It's monday. You wake out and reach the office (which may very well be your sofa given the current times), turn on your laptop and open your email software.
One of them catches your attention; the title reads "New company wide Project Management tool".
A chill goes down your spine. "Make it be not Jira" is the first thought as you open the email.
Feels familiar? I guess everyone had a similar moment in their professional career.
I've had the pleasure to follow the rollout and administrate an Atlassian Jira Cloud instance for a couple of years for a small company, and I don't think I have fully recovered yet. The complexity hidden behind that subscription is massive.
After self-reflection, my question is: was it Jira's fault? Is the tool to blame for the complexity of the resulting process and the effort it required just to use it for day to day work? Would another tool change the outcome?
It seems it's the tool that matters, but it's not. It's the context around the tool that matters.
This is a perspective from an ex-DevOps working for a product company.
This post is not about Jira. Far from being perfect but you'll never be happy using a hammer when you need a screwdriver.
This post is about the fundamental wrong assumption we make when searching for a project management tool.
The first interesting question is: why do we need a project management tool?
The answer I've seen in the wild is that coordinating the work in progress becomes too difficult, and this complexity is blamed on the tooling being missing or not adequate (i.e. different or fragmented usage, missing items, lack of visibility or adoption).
The supposed benefit of a Project Management tool are:
- coordination, defined as being able to make plans on top of other groups activities/plannings
- consistency, defined as being able to move easily across groups/teams with a small overhead
But you are not going to achieve consistency, and once that promise is broken, good luck obtaining coordination. More interesting, coordination may not be what you need at all.
First, let's examine consistency. I've yet to see two teams (or people) use the same tool in the same way. It doesn't matter how far the teams are, even in the same company.
Most of the time, the usage is so different that they could be two different, not interoperable tools, and the complexity would be the same.
Consistency requires a massive effort in understanding, coordination, enforcement. Such effort does not scale and is so rigid that you risk being paralysed by it.
Do we really need consistency? No.
We strive for consistency because we expect it to drive better collaboration. And we struggle so much trying to be consistent that our work becomes keeping the consistency.
I would argue that once you reach proper consistency, the one-size-fits-all approach resulting from it would be a terrible product management take. (Remember it is a product company, not a consultancy).
The one-size-fits-all does not work because software development is knowledge work. It implies learning, continuously. It implies adapting.
We know that knowledge work requires "deep work", defined as long slots of uninterrupted focus work time.
The Deep Work Hypothesis.
Deep work is becoming increasingly valuable at the same time that it’s becoming increasingly rare. Therefore, if you cultivate this skill, you’ll thrive.
Cal Newport in Deep Work: Rules for Focused Success in a Distracted World
The recent remote work explosion made clear something that remote companies already knew: focus work drives productivity (and revenue).
If we already trust people to plan work and execute through long focused time slots, why don't we trust teams to do the same?
It's time to go back to the drawing board and review the question that brought us here. The question we should start from is "how do we deliver better software?".
We know some coordination is needed and we know focus is needed.
So why don't we focus on making coordination easier instead of making it consistent?
What does consistency even mean in a fast-paced context like software development? There is an industry focus on being agile to respond to changes, but coordination makes reacting to change more difficult and expensive.
What to do instead? Incidentally, we can take inspiration from the same field we are in. Software Engineers developed ways to make it easier for different code created in isolation to work once it is put all together.
We use testing, decoupling, interfaces and APIs. Those are our tools to build incredibly complex and interconnected systems.
Then why don't we apply the same principles to coordinating work? (Spoiler: hyperscalers do).
We can derive that it is not coordination that is important, but boundaries and understanding.
Boundaries: once I start thinking about what a dependency should do to fulfil a need I have, I stop worrying about my work and start worrying about someone else’s work. Boundaries drive Expectations: if I know I cannot directly influence something, I will need to find ways to integrate with more generalist approaches.
Understanding: no system can talk to another without mutual protocols that both systems understand. No teams can work together without mutual understanding and building shared processes.
Defining boundaries and understanding others can be only fulfilled through communication. Any communication protocol (in use by humans or machines) adds overhead to the conversation (why is the Lora protocol preferred over TCP/IP in IoT? Lower overhead)
Being a generalist and understating others requires communicating, which creates overhead, like any communication protocol.
Any form of collaboration has overhead. Your Project Management tool of choice will have overhead, probably hidden behind all the marketing.
But we have a North Star to drive us, we want to build better software.
We cannot answer only considering costs (collaboration overhead) we have to consider quality.
Boundaries and understanding drive quality.
You will adopt a Project Management tool. But do not use it for coordination, use it to empower teams within themselves.
Coordination is not the forcing function you want your employee to spend time on. Instead, engage teams to define boundaries and create space to understand each other.
In the end, we want better software for better products to better serve our customers in an ever changing landscape. Your silver bullets are empowered teams working towards the same goals.
Cover photo by Leon on Unsplash
Inline photo by Paul Skorupskas on Unsplash
Hey 👋 I'm Edoardo. I've been a DevOps and started digging into processes and what does it mean to improve software delivery within a company. Reading and listening creates opinion, and I'd like to discuss them with anyone interested! Join the conversation and let me know what you think in the comments!
Top comments (0)