The plan is our best company-wide communication device. It visualizes where and when we will spend our resources. It also shows us where we won't spend our resources. What's not on the plan won't get built.
One of my apparently more controversial opinions is that Engineering, not Product should own the plan. Last week I explained why I believe there should be a single owner. This week, I’d like to go a bit deeper into why I believe that should be Engineering.
Back in the day, the team that delivered the project was also in control of their plan. That was seen as part of the job. You couldn't outsource it. Why would you? Each development team had a Project Manager who created, maintained, and communicated the plan to the rest of the organization. While the PM had little to no influence on the scope of the product, they owned the plan. They decided what got built and when.
A lot has happened since the '80s. We've moved our mindset from change-as-the-exception to change-as-the-default. While there is some debate about whether they are "doing real Agile", most organizations have moved to a form of agile software development. Our teams are optimized for change rather than predictability.
The popularity of agile software development has replaced the project manager with other leadership roles. While these roles have some diversity, they share a common trait: they don't plan.
A generation of Scrum-style frameworks has raised developers to believe that planning is for dinosaurs. We can't predict the future, and therefore, planning is useless. Prioritization is our only tool.
It's a mistaken worldview that hurts our businesses.
Customers and stakeholders want to know when they will get something. They wanted to know that in 1970 and still want to know that today. That hasn't changed.
"When" is a tough question to answer, and nobody claims it isn't. But, whether they like it or not, engineers are in the best position to answer it. They are the closest to the work.
If they don't answer the question, they kick the can down the road. By definition, it will end up on the doorstep of someone less qualified to answer it. That's usually the Product department. Product people are generally intelligent but ill-equipped to answer the When question. They have no insights into capacity or complexity.
Product has only two options when they can't get the Engineering team to commit to a delivery date. And one is "ignore our customer's valid question and hope it goes away"...
So they try to answer because the can ended up on their doorstep.
They have to.
That's not making empty promises. That's not writing a cheque that Engineering can't cash. That's making a flawed attempt at doing the job Engineering was better equipped to do.
Engineers should own the plan because they are in the best position to do so. They are closest to the work and can adapt the fastest. They’re the ones making and breaking the commitment.
Owning the plan does not mean nobody else has a say.
It's not a powerplay.
It's a clear definition of responsibility.
What we're going to build when is a conversation that requires input from Leadership, Product, and Customer Success. All these parties have conflicting incentives. The only one who can align these requests into a plan is the party that will do the actual work. Only they know their capacity. Only they can commit.
In other words: Everyone can influence the plan, but only Engineering is in the best position to maintain it. Everyone can comment; only Engineering can edit.
Ownership means Engineering should be able to answer "When can we work on this?".
When Customer Success needs an urgent intervention, Engineering should be able to see the impact. "If we prioritize the patch for customer A, the feature for customer B will be postponed to June. Is that worth it?"
When Sales can close a deal by promising a future feature, Engineering should be in a position to support that rather than blocking any attempt to run ahead.
The alternative is the all too common situation where everybody is forced to make implicit promises and throw them on an ever-growing backlog. That's frustrating and unsustainable for all involved.
Backlog prioritization can only take us so far. To answer the big questions, we need a plan owned by those who can best maintain it.
And that, without a doubt, is the Engineering department.
I think it's best when the CTO oversees product and engineering and can balance all of it together to your points. Engineering tends to focus too much on maintenance work. Product wants to build new features. Someone has to balance it out.
A version of this that has worked well for me is to have a Product focused person being on the engineering team that is doing the implementation (Squad, Pod, etc).
They are part of the team: in the standups, in the design discussions, in planning meetings. They understand both the overall Product needs as well as the engineering challenges. When a priority conflict occurs or a development hurdle presents itself, they are there working with the team to resolve it.
I agree, engineering should be the driver of the plan. The engineering team can include an embedded product person that understands both engineering and business needs.