A pretty good instrument for an engineering manager that helps figure out what’s going on and what to do next is a staffing plan. A counterpart to that is staffing audit, which has a purpose of making sense of reality, as opposed to making a forecast into the future.
You might need to make sense of staffing when the team’s ownership areas change as a second-order effect of an update to product strategy or even new short-term goals being set, when the team configuration changes in response to hiring or employee churn, or when the change in product and/or engineering strategy requires the team’s collective skillset to adapt.
So technically staffing plan aims for solving two problems:
- when the conditions for team’s success change, you want to be smart about restaffing, to (adaptively) set the team up for success
- when the team configuration changes, the conditions for the team’s success change, see previous point
Knowing a couple other things help figure out staffing:
- a clear, unambiguous purpose for the team that is up to date
- things that the team de facto owns and maintains
- distribution of tasks and skills on the team
- projected professional growth of each individual and their career ambition
Purpose of the team
The team’s purpose serves a big role because it informs what the team is going to be building and maintaining, and what kind of problems exist or are likely to emerge as the team iterates on the product.
Team’s purpose informs what their part of the product is about (functionality) and how likely it’s going to require maintenance (longevity).
In a small org, teams own parts of the product end-to-end, across the entire stack, through good times and bad. In a moderately sized org, where the number of teams doesn’t allow for easy inter-team prioritization, an extra dimension opens up to help different teams apply their expertise to build something big, and project management as a discipline (might be called differently) starts taking place. In a large company, for any part of the product, development and maintenance inevitably get broken down into smaller subdomains and then separated by function (know a company where it didn’t happen? drop a comment), which means clearly defined purpose for each of these teams is even more important.
Finally, tying staffing to the team purpose serves as a sanity check at org level: for two teams with similar purposes, if there’s a different in how they’re staffed, something is off and needs more attention.
Areas of ownership
In a digital product and engineering org, each team should be clear on what they own and maintain and what they don’t.
Team’s purpose helps, but it’s not enough when the team is under pressure: a lot of last-minute projects can get hammered into that definition, usually leaving the team with tech work that doesn’t click with the rest of the product the team has developed and keeps alive. That’s why it’s important to be clear on actual pieces of the product.
Side-note, calling things the same name is notoriously hard across a big enough organization. Coincidentally, that’s when it’s most important. Getting through the way people talk about things and working out a shared vocabulary requires many, many months of work.
Distribution of tasks and skills
Tasks on the team can be defined by distinct processes or artifacts. Writing code is a task, collecting user feedback on a prototype is a task, and running a retrospective meeting is also a separate task.
Skills are what people can do or practice in order to achieve the team’s goals.
Each individual on the team is committed to doing some of the tasks. Over time, if people on the team are given enough autonomy and receive enough feedback, they’ll arrange tasks among them in a way that fits their skills best.
Now the interesting part: some of the tasks on the team might not be fulfilled. That is, they need to be done, but no one really gets them done. And sometimes it’s not even immediately visible.
My favorite example is technical documentation. Some people have seen lack of docs backfire, and they then corrected towards documenting things. If they stick long enough, they figure out that organizing docs, writing a document that can be understood, and getting people to read docs are three separate skills that each need practice.
When staffing a team, you want to have at least one person having a skill that is needed to fulfill each of the team’s tasks. With feedback and recognition done well, skills usually spread, although slowly.
Even with the tasks that require nearly perfect execution, it’s actually tricky to staff a team in a way that all or almost all team members would possess the necessary skills. In a moderately sized team of 5–8 people, 1–2 people end up owning that task, thus applying the skill. And that’s okay, because it doesn’t require crazy complex planning, allowing to focus more on team “click” than skills.
Individuals’ projected professional growth
By default, if you have a problem and you have budget, you’ll probably default to hiring for specific skills that are supposed to solve the problem. Hiring for full-time roles is in itself a complex process and an exercise in placing bets against partially unknown, and +1 direct report can kick in the need for more changes.
To some degree, same is true for hiring contractors or agencies. They still require direct management, even though a lot of things are easier because the relationship is more transactional and performance-based.
An exercise I found useful is projecting professional growth and skill acquisition for each of the individuals on the team. There’s often a way to align incentives, and if you’re lucky, it can even work without a long ramp-up period.
A smaller team that makes it work is in many ways better than a bigger team that makes it work.
The most prominent constraint that works against the team is time. There are cases when hiring for a missing skillset, as long as this and then onboarding take, is a more reasonable option.
A staffing plan, done good enough, should help you avoid overhiring and look for people that are going to cover the tasks that can’t currently be covered. This might reflect into the hiring plan and thus will require cooperation with the hiring team. In extreme cases, this might also lead you to creating a new role in the org, causing changes in onboarding tracks, career paths, and more. Don’t go alone, work with your peers in the company who are most likely to be affected (recruiters, engineers, non-tech product and design people, technology marketing, the list goes on). It starts small, it can get big, the key is in making small incremental changes while keeping an eye on the target org structure. Good luck!
