The Anti-Pattern that Sees the Disempowerment of Engineering Organisations Everywhere
Product Managers doubling as the gatekeepers of work in sprints is a tale as old as time itself.
But with such little reward, the question begs to be asked: why?
Product Managers have the critical role of building a product that will win the hearts and wallets of the masses. At a macro level, this involves setting product vision and strategy, defining and socialising OKRs and developing a roadmap. At a micro level this involves building feature canvases, writing and prioritising user stories, driving alignment with cross functional team members and stakeholders, spending lots and lots of time in discovery (with internal teams, with customers, with the target markets)…and, apparently, policing what Engineering are and are not allowed to work on in a sprint.
Whilst an exact date of this immaculate conception of Product Managers to Sprint Gatekeepers is unknown, I would hazard it was most likely around the time Product Managers were suddenly expected to also be Scrum Masters, Jira Housekeepers, and the most unfortunate of them all fell prey to the perils of the dreaded feature factory style of working. This deadly combination has an equally deadly outcome: Product Managers invoke parental controls over Engineering and take charge of what goes in and out of a sprint in a desperate attempt to meet crushing delivery expectations.
And from this point forward, Engineering is almost always viewed as a “sub” function owned by Product. When various stakeholders “need something in a sprint”, those stakeholders and even the Engineers themselves will look to the Product Managers for their “blessing” to include the item. And thus, the anti-pattern is established. But Engineering is not a sub-function of Product, it is its own function, and should be empowered to be responsible for what they deliver within a sprint.
Seeking approval from the Product Manager because the Product Team “own” the sprint is a common antipattern in organisations.
Product Managers obviously have substantial equity in an Engineering team’s sprint capacity. However, that equity should be elastic, with an ongoing roundtable negotiation between all stakeholders.
Whilst the primary function of an Engineering team may be the delivery of product development, many Engineering teams also find themselves responsible for other non-product-development tasks. I’m not talking about new feature requests or feature changes, I’m talking about those other tasks such as Marketing needing their GTM codes updated or changes made to copy, or an update made to the integration the product has with the CRM. None of the aforementioned items should need the blessing of a Product Manager.
Even particular, bonafide bugs (not the sneaky feature changes or enhancements masquerading as bugs) should be up for debate and not at the direct mercy of the Product Manager’s nod; instead Marketing, Sales, Customer Success or whomever should be part of the conversations with Engineering and Product Management during sprint planning and align on sprint priorities and goals together.
A much cleaner method is having frequent roundtables for sprint prioritisation.
The benefits are three-fold:
- There is less opportunity for miscommunication, and communication overall is faster and more efficient,
- The Engineering team are empowered to act as and be their own organisational function,
- Stakeholders (besides Product) feel empowered, unblocked and in control of their own work and accountabilities; and
- Product Managers don’t need to play God and get to focus on their core role: building an amazing product people will love to use.
The Engineering team become responsible for the tickets in their sprint — they are responsible for keeping them up to date, liaising with the relevant stakeholders and essentially removing the middleman that the Product Manager often (unnecessarily) plays. There’s something very gratifying about being in charge of your own destiny, don’t you think?
If a key concern is having the Engineering team become distracted, or receiving requests from too many angles, then my answer to you is that is what your Engineering leadership is for. Stakeholder management is equally critical as an Engineering Leader as it is for a Product Leader, and you should not underestimate the importance of having strong Engineering Leadership in place.
Equally, if you’re concerned that granting additional stakeholders direct access to sprint capacity will dilute focus on product development to the overall detriment of the product, I challenge you to have greater trust in your Product Management team: inspiring shared vision and driving alignment around key priorities and objectives that will lead to a winning product is part of the Product Manager’s bread and butter. When sprint capacity needs to be dedicated to getting a critical, overarching objective over the line, your Product Manager should have the influence and skill to rally everyone around that need.
This slight change in process doesn’t solve all the aforementioned problems of Jira housekeeping, Sprint gatekeeping and feature factory conveyor-belt syndrome, but you do achieve Product Managers relinquishing parental controls over Engineering, broader stakeholder empowerment and collective alignment across the company.
This is a deeply ingrained anti-pattern that so, so many organisations have adopted for one reason or another and it’s an anti-pattern that is far more costly than you’d believe it to be. I encourage you to take a look at the way your own Product and Engineering functions operate together: do you see this anti-pattern at play in your organisation?
