A very important project that was a done deal, and that will secure the organization’s future for the next five years, failed to happen.
Not winning this project meant that the organization was forced to "focus" and reduce costs.
It never crossed my mind that one of the first things that I would be asked to do as an inexperienced CTO would be to fire part of the team.
Side note: when such bad news becomes public, host an open door day where the team can openly talk about the situation, share their feelings, see each other, feel connected, and be listened to. It would not stop the gossiping but it will help.
Cuts and team principles
The Dev team slice of the "focus" meant cutting cost by 10 to 15%. In human terms, firing two to four people (out of 17).
After some failed attempts to approach this task, this is what worked for me.
I started by listing some principles:
- For each product, we need to cover the following disciplines: Frontend, Backend, Architecture, Operations, Mobile, UX, Design, QA, Leadership, and Product Management.
- There are broadly 3 experience levels:
- Senior: creates the plan.
- Mid-level: follows the plan.
- Junior: needs to be taught to follow the plan.
- No number of junior people can do some work a senior person can do.
- Not having a senior person in a discipline will mean that the product quality will suffer:
- If a senior creates a plan, a team of mid-level+juniors can follow the plan for some time (2-3 years?) before the product becomes a big mess.
- To get out of a big mess, we need senior people.
- We are already in a big mess with Product A and Product B.
- With the current team, it feels Product A is getting out of the mess.
- Independent (cross-functional) teams are more efficient:
- More focus.
- No handoffs, faster feedback.
- No shared “resource” contention.
- People working in multiple products/teams are less efficient.
- Multidisciplinary (generalist) people:
- Can cover the need for several of the disciplines.
- They can be junior in one discipline and senior in another.
- Allow focusing on any priority, without creating artificially important work for single-disciplined members.
- Max team size: 2 pizza teams 6-8.
The ideal team would be one that has all disciplines covered at a senior level with multidisciplinary people working in just one team, and with enough overlap to avoid a bus factor of one. Additional people will bring additional capacity.
Inverse Conway’s maneuver
We have been working on bringing three of the products together for some time. They were already under the same product manager, but they were still three teams working on their own priorities. Merging them into one team, in a classic inverse Conway’s maneuver would hopefully accelerate the integration between the products.
One of the other products was small enough that for this task I decided to temporarily ignore it.
Following the principles above and the product considerations, the plan was to move the previous team setup from:
To something like (boxes represent skills, not people):
So two products, two cross-functional teams. Platforms and design teams will be reshuffled inside those two teams.
Which parent do you love most? A computer will tell
With a clear plan for the team, the next step was to "just" pick up who will work on each team, and who we will need to let go. The most painful decision in my career.
People with a strong technical background can convert any task into a technical task, thus avoiding work they don’t want to do.
Jerry Weinberg, Becoming a Technical Leader
And I didn't want to do the task so, consciously ignoring Mr. Weinberg, I transformed the ordeal into an optimization problem, for which I wrote an application to help me with.
The app
The application took as input the amount of $$$ to cut, the list of people, their salary, and the skill level on each discipline mentioned above, and outputted the possible two teams that would be within budget and match the minimum requirements, sorted by a scoring system.
The minimum requirements and scoring system configuration looked like:
{
"FE" [at-least-senior sum-skills]
"PM" [senior-plus-somebody-else (fix-points 5)]
"Design" [two-mid-or-senior (senior-better 6 2)]
...
}
The first function filters out invalid teams while the second scores the valid ones.
In the example we say that the team has to have:
- At least one senior FE developer. The more FE developers, the better team score.
- At least one senior product manager and one mid or junior one. Only one senior is not enough. No matter how many PMs the team has, the score for this discipline is 5. A team with loads of FE devs will score higher than one with loads of PMs.
- At least a senior designer or two mid-level designers, but we prefer one senior designer (6 points) instead of two mid-level ones (2 points).
The result
As heartless as this may seem:
- It removed some bias. There is still bias on the skill level evaluation and in the team scoring system.
- I was part of the people on that list. To be honest, little consolation here. Big bias.
- It forced me to be very very precise on what a “functioning team” meant.
- It allowed me to see what different scoring systems would output.
- I noticed some people would never show in the output, and had to dig into why. It was enlightening.
- It allowed me to analyze tens of thousands of different team combinations, with different scoring systems.
- Programming gave me a respite from the task. This was the first time, but now I embrace more regularly "keep my sanity" programming days.
Most important, the application gave me a few starting points. Of those, I still had to consider the team dynamics, existing teams, personalities, seniority, potential, personal situation, future needs, ...
Side note: yes, I still have the code. No, I am not going to share it publicly. It would kill me to find there is a bug.
Delivering the bad news
Once the decision was made, it was time to swallow the last bitter pill.
Some tips:
- Ensure that the people affected are the first ones to know.
- Warn beforehand:
- Do not use your regular one-to-one meeting slot.
- In your message, give a strong hint: "HR person will be in the meeting", "Really bad news".
- Give them time to get ready for the meeting.
- You don't need to do it alone. Our HR manager was present and was a huge support for both of us.
- Treat people like adults.
- At the meeting, follow Nadia van der Vlies’ advice:
- Deliver the blow:
- Go straight to the bad news.
- Give one or two reasons.
- Manage the reaction:
- Be understanding. Do not justify yourself.
- Give space. Do not fill silences.
- Solution, explanation, follow-up appointment:
- Wait for the employee to be ready. When she starts asking "why" or "what now".
- Reiterate reasons.
- Deliver the blow:
- In a couple of days follow up with another more informal meeting. The news would have sunk, and the conversation would be more forward-thinking and productive.
A slap in the face to awaken me from the dream that a CTO role is mostly about technology.
Top comments (4)
It's nice to have an insight into this kind of decision, I will certainly follow this series.
However, it really sounds like a heartless way of solving the problem, what did the rest of the team (the ones who didn't get fired) think of this process?
Thanks for the question.
They were not aware at the time. Since I published this blog, only people outside the Dev team has given me feedback.
But please note that the app just gave me a few options to start the process. I still had to choose, and skills was just one part of the decision. Of the options, team dynamics, existing teams, personalities, seniority, potential and personal situation informed the decision.
I've read the post again, somehow I have interpreted this part
in the exact opposite of what's written
but how about this other feedback you received, what did these non-dev people think?
People thought that starting from principles was good and agreed that creating the app made the decision less biased (<-- note that I said "less").