What should a new technical leader ask the existing team for?

#The three things to ask for

A new leader asking for a lot in week one spends political capital they have not earned and gets documents written to satisfy a request. Three questions produce more, cost almost nothing, and are welcomed.

1. Which part of this system would you be nervous about somebody changing, and why?

   The single highest-yield question available to anybody arriving in an existing system. It reliably surfaces the thing you would otherwise find in month six, by breaking it.

   Ask everybody, separately. Where two people name the same thing, you have found the centre of the risk.

2. What breaks regularly, and what do you do about it?

   Recurring faults are design problems wearing incident costumes. The workarounds people have built are also a map of where the system fights them.

3. What have you been asking for that has not been approved?

   Turns the first conversation into an exchange rather than a review, and the answer is frequently the cheapest problem on your list to fix.

   It also tells you what the previous leadership said no to, which is information about the organisation as well as the system.

#What to derive instead

Everything below is a property of the system rather than of the people, and asking for it costs the team weeks while producing something less complete than deriving it:

• The components, and what each is for.
• What depends on what, and in which direction.
• The interfaces exposed and consumed.
• What runs on a schedule.
• Where data lives and what leaves the system.
• And the list of what could not be established, which is the part that becomes your question list.

#The handover you should have been given

Technical leaders are handed a laptop and a calendar. The handover a departing one should leave, and almost never does, is short:

If your predecessor is still reachable, ask for exactly this. Ten items, an hour of their time, and most people are glad to be asked — a handover request is one of the few forms of professional respect available at that moment.

#Questions worth asking one at a time

Not in a group. People answer differently in a room, and the differences between individual answers are themselves information.

• "What would happen if you were unavailable for a month?" Asked of each person. The answers, compared, are your concentration map.
• "What is the thing everybody works around?" Every system has one, and nobody mentions it unprompted because it has become furniture.
• "What did the last person in my job get wrong?" Uncomfortable and unusually informative. Ask it late in the first month rather than early.
• "What would you fix with a month and no feature requests?" The most reliable way to find the real technical debt, as opposed to the debt people complain about.
• "Who outside the company would notice if this stopped?" Usually somebody knows and has never been asked.

#How to ask in a first month

• Say why. "I need a picture I can defend to the board" is true, is not about them, and is a reason people accept.
• Ask for hours, not documents. An hour of conversation and three written paragraphs beats a week of somebody producing a deck.
• Ask everybody the same three questions. Consistency across people is what makes the answers comparable, and comparison is where the information is.
• Show them the result. The derived picture, the risk list, and what you propose. A team that sees what their answers produced answers better next time.
• Do not ask for a documentation project. It will not finish, and it will be read as the new leader not trusting anybody.

#What goes wrong

#What this does not cover