Running Engineering Teams productively - having both slack and being understaffed
The key to running engineering teams at the optimum efficience is by both having some slack, as well as always feeling like you have less people for the tasks at hand
1. All engineering teams need some “slack time” (not the chatting app)
2. All engineering teams should be slightly understaffed and perennially non-empty list of things to do
The biggest Engineering Management learning is to reconcile these two truths of work.
There is this famous book by Tom Demarco called “Slack” which is great read on why teams need some 'slack time'. That is, if the team's capacity is to produce 200 units of work per week, then only plan for 175 units of tasks every week, and keep 25 units free to pick up tasks that come along the way.
Things break.
Suddenly things get re-prioritized.
You encounter weird corner cases working on something, and it takes more time to close.
Shit happens.
Always have some spare time to keep bandwidth for that.
That said, teams should also always be a little understaffed.
Why?
Read this whole thread by @mipsytipsy (on @GergelyOrosz's reportage of Apple hiring policy through COVID)
https://twitter.com/mipsytipsy/status/1620693675293691907
The challenging thing for most first-time engineering managers is to wrap their head around this fact that both the statements are true.
And at first glance it'll appear a bit bonkers. We need to have spare time and yet, we need to have more work than people can do?
It is compounded by the fact that 99% of workplaces are either one of these two -
extremely over-hired, and fairly profitable (common in zirp era) big tech companies — where new projects some with a default ETA of multiple quarters, and employees frequently make use of 20% time, unlimited PTO, etc
a biltzscaling over-funded scaleup (also common in zirp era) which wants to do everything - growth, ads, subscriptions, enterprise, support all of it, and is looking at 3-4 competitors and trying to out-build them all, with PMs gunning for unreasonable 'ship it yesterday' demands
If you are in category 1, it might be difficult to see the problem @mipsytipsy talked about — that you have no constraints to keep you grounded in reality. And it can lead to some of these weird scenarios where your reports come and tell you that their biggest problem in life is that their “backlog is empty”.
If you are in category 2, it might be hard to see that half of your problems are not lack of bandwidth, but lack of time to pause and take breath. As a result of which your team are on the verge of burnout, and producing sub-par quality work, that breaks more often, creates more production issues, and is actually slowing you down.
If you can engineer the most beautiful balance though... the utopia looks a bit like this -
when you look at today's deliverables vs this week's todo list, you feel there is enough time to wrap up today's work (and some spare), but there's a lot to be done this week
when you look sprint goals vs quarterly OKRs, it feels like the sprint can be comfortably achieved, but the quarterly OKRs seem daunting
when you look at current team size vs hiring goals it seems like you don't have enough tasks to give to everyone, and yet there's less people scheduled to join in the next couple of months than you need
when you look at upcoming releases for this quarter vs projects lined up to ship in next year's annual conference..... you getting where I am going with this?
Yeah so basically, if you can engineer this "slack time + understaffed" scenario in the most elegant way - the short term will always feel relaxed and under-control, while the long term will always feel ambitious and challenging.
Both these things are immensely important to let engineers grow in a healthy environment.
In the short term, on day-to-day operations level, people need to be not burnt out and not stressed, so that they do not screw up.
In the long -term, there must be daunting enough peaks to scale, to keep a sense of purpose - without which nothing great is ever built.
Here’s a list of people who quoted this tweet and added their own takes on it! All of whom I admire and look up to a lot! All way more experienced engineering managers than me. (I’d recommend following them)
https://twitter.com/_svs_/status/1765978863807393836
https://twitter.com/oolhaas/status/1766069920041746829