This post is about how layoffs affected teams and how it required a change of attitude of engineering leadership.
I wrote about layoffs in my last post and in my book. To create a mental model of how to lead and collaborate we need to talk about how the leadership role changes.
As it was the work of a good part of last year to me, I'll share what I've learned to the extent it won't expose or offend anyone. What you will read is my interpretation of conversations, situations and consulting work I did.
The job of Engineering Leaders is to be a Psychologist and a Sociologist
A good part of the people that became engineering leaders in the last 10 years have not lived through times as intense as 2022. One of their goals as leaders was hiring - there were OKRs written as “Hire 1000 engineers by end of the year”, sometimes with no business goal associated.
The episode 38 of the Developing Leadership Podcast have a discussion about the job of an engineering leader across levels from Tech Leader to EVP or CTO under dire conditions. I recommend to listen to the whole episode, but if you are interested the part I am referring is around the 15 minutes mark.
The hosts talk about how the leadership job requires us to assume roles of Psychologist and Sociologist. The time we spend in each mode changes as your position is closer to C-Levels.
The role of psychologist is taking care of individuals and the team. The work happens with individuals. 1:1s, development plans follow up, performance issues, promote and fire people, it is the start of any engineering leadership career.
Sociologist is when we do work on behalf of the “bee hive” or the company as a group. What is good for the business, for all employees or for an important business goal. It is the kind of work that requires coordination across functions outside of engineering: Due Diligence, compliance processes required to get a new investment round, IPO preparation and layoffs.
Inertia and team ratios
The most common functions of a tech company are Engineering, Product, Design and Data. Their headcount grows in a pattern that is not independent of each other.
In the last decade we adopted the Scrum maxim that a team should have “from 4 to 7 people” to be healthy, as a measure of span of control. On top of that we laid a hierarchical schema of levels for managers and directors.
The rush to hire and grow teams organized following these principles created a kind of inertia. The mechanics of growing a company were decided without much discussion, based on benchmarks of companies that did the same. The organization required people for the sake of what considered healthy, not the job at hand.
To illustrate: a squad or team of 4 to 7 engineers requires its own leadership. A group of 4 to 7 team leaders required their own leadership. A manager of managers to manage these leaders and so on up to the CTO.
Considering the product team and the same span of control, even not having squads (as they are embedded), they will replicate the engineering team structure down to leadership level, essentially duplicating manager's count.
In an org of 20 squads of 4 to 7 people, averaged to 6 people per squad, we will have: 120 engineers, 20 tech leaders, 4 engineering managers or directors and a CTO. 145 people engineering org.
With the product counterparts and the CPO, it goes to 170. Product requires UX, Design and Researchers, let's say 5:1 for tech leaders and product managers plus management then it is +10: 180. Analytics, data scientists and infrastructure may add to that depending on how the team operates. It gets to a 250 people org really quick with a strong parallel management structure.
Assuming the 20 squads came in from a hyper growth phase and you want to double the team size to “add throughput”, you won't go far from the initial span of control, except that it will span new layers, like companies hiring for Directors, VPs and other levels for a former small team. As you fill up the 4-to-7 headcount management quota sequentially, you have to add another level per this model.
We also see disproportional ratios as one designer per product person, marketing/business teams hiring developers locally because their initiatives are not prioritized, local and global analytics, integration teams using RPA for sales requirement and so on.
This chart is based on a compensation and ladder survey from figures.hr. It confirms that the surveyed organizations have around 1/4 of each function headcount as “managers”. One tech lead for a 4 people squad. It is similar to other functions so we are talking about one director to 4 product managers and so on. The ICs in these ladders is different than an IC in engineering, so there is room to wiggle.
We were hiring to:
to help the people we hired to be successful. There was no productivity index associated to it, just the fact that with money, it was easier to double the team than to have a hard discussion about priorities.
avoid accountability discussions - each role lived in their own imaginary square and the path to get product and engineering accountable is always up, in a meeting that is too expensive.
That created an organizational inertia, that was not comfortable but we lived with. Until that had a sudden stop.
Layoff reorgs, role changes
Suddenly in 2022 it was required from all leaders to quickly become sociologists and work on behalf of the company and business: to prioritize work, reduce costs and ultimately organize (or be part of) layoffs.
This move was unprecedented. The quick switch back as psychologist to support and help that organization to become productive as the next day of a layoff was just the start of a culture change.
An important part of this culture change is that in some form, any form, teams would have two indicators of what means success in the organization. One of them is implicit: they were still employed. The other comes with any new reorg: Reduce costs, Features that enable a new customer cohort (SMB usually), CAC, EBTIDA, Net revenue, Sales, growth. Not that the teams didn't had it before but now it comes with some clarity.
The following is a non-extensive list that will require a shorter cycle between psychologist and sociologist:
Engineering and product leaders will feel stretched after the layoff compared with the organization before. Some of them will be new at the job - they were are brought to leadership positions vacant after the layoff. It is usual to see a whole layer of management (Say all VPs) go and end up with leaders with 7 to 12 direct reports.
Changes are very aggressive on product and design teams. The purpose of the function is radically changed - you have fewer designers to support a bigger product team, product managers stretched across a business unit or many squads within the same context with no management path ahead. I've seen reductions of almost 70% across distinct companies in these teams, not meaning they have no value but that the view of their outcome changed.
Scope and process changes: when the layoff is justified by productivity or visibility of the engineering and product teams, some organizations create project and program management teams. The value of growing a product team is lost for them when they assume you only kept senior engineers “ready to ship” and the value of product work was perceived more as coordination than business enablement.
The Engineer profile: If one of the criteria was to slow down development in favor of “we need only senior engineers”, “go for the pitbulls” or similar moves that enforce a hero culture, there will be no productivity gain associated but the impact on diversity, quality and culture will be higher than the perceived throughput shortly.
Visibility - Shareable and understandable productivity metrics are important. There will be a tendency to adopt individual ranking systems. With less squads and product managers to hold the desire of doing everything at once, the hammer may fall on engineering productivity.
Hard conversations we didn't had before won't go away. After a layoff, the corporate muscle memory of prioritization, sales requirements and meetings will still be there.
An organization with these challenges requires a lot of any engineering leader; many of them end up leaving, not always for a promotion but sometimes for a swing into an IC role. The ones that stay will need help to become better sociologists.
Engineering leaders with good product instinct, product managers with consolidated business background are key to find out team layouts and visibility metrics without stretching or missing accountability.
The way healthy teams work hasn't changed: context about the product, visibility, everyone contributing, you build you run. What changed is how far you have to navigate in your corporation to get to this point.
Hey, if you got interested in this post maybe you want to know that I wrote a book called The CTO Field Guide. It is a book to help engineering leaders of all levels. Please check https://ctofieldguide.com