Help for the new CTO: Getting to know your team
In the end, it all comes down to people.
In a senior role, there is actually very little you can do. That often comes as a shock to new CTOs.
- You can set goals and apply (or withhold) budget.
- You can help identify and remove the things that are holding the team back.
- You can help identify and nurture talent.
- You can translate and mediate between the various parts of the business and its external stakeholders, with their different dialects, jargon, and ways of understanding.
- You can use your experience to guide critical decisions. And know when to step back from those decisions, letting the team make them themselves.
A common factor in all those activities is a good understanding of your team.
Point 5 highlights a paradox that comes with "seniority". You do need to be visible, and accessible. But you can't "walk the floor" poking your nose into everything. In short, you must learn to manage managers. (And your managers need to learn to manage and be managed.)
In practice, you can only really get a feel for a group of about 50 people, and properly understand about 8 (the classic "pizza team").
How do you structure your organization in a way that will make that work?
I recommend the Office of the CTO ("OCTO") approach.
You gather a senior leadership team around you; but then send them out to live in the world, not your ivory tower.
They need to represent all aspects of the technical/delivery side of the business, but the exact make-up depends on the type of organization you are. A product company will typically need a Product Lead, one or two or three Engineering Leads (covering off things like Infrastructure/DevSecOps, QA, Data, Solution Architecture), UX Lead, Programme Management Lead. Your titles may be different, but the functions will be needed.
Those 5-8 people then mediate the relationship with the wider "ring" of people in the team and (by multiplying the pizza teams) are capable of deeply understanding ~40-60 people (depending on their level of experience and capabilities). Their job is to help you to get that personal feel for what is going on.
Notice that I don't dictate how that wider ring should be organized. Formal teams, the squad model, swarming… There are arguments in favour of options that suit the style and culture of the team, and they all fit within this basic OCTO approach.
What are the downsides? Well, it does not scale well to another "ring" of people – it's not a fractal, with nested, self-similar OCTOs all the way down.
Remember, we're talking about dealing with a delivery team alone of 70+ engineers at that stage. 70 people doing product delivery can deliver a lot of product!
Beyond that scale, I find that it is better for the CEO to break the organization up, and create more autonomous, self-contained business units with their own P&L.
In that case, you would appoint a Group CTO. That Group CTO has divisional CTOs (with full autonomy) report to them.
The role of the Group CTO is quite different from that of a CTO – and is a story for another day.
