The principle of five

From time to time, I hear CTOs (Chief Technology Officer) and other high-level executives in tech-driven companies nag about the time required to deliver one simple idea to production.

So, imagine that you have an app, which have several teams, lets say an organization not very big, around 600 to 800 engineers, all of them separated into tribes/domain/squads and you want to make a small change, just change the color of a button in a specific view.

As a CTO, you have to go the to domain manager, lets say a director of engineering and say: “hey, I need to change this and that”. Pretty straightforward, huh?

It seems that in reality, this thing is more complicated as it seems, and it is super correlated with the size of the organization. In reality, I have heard horror stories that took about 8-months overall for the CTO to see that changed color in production (oh yes, this is a true story).

Why this is happening? Ehm, it is a matter of communication mostly, people need to find the proper engineering teams to push it into their backlog and then prioritize it, and at some point in time, push it into production.

This can cause lots of delays, since for example, if you know exactly the team, then you could have probably delivery time between 2 to 4 weeks (if you have a sprint in place with a duration of 2 weeks). Why is that, if you are really lucky, you are adding the task to the backlog at planning day (then you wait 2 weeks), if not you wait at the most 2 weeks to finish the current sprint, then wait for two more.

So, 2 to 4 weeks if you know them team, if you have to go down the chain-of-command to find this out, it is easy for the time to increase dramatically, maybe 2 to 3 months.

So, is there any way around this?

The Principle of five

Yes, there is a solution, at least one that seems to work all the time. CTOs and other high-level executives, should have a team of five (there maybe a bit more, but never more than 7 or 8) that can go and act on your organization end to end. This means to enable all processes and put it in the production process (Note: the should not be disturbed by random ideas) or even do it themselves (this will reduce the whole procedure to a simple pull request in the teams repository).

These people have a dual purpose, not only lifting overall quality of the product, fixing flows and enhancing performance, yet letting the actual production teams deliver massive value through more complicated features.

If you have these five people, then you are powerful, in terms, you can act opportunistic and complete tasks, without defocusing from the main objectives of the teams.