Team sizing and planning

A framework for team sizes and how to find the hidden energy sinks

I will share a couple of tools that I use to plan or evaluate priorities in a product engineering team. They are somewhat opinionated because they are made to assess two dimensions: staffing and priorities.

If you talk to tech companies with product engineering teams bigger than 100 people, lack of visibility, moving targets, too much time spent on meetings, hiring hardship and a yearning to measure ROI comes up in different orders.

I am a strong believer that teams should be protective of their the work in progress (WiP). Out of control WiP will drag people around, reduce energy and create discussions of prioritization. carefully but to do that you have to have healthy teams, reasonable tech stack and direction.

Hiring

Teams that are pushed to ship more, are usually (well, before 2022) led to hire in what is called “hyper growth”. Engineering count was a vanity metric for VCs, over a given valuation your team had to have more than 500 or 1000 engineers. If you want to up your multipliers you should have a Data Science initiative or office. Hiring based on count sometimes is the choice of companies that are not used to make priority calls that lead to hard conversations.

You should write down what you do and what you want to do, look on how many people you already have and how they are distributed over it. Take into account people that are “shared” across initiative and then proposing scenarios of different pocket deepness.

The key is visibility of people that are shared as it can give the impression that an initiative is covered but it is not. That's true for sales driven organizations where the prioritization process is not clear or product driven. You may have interruptions and processes that drive the team to poor engineering choices due to lack of time (think scripts running manually in production as rake or shellp, queries that are sent through email, hard coded data that require deployments to change).

Assessment

As a new tech lead or CTO you will have to assess these initiatives to see where they are, if they are worth, not competing or cannibalizing any other initiatives. An easy way to do that is to map. A simple framework for this is to write scenarios based on the work you do and want to do. You will find an example here.

It is essentially a review of what you do and what you have. Workload management is important as you know what your team do and what it shouldn't do. Interruptions and “just an if” kind of work allied to low quality engineering are multipliers of technical debt and energy sinks.

Note that in some places you have .5 or .3 or .6 instead of 1 engineer. It means that the same person is doing more than one thing. It may be ok but you need to look how it will work once you hit a new scale level, if these things are more than tasks, if they should be automated and if they were officially planned.

My rule of thumb is that you can share tasks within a project but never full line of work. And that one people doing one thing is a huge risk for the company, usually called “bus or truck factor”. Try to eliminate them in the Realistic scenario.

Once your assessment is filled you will have deltas and scenarios to work for hiring plus product prioritization. That's it. Easy to write, hard to follow. You will have to balance between your dream as in “having a full squad for each project so I don't need to have meetings to prioritize and discuss delays” and realistic “I shouldn't be doing all of these, let's try to get our platform together and move from there”.

Having these scenarios discussed with your team will give you mobility as they won't be in all meetings and decision making forums as you will, so you will always trade-off between blocks of commitments you all agree. That's important to enable your leadership to get stuff done.

The next step are defining the metrics for success and agreeing on how to follow them. Follow the money is always a wise choice - having your product north star defined and agreed will make everyone life's easy on the day-to-day decision making.

If you need a framework for these small decisions and to know when to escalate them, check my post about decisions frameworks.

You will find a 90 days getting started framework in my book, The CTO Field Guide

Foreword

I have published a book called The CTO Field Guide that provides a comprehensive breakdown of metrics and questions that works for most of the teams. It will help people from tech lead to CTO roles.