Who owns the timeline — Product or Engineering?
For any important tech-driven initiative, there are three key aspects that are reviewed by org leaders — impact of the initiative, cost involved and the time taken. The impact of an initiative can only be truly known after the relevant features go live. So, during execution, the other two aspects — costs and timeline are tracked by the leaders. For initiatives developed by internal product and engineering teams, while the marginal cost of running the new features will be important to understand, the cost of development is directly linked to the time taken to develop once specific teams are identified and allocated. So the key aspect that is really tracked is the timeline. Which products and features are on time? Which are delayed? Why are they delayed? And the reality with most big projects is that there are delays. So the uncomfortable question that teams often face is who should be the person responsible for “owning” the timeline? Should it be the program manager, the product manager or the engineering manager or a joint responsibility amongst these folks?
But what does owning the timeline actually mean? Here, it refers to the attitude needed to ensure release or launch by a target date by aligning the teams, tracking the execution, identifying and unblocking risks. Importantly, it also means when things do get delayed, communicating the same to other parts of the organization & org leadership on what upset the plan and share the updated plan on what’s going to be done. And in many organizations, this responsibility is expected to be with a single person for each major initiative and not a group — to ensure there is clear accountability. “One throat to choke” and “Single-threaded leader” are some terms that convey this expectation.
I believe this owner of the timeline should be the product manager of the feature or the corresponding product leader. We will discuss the reasons behind this, but, before that, let’s briefly examine the steel man arguments for why the owner should rather be the engineering manager or the program manager.
Engineering Manager as the Timeline Owner
The arguments for making the engineering manager as the timeline owner are:
- The work is finally done by the engineering team. So they are closest to the details and know where the work actually stands.
- If anyone else outside engineering is managing and communicating the timeline, they are in effect making commitments on behalf of engineering, probably without sufficient knowledge of the work and without taking the engineering team into confidence.
- The product manager cannot be the timeline owner since he does not directly control or manage the engineering team. The PM will then have the responsibility but not the authority to fulfill the responsibility.
While each of these arguments have truth in them, we will soon discuss other reasons that make a more persuasive case for why engineers should be accountable for their commitments but not for the overall feature or initiative.
Program Manager as the Timeline Owner
So, what about the program manager? By role definition, the program manager needs to get commitments from different teams, keep them accountable, unblock external or inter-team dependencies and provide updates to management. Shouldn’t he be the natural owner of the timeline?
Unfortunately, many product teams don’t have program managers. And even if they do, the program managers are responsible for tracking multiple ongoing initiatives. They typically do not have the detailed knowledge of what’s being built, the tradeoffs involved in making changes and deciding if something is good enough to be shipped. So when there is a program manager available for product teams, it is great to leverage them and they can lift a lot of the heavy work involved in execution, reporting and help facilitate decisions, but they cannot become the owners in the true sense.
It has to be the Product Manager.
Now, let’s see why the product manager is the best person to own the timeline.
PM provides the sign-off
The product manager is responsible for determining if a feature meets the quality threshold needed for releasing to the wild. While there might be other approvers involved, the PM is the main person who first needs to convince himself and then make the case to the others.
PM knows the true status
Engineers tend to be optimistic about what they have developed and present a rosy picture on where a feature stands. And quality assurance teams are pessimistic and likely to provide a laundry list of open issues to make the argument on why the feature is not yet ready. The PM is (should be) the pragmatic person who can sift the two and provide a more realistic status on where things stand.
Engineering work isn’t everything in a feature
In most large features, coding is only a subset of the overall work involved. Go-to-market readiness typically includes dependencies on many other teams like marketing, content, ops and support. The PM would be the one to know where each of these dependencies stand to provide the right holistic status.
Feature work doesn’t stop after engineering
A feature might be complete from a development perspective and the engineering team might have also moved on to the next thing. But it can still be under validation — Beta, Pilot, Limited Release, etc. The PM would be driving these phases and coming up with the learnings. The timeline for a general release to all users would depend on follow-up actions planned based on the learnings and the PM is the one best positioned to provide such updates.
Timeline isn’t everything
Sometimes, there are technical challenges or usability challenges identified only during the development or validation of a feature and decisions need to be taken trading off between timelines and the overall user experience or usefulness. Owning the timeline involves making these assessments and convincing leaders on why something would take more time than initially planned and that it is worth the wait. It is difficult to expect the program manager or engineering manager to provide the full perspective in such scenarios.
Shield the team
There will be scenarios where communicating and owning up to delays is just a thankless job and the PM needs to be in the line of fire. But this helps protect the team from the heat and keep them focused on the execution rather than exposing them to direct fire from different teams. When this repeatedly happens, it obviously points to something wrong in the overall process but an occasional hit should be taken as part of the job.
While the above are good reasons for having the product manager own the timeline, there can also be bad reasons for doing this.
- If the PM believes that the timelines provided by engineers are unreliable, the product team can get into the habit of adding buffers and sharing those with other stakeholders while still pushing the engineers to deliver by earlier dates. This is not a good idea as it will be seen through pretty soon and will just become an unnecessary headache to manage while losing the team’s trust. The better approach is for the PM to take his intuition on why the timeline from engineering is unreliable and convert it to a more reliable plan. This can be done by asking the right questions to the engineers to understand the assumptions, dependencies and risks and by bringing all the important milestones (like the General Release, Marketing Event, Beta Release, Internal Release, Leadership Demo, QA Sign-off, QA Release, Dev Demo) and the criteria for proceeding from one step to the next into the plan.
But, beware. Things can go wrong.
Product managers owning timelines can backfire if there is too much organizational focus on just delivering features on time than focusing on the actual impact of the features.
- Innovation can get stifled. PMs might stop taking risky bets which can take more time due to the uncertainty involved in such initiatives.
- Much more proportion of time might start getting spent on execution of an average solution rather than on problem definition and solution ideation.
- PMs can end up doing tasks which legitimately need to be owned by engineering like coordinating between the frontend and backend teams.
