Anti Pattern — The Ponzi Roadmap

The anti-pattern I’d like to explore today is the Ponzi roadmap. It usually starts with the best of intentions but has extremely harmful effects as a company scales.

When a company is in the initial stages and has a small engineering and product team the planning model that emerges is what I call the pooled model. Engineering is considered a pool of resources and usually composed of full-stack engineers. The product is typically small and mostly a monolith, every engineer can work on anything and there are just a few PM’s (maybe just one). Since we are all agile, every quarter the PM comes up with a list of priorities and outcomes, engineering staffs the priority from its pool of engineers and delivers outcomes. The next quarter rolls around and we do this all over again. Engineers move on to working on different things every quarter. This makes perfect sense in a small company — but goes horribly wrong as you start scaling up.

Now imagine, you have scaled up and you have a large (100+) engineering team. You have a lot more customers, your product set is getting complex and thus the outcomes that you want, take longer to deliver. The resources required to deliver each of these outcomes also vary widely — some are big bets some are quick wins. Your stakeholder base has also grown proportionally, you have a lot more priorities and stakeholders to manage.

Here is what typically happens in this scenario,

• The large priorities (bets) get staffed first followed by the smaller priorities. This typically leads to the smaller priorities being staffed with subscale teams (1 or 2 devs per project)
• Since outcomes don’t follow a quick quarterly cadence, they tend to be now converted to “projects”. There are now long-running and short running projects.
• There is a now a mismatch created in the stakeholder’s expectations — they are assuming that all projects are staffed equally based on what used to happen in the early days using the pooled model
• As time goes by, some project gets delayed and that particular stakeholder wants it bought back on track, they want to be creative and explore acceleration. As product and engineering you start making resourcing tradeoffs — “that project is late, how can I put more engineers on that project”. You start moving resources around to plug the gap, but in effect steal from other projects. This seems natural to you since you consider resources as a pool, the pooled resource model is what you are used to as your operating mental model.

You can see how this starts to feel like a Ponzi scheme. You start moving engineers mid-project, you start creating havoc. You start moving people around to whichever stakeholder shouts the loudest. The resource pool is still fixed — you effectively are executing on a Ponzi roadmap.

This Ponzi scheme has huge effects on the team. The engineering and product team is very demoralized as they keep moving around — so much context switching. The stakeholders are upset as their objectives are not met, leads to a loss of trust. More importantly, the organization becomes more project focussed than outcome focussed.

So what’s the right way to think about it?

Right before you start scaling, you as a product leader have to start the organization’s transition the mental model from a pooled model to a domain model. What is the right way to model your business as long-running streams of work? What are the right domains for your company that you can map mutually exclusive outcomes too? Once you have figured out these domains, now staff these domains with long-running teams that are specialized for that domain.

What constitutes a long-running team?

• A team that works on that domain for an extended period of time (ideally 1+ years)
• The team capacity is fixed and is scaled correctly to the domain — no subscale teams
• The team has a single mission and works on a specific part of your product. They have absolute clarity and ownership of that part of the product.

This long-running team model has a ton of benefits. It is great for teams as they have long-running ownership and go deep within their domain. They can see their efforts pay off in the long run since they are going to be around on the same team to see the results of their work. They own their code, warts and all — they’ve been on the team long enough to know how to fix problems. Most importantly as the team works together for an extended period of time they can finely tune their ways of working and become a high performing team! From a product/stakeholder perspective roadmap shifts are also easier to manage as every tradeoff isolated to the same domain. As resources are specialized you cannot wily-nily move engineers between domains — this keeps resource churn at bay. This enables the product team to keep the focus on outcomes rather than projects.

But what if you are already a victim of this anti-pattern and want to change? Have no fear, here is a 5 step plan to get out of the rut

1. First, acknowledge that you have to start somewhere, the right place to start is to fix the baseline team size. There will be a temptation to focus on fixing the priority set first — do not do that. Decide what your baseline team size should be, typically this is no less than five Engineers, a PM and a Designer
2. Sit with your stakeholders and map out your product into domains. This is the most important bit. What are the long-running streams of work? What are the skills required in each of these domains?
3. Map your existing teams to these product domains. Ensure that the domains are correctly staffed in terms of skills and scale. If there are domains that are staffed with subscale teams — recognize this as a gap. You need to invest in filling this gap! Also, recognize and state upfront that this domain will have suboptimal outcomes until the gap is fixed. Once this mapping is complete, you have a good idea of the baseline bandwidth for delivering outcomes for each domain
4. Now map your priorities on top of these long-running domains. Since you have a good handle on bandwidth PM’s can accurately prioritize within the domains. Domain bandwidth is the constraining factor
5. Now ruthlessly stick to this model. Once this model is implemented, do not go back to a pooled approach. Priority and outcomes are domain specific, the only thing you can do is to add resources to the domain pool or decide that a domain is no longer viable and kill the entire domain. Each domain is largely independent of each other and can start delivering outcomes independently

Would love to hear your experiences with this anti-pattern in the comments!

Originally published at https://blog.thesharmas.org on March 26, 2019.