Product development capacity: What is it and how to model it
In my previous post, I outlined a collaborative process for deriving a product roadmap. One of the key components of this process was the available engineering and product capacity. The question is, how do you measure this capacity? That is the topic of today’s post.
I measure engineering capacity in terms of teams, which is probably not much different than most other software companies. There are however some first principles I apply when creating teams. These are the following.
First, teams should be vertically integrated. This implies that a team developing a particular feature should have all the required skill-sets needed to build said feature. The typical skills, or personas, range from back-end software developers, front-end, data, UX and DevOPs. The composition of teams need not be aligned with the structure of the product and engineering organizations. I’ll come to this point later on.
Second, every team must have a Product Manager, a Tech Lead and an Engineering Manager assigned to the team. A Tech Lead belongs to one and only 1 team, whereas an Engineering Manager and PM can be mapped to more than one, likely capped to 2. Tech Leads are responsible for the technical outcomes. Therefore, they tend to guide their team on feature design, dependencies and testability. They are the technical experts on the team. Product Managers are ultimately responsible to ensure that the delivered feature meets specifications and provides user value. There’s a lot more that PMs do, this is simply scoping it down to their core responsibility on a development team. Engineering Managers, on the other hand, act as the Zen Masters of one or more teams. The role can be best summarized as shepherding their teams to a successful outcome. Engineering Managers can take on a technical leadership capacity, typically for first time managers who were previously Tech Leads on their teams. The more experienced managers, “hover” over 2 or more teams.
“A strong engineering manager observes her teams, sometimes deliberately letting balls “drop” and every so often interjects herself to handle one of the many balls in the air, before it drops. The one that she handles, presumably would have had dire consequences had it dropped. “ The Engineering Manager Role
Third, is the need to build long lasting teams. Teams take time to gel. The longer a team works together, the better the chances that they perform better, meaning they can become a high performing team. As such, you do not want to change the team composition, or at least you should not dramatically alter it. Therefore, when designing a product roadmap, I try to optimize for this outcome by assigning a team to a thematic line of work, meaning that the list of features assigned to a team are related. You want the scope of work to change somewhat for the team, but not to dramatically alter the team composition. This helps develop expertise within the codebase and customer use-cases and fosters team longevity.
Fourth, is the desire to have agency and flexibility in team selection. At one extreme you can open up team assignments to the entire team, asking individuals to self-select who and what to work on. Similarly, on the opposite extreme you - or generally speaking leadership - can make these assignments on behalf of individuals. I have found that a middle ground approach yields the best result. You want to seed some positions whilst offering up some open spots for a subset of the team to self-select. The motivation for this hybrid approach is to optimize for well balanced teams. While you do want agency, you also want teams to be set up for success and sometimes that requires placing individuals on teams. Those tend to be ones with skill-sets, technical or otherwise, that are a must-have on those teams.
With these principles and additional constraints in place, you can now start plotting out the number of teams you have and their composition. I had outlined some of the constraints that I applied earlier, which are I summarize down below:
Each team must have 1 PM and a PM cannot be assigned to more than 2 team
Each team must have 1 EM and an EM cannot be assigned to more than 2 teams
Each team must have 1 Tech Lead
A full-stack team (i.e. building UI elements) must have at least 2 front-end engineers and 1 UX designer.
If you absolutely must, the minimum team size is 2 engineers. Default to 4+
All resources/skills that a team requires are embedded within the team
I then use a sheet like the one shown below to solve for these principles and constraints. Those in turn will always yield some limiting factor that gates the number of teams, and hence capacity available to consume work. The image below is for illustrative purposes only.
I mentioned earlier that you shouldn’t take the structure of the various organizations that contribute members to these teams. The main reason for this is because you are trying to optimize for business outcomes.
Therefore, when building a capacity model you are attempting to find the optimum bandwidth that can yield the highest business outcomes. The latter being a function of prioritizing the most important work and doing it as efficiently as possible. Hence optimize for that versus trying to map work to an organizational structure.
That in turn implies that the Engineering Managers on a team might not necessarily work with all of their direct reports. The org model is not necessarily 100% aligned with the team model. However, it has been my experience that the overlap between direct reports and manager tends to be ~80%. Additionally, some orgs will have some individuals not mapped to product development teams. For example, not every member of your DevOPs or Data teams will be mapped to a product development team. The ones that aren’t will focus on work that is relevant to their respective teams; keeping infrastructure operational for DevOPs and maintaining ETL pipelines, data lakes and so forth for individuals on the Data team.
Things I am reading/listening to
It’s not everyday that we get an inside peek into the text messages of the world’s richest person. The Musk exchanges were quite disheartening to be honest. The cavalier approach to company strategy - if you can call that strategy - left a lot to be desired. That, and how ridiculously easy it is to get Larry Ellison to part ways with $1B :)
Battery Ventures published a couple of posts on offering a glimmer of hope for SaaS and software companies. “Finally, Some Good News for Enterprise-Tech Startups: Battery Ventures Survey Finds Tech Spending Holding Steady, Even Increasing Despite Market Downturn”
I’m a huge fan of Aswath Damodaran, who does an incredible job on corporate finance and equity valuation. His latest post offers his perspective on the inflation and the current market downturn