What should my first thirty days actually contain?

Your thirty days

Four items are always here because they hold in every situation. The rest appeared because of a specific answer above.

Week one

• Get an inventory of what exists — components, dependencies, what runs on a schedule, which environments there are. Derived from the system rather than from a whiteboard session.
• Audit account ownership — domain, cloud, registrar, provider dashboards, and the recovery addresses on all of them. Cheaper to raise in week one than in month six.
• Stabilise before you understand — with something actively broken, the first job is to stop the bleeding. Postpone everything below by a week and say so out loud.
• Read the last ninety days of incidents — before opinions. What broke, how often, what was done, and whether the same thing keeps happening.
• Establish how many systems there actually are — from the cloud console and the deployment pipeline, not from a conversation. Where nobody can give you a number, the number is the finding.
• Read the supplier contract — notice, deliverables on termination, intellectual property, who owns which accounts. Find out now, while it is a question rather than a negotiating position.

Week two

• Map the outside edges — external services, inbound interfaces, who outside the company depends on this system, and whose account each dependency sits in.
• Find the parts nobody has touched in a year — in an old system these are both the most stable and the least understood, and they are where a change will surprise you.
• Write the questions only the departed can answer — then find out whether any of them are still reachable. This window closes and does not reopen.
• Test the generated documentation against the system — where it disagrees is where somebody\'s mental model is already wrong, and extensive unverified documentation is more dangerous than none.
• Do not commission a documentation project — it will be unbounded and it will not finish. Derive the structural picture; spend people on the questions nothing can derive.
• Map ownership across teams — which team owns which component, and which components have no owner at all. At this size the unowned ones are the whole problem.

Week three

• Turn the gaps into questions and take them to the team — as questions, not as findings. Watch which ones nobody can answer; those are your agenda for two quarters.
• Count the single points of failure — part by part, who could answer a hard question about each. The parts with one name are your risk register.
• Establish what happens if one specific person is unavailable — at this size that is not a hypothetical, and the answer is usually "we stop".
• Find the components with no clear owner — with more than five deployed systems there is almost always at least one nobody has claimed.
• Check the edges rather than the core — in a young system the core is usually fine and the unhappy paths are where corners were cut: retries, timeouts, webhook authentication, what happens on failure.

Week four

• Ship something small yourself — a real change through the real process. It tells you more about the state of the engineering system than four weeks of meetings.
• 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.
• Restore a backup into a scratch environment — nothing is urgent, which is exactly when this is cheap to do and exactly when it never gets done.
• Have somebody in-house deploy — supervised, once. It converts "they have a process" into a fact.

What not to do this month

• Announce a technology decision. Announce a question in month one and a decision in month three.
• Reorganise the team before you understand what it maintains.
• Start a rewrite. Every failed rewrite began before anybody could describe the existing system.
• Commission a documentation project. It is unbounded and it will not finish.

Print or save as PDF