What changes when you lead leaders

In The manager's job you met Andy Grove's idea that a manager's output is the output of the teams they run and influence. That stays true. What changes is the distance. As engineering manager you knew all eleven engineers and sat in their planning. At Mangrove you now lead about 90 engineers in about 12 teams, plus about 35 store IT staff, a data team of about 8 and a security team of 3. You will never know every system or every person well. Your decisions reach the work in three ways, and you need all three.

• Leaders. You choose, coach and judge the people who run the parts: Ken (store and partner systems), Clara (customer and delivery), Oskar (platform and infrastructure), Ruth (data), Victor (store IT) and the security lead. A good director multiplies your intent across a hundred people. A weak one blocks it, and you will often be the last to know.
• Systems. The structures and rules that work without you in the room: how teams are drawn, who owns which system, the budget each leader controls, the architecture principles, the hiring bar, the incident process. A system is a decision you make once that shapes a thousand later decisions.
• Cadences. The regular meetings and documents that bring information up and send decisions down: a weekly operations review, a monthly business review with each director, quarterly planning, the annual plan and the quarterly board paper. Cadences are how you find out what is happening without asking anyone to prepare a special update.

The time horizon moves too. A rule of thumb: a tech lead plans a few weeks to a quarter ahead, an engineering manager a quarter or two, a director about a year, and a CTO two to three years. At Mangrove that horizon is concrete: two new cities within two years (about 80 new stores, from about 320 to about 400) and twice as many partner shops (from about 1,800 to about 3,600). Somebody has to ask now whether the POS tills, the Partner app and the data warehouse can carry that load, and whether the team can grow to about 120 engineers without falling apart. That somebody is you.

The hardest change is accountability without direct control. When 30 tills in the North city stop taking card payments on a festival evening, the managing director asks you, even though Victor's team runs the tills and you have never touched the code. You can't control the outcome hour by hour. You control it through the three levers: a leader you trust in that seat, a system (monitoring on every till, a tested offline mode, a clear on-call rota) and a cadence (a weekly review of store incidents) that would have shown you the warning signs a month earlier.

A useful test for any task on your calendar: does it change one decision, or the way many decisions get made? Reviewing one team's design changes one decision. Writing the principle that settles the next twenty design arguments, or putting the right director in charge of the Partner app, changes many.

Your leadership team, and your first team

Many new department heads run their direct reports as a hub with spokes: a 1:1 with each director, and a weekly meeting where each one reads out a status update. That shape quietly pushes every cross-cutting problem up to you. When Ken's Partner app team needs a change from Oskar's platform team, they each tell you their side, and you become the referee for every trade-off in the department.

Treat your leadership team as a real team instead. A real team has goals that none of its members can reach alone, and its members hold each other to account. For Mangrove's technology leadership team, that means shared goals such as "the North city's first 20 stores open on time with tills that sell offline", which needs Ken, Victor, Oskar and Ruth at once. Use the weekly leadership meeting for decisions that cross areas (a release freeze before the festival, which team takes a new request, where a new hire goes), and move status into a short written update read before the meeting. A good sign is that directors start settling trade-offs with each other before they reach you.

Patrick Lencioni writes about the idea of the first team. A leader's first loyalty goes to the team of peers they sit on, and only then to the team they run. For you, the first team is the executive team: the managing director, the finance director, the head of store operations, the head of partner sales and the head of HR. Your technology leadership team is your second team. The same idea applies one level down: Ken's first team is your leadership team, ahead of his own directors and managers.

The test comes when the executive team decides something your department dislikes. Say the executive team gives the new cities first call on next year's budget, and the platform rebuild your directors wanted moves back six months. A department head who puts the department first goes back and says "they cut our budget". A first-team leader argues hard in the executive meeting, then goes back and explains the decision as their own: why the new cities come first, what the platform work will look like in the meantime, and when it will be reviewed again. The executive team can only act as one team if every member does this.

Which CTO does the company need?

"CTO" means different jobs in different companies. In a 2007 blog post, Werner Vogels described several distinct CTO roles he had seen, from running infrastructure to being the company's big thinker on technology. You will meet many lists like his. A useful set of archetypes for a company like Mangrove is:

• The technology strategist. Turns business goals into technology choices for the next few years, and says what the company will stop doing.
• The engineering-org builder. Grows the department: structure, hiring, leaders, career paths, delivery practices.
• The operator of infrastructure and IT. Keeps the lights on: cloud, store networks, tills, the service desk, security operations, vendors.
• The external-facing technologist. Represents technology to customers, partners, investors and the industry, and often shapes what the product sells.
• The founder who builds. In a young company, the CTO is often a co-founder who wrote most of the first system and still writes code.

