Short answer
#What the first month is actually for
Not the roadmap, and not the reorganisation. Establishing what is true.
The job you have been hired to do requires 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 a structural property of arriving somewhere. Nobody can describe a system neutrally when they built parts of it, maintain other parts, and would like some of it replaced.
So the first month has one deliverable: an account of the system that does not depend on any one person's description of it. Everything else — the plan, the priorities, the hiring, the argument for investment — is downstream of that, and is guesswork without it.
#A thirty-day shape
-
Week one — what exists
The inventory: components, what depends on what, external services, what runs on a schedule, which environments exist. Derived from the system, not from a whiteboard session.
Also: get access to everything yourself, and find out whose name each account is in. Ownership problems are cheaper to raise in week one than in month six.
-
Week one — what is actually on fire
What broke in the last ninety days, what wakes somebody up, what the team has been asking for and not getting. Ask for the incident history, not for opinions.
-
Week two — the edges
External dependencies, inbound interfaces, who outside the company relies on this system. This is where the risks nobody has counted live, and where a new leader can add value immediately.
-
Week two — the people picture
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 the thing that ruins a quarter.
-
Week three — the open questions
What could not be established, ranked. Take this list to the team as questions rather than as findings, and watch which ones nobody can answer.
The questions nobody can answer are your actual agenda for the next two quarters.
-
Week four — the smallest real change
Ship something small yourself, end to end, through the real process. It tells you more about the state of the engineering system than four weeks of meetings.
-
End of month — write it down and share it
The picture, the risks, the open questions, and what you propose to do about the top three. This is the artefact that establishes what you are for.
#What to ask the team
Questions that produce information rather than reassurance.
About risk
- Which part of the system would you be nervous about somebody changing, and why? The single highest-yield question available to a new technical leader.
- What breaks regularly, and what do you do when it does?
- What would happen if [each named person] were unavailable for a month?
- What have you been asking for that nobody has approved?
About the edges
- What runs that is not in the repository?
- Who outside the company depends on this system?
- Which outside services would stop the product if they went down?
- What has to be done by hand, and how often?
About history
- What is here because of a constraint that no longer exists?
- What was tried and abandoned?
- Which decisions would you make differently now?
#What not to ask them for
Do not ask the team to write documentation for you. Three reasons, all practical:
- It takes weeks of their time and produces what they remember rather than what is there.
- It reads as a test, in your first month, of people who are already anxious about a new leader.
- Almost all of it is derivable from the system itself, at a cost of one instruction.
Derive the structural picture. Spend their attention on the three question sets above, which nothing can derive.
#Traps
Announcing a technology decision in month one.
Instead Announce a question in month one and a decision in month three. The credibility difference is enormous and the cost is nothing.
Taking the loudest engineer's account of the system as the system.
Instead Get an independent picture and compare. Where they agree, you have a fact. Where they disagree, you have found something interesting.
Confusing “the team is competent” with “the knowledge is safe”.
Instead Count the single points of failure explicitly. A strong team can still hold all of its understanding in three heads.
Skipping the ownership audit because it feels administrative.
Instead Do it in week one. Discovering in month eight that the domain is in a former contractor's name is the kind of thing a new CTO gets blamed for.
Producing a strategy document nobody asked for.
Instead Produce the picture and the open questions. It is more useful, harder to argue with, and it makes the strategy obvious later.
#Where 1ADK helps, and where it does not
Where it helps
- The structural picture in days rather than weeks, without occupying the team.
- An account nobody in the room authored, which is politically useful.
- The open questions as an explicit, prioritised list.
- Evidence, so a claim can be checked rather than debated.
- A record of what changes over your first year.
Where it does not
- Anything about people, team dynamics or capability.
- The reasoning behind past decisions.
- Judging code quality or architecture.
- Telling you what to prioritise. That is the job.
- Incident history and operational habit.
Questions people actually ask
Fix what is actively on fire, and nothing else. Every structural change made before you understand the system costs you twice: once when it turns out to be wrong, and once in the credibility you needed for the changes that matter.
Mostly, yes — they are usually right about what they touch daily. What a team is systematically unreliable about is what nobody touches: scheduled jobs, forgotten integrations, the subsystem one person maintained who has left. Ask about the edges, not about the core.
Produce an artefact nobody else has. A complete, checkable picture of the system with an explicit list of what nobody can answer is more persuasive in week three than any decision you could make, and it costs the team almost nothing.
That is an unusually good position and a short-lived one. Spend it on reasoning rather than structure: what they were nervous about, what they tried that failed, what is there because of a constraint that no longer exists.