CTO day 2: downsizing the team

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.

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, …

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.
• 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.