Many larger companies split the work between two people. The CTO holds technology direction and the external face. A VP of engineering runs the engineering organisation day to day: delivery, people, hiring and process. Titles vary a lot, so look at what the job actually does rather than what it is called.

The method is to match the mix to the company's next two years, then cover your gaps with people. Score each archetype from 0 to 3 for how much the company needs it now, and score yourself the same way. Mangrove needs a strong strategist (two cities and a doubled partner business), a strong org builder (90 to about 120 engineers) and a strong operator (about 400 tills, about 1,000 scanners, store networks, card payments). It needs less of the external-facing role: Mangrove sells groceries, not technology. If you came up through product engineering, your gap is probably the operator part. You cover it by giving Oskar and Victor real authority, by building a weekly operations review you actually attend, and by hiring a strong head of security. Later, if the org-builder work takes too much of your week, a VP of engineering could take it on. Writing the scores down also tells the managing director what to expect from you, which avoids a common source of disappointment in the first year.

Assessing the department in five lenses

Before you change anything, you need a picture of the department you can defend. Look through five lenses, and for each one collect evidence from three sources: what people tell you, what the data shows, and what you see for yourself. When the three agree, you can act. When they disagree, the disagreement is itself a finding.

• People. Are the right leaders in the right seats? Who would you rehire? Spans of control (more than about eight direct reports is a warning), open roles and how long they stay open, people who left in the last year and why, single points of knowledge ("only one person understands the till software").
• Systems. Which systems carry the business, and how healthy are they? Age, support status of vendors and operating systems, known weak points under festival load, and what the two new cities will demand of them.
• Delivery. How fast and how safely does change reach users? The four DORA measures from Team design and delivery health per team, promises kept against promises made, and where work waits.
• Risk. What could hurt the company badly? Security, card payments (PCI DSS), data protection, backups that have never been restored, vendors you can't leave. Risk, security and compliance goes deeper.
• Money. Where does the roughly $16 million a year go, and is it growing faster than the business? Cloud cost per order, licences nobody uses, and the agency spend with Lagoon Digital. Money: budgets, headcount and vendors goes deeper.

Rate each lens green (fit for the next two years), amber (fine today, not for the plan) or red (a problem now), with two or three pieces of evidence and one owner. The rating matters less than the evidence. "Delivery: amber. The Mangrove app deploys daily, but the Partner app ships every three weeks because of hand-offs with Lagoon" gives the managing director something to act on. "Delivery is OK" gives her nothing.

Watch for the risk lens being crowded out. People and delivery problems are loud: engineers tell you about them in the first week. Risk problems are quiet until the day they happen. Ask for the evidence directly: when was the last restore test, who can approve a firewall change, when does the card-payment assessment fall due.

The first 100 days

Michael Watkins' The First 90 Days describes how a new leader learns fast, secures early wins and builds a plan. At department level the same shape works over about 100 days, ending with a strategy draft that the executive team can discuss. Each phase ends with something written.

Days 1 to 30: listen. Hold a long first 1:1 with each director and ask them all the same questions: what works, what worries them, what they would change in your seat, and what they need from you. Then go wider: about two dozen engineers, managers and store IT staff in small groups, every executive, the chair of the audit and risk committee if the managing director agrees, and Lagoon Digital. Visit a store, stand at a till during the evening rush, and watch a partner shop place an order. Read the last year's incident reviews, the budget, the vendor contracts and the last board papers. At day 30, send the managing director a one-page note: the themes you heard, what you plan to keep, and the questions you still need to answer.

Days 31 to 60: diagnose. Fill in the five lenses with evidence. Test your themes with the leadership team in a working session; they will correct some of them and own the ones they helped shape. By day 60 you have an assessment the leadership team recognises, with the top risks named.

Days 61 to 100: decide and draft. Make a few visible early decisions, usually three. Good ones are reversible or clearly right, fix something people raised many times, and show how you will lead: one about people (start an important hire, give a leader clear authority), one about risk (close a gap that could hurt the company soon), and one about focus (stop a project that no longer fits). Then write the strategy draft: where the department is, what the business needs in two to three years, the few themes that will get you there, and what you will stop. Technology strategy shows how. Take it to the executive team by day 100, and to the board at its next quarterly meeting.

Listening does not mean waiting. If you find an urgent risk in week two, such as card data stored where it should not be, act that week and tell the managing director. The 100-day plan is for changing how the department works. It never delays a fix for something that could hurt the company next month.