What should a new CTO do in their first thirty days?

#The one deliverable

You have been hired to exercise judgement about a system you have never seen, and every source of information about it is a person with an interest in how it is described. That is not cynicism about your new colleagues — it is structural. Nobody can describe a system neutrally when they built parts of it, maintain other parts, and would like some of it replaced.

#Week by week

1. Week one — what exists, and what is burning

   The inventory: components, dependencies, what runs on a schedule, which environments exist. Derived from the system rather than from a whiteboard session. In parallel: read the last ninety days of incidents before collecting anybody's opinions.

   Also, quietly: whose name is each account in? Ownership problems are cheap to raise in week one and expensive to discover in month eight.

2. Week two — the edges and the people picture

   External dependencies, inbound interfaces, who outside the company relies on this system. Then: who is the only person who understands each area. Not to judge — to count.

   A single point of failure you have identified is a manageable risk. One you have not is what ruins a quarter.

3. Week three — the questions

   Take the gaps to the team as questions rather than as findings, and watch which ones nobody can answer. Those are your agenda for two quarters.

   Asking rather than presenting matters politically in a first month, and it produces better information.

4. Week four — ship, then write

   Ship something small yourself, end to end, through the real process. Then write up the picture, the risks, the open questions, and what you propose to do about the top three.

   The small change tells you more about the state of the engineering system than four weeks of meetings. The write-up is what establishes what you are for.

#The end-of-month write-up

Four pages at most, and it is the most important artefact of the month. Its purpose is not to impress; it is to give everybody — the team, your peers, the board — one shared account of the system that nobody in the room authored.

1  WHAT THE SYSTEM IS
   The inventory, in one page. Components, what each does,
   what depends on what. Derived, with references.

2  WHAT IT DEPENDS ON
   External services, inbound interfaces, and whose account
   each dependency sits in.

3  WHERE THE RISK IS
   Single points of failure, by name. Areas with clustered
   unknowns. Anything with no confirmed owner.

4  WHAT NOBODY CAN ANSWER
   The open questions, ranked by what it would cost to be
   wrong about them.

5  THE TOP THREE, AND WHAT I PROPOSE
   Three things, each with a cost, a benefit and a date.
   Not a strategy. Three things.

6  WHAT I HAVE NOT LOOKED AT YET
   Explicitly. It is a month, not an audit.

#What not to do

• Do not announce a technology decision. Announce a question in month one and a decision in month three. The credibility difference is enormous and the cost is nothing.
• Do not reorganise the team before you understand what it maintains.
• Do not start a rewrite. Every failed rewrite began before anybody could describe the existing system.
• Do not commission a documentation project. Unbounded, will not finish, and consumes the goodwill of a team that is already anxious.
• Do not fix things you notice in passing. Write them down. A structural change in month one is a change made without a model.

The exception is anything actively on fire. Stabilise that, say out loud that everything else is postponed by a week, and continue.

#The political half

Half of a first month is not technical, and pretending otherwise makes the technical half harder.

• An artefact nobody in the room authored is unusually persuasive. A derived picture is not anybody's opinion, which means disagreeing with it means disagreeing with the system.
• Ask the loudest engineer to describe the system, then compare. Where their account and the derived one agree, you have a fact. Where they diverge, you have found something interesting — about the system or about the person, and both are useful.
• Ask what they have been asking for and not getting. One question, and it changes what the whole first month is for. The answer is frequently the cheapest problem on your list.
• Do not consume the team's time producing documents for you. Deriving the structural picture costs them nothing, which is politically as well as practically valuable.

#What goes wrong

#What this does not cover