An IT system audit for engineering teams

I look at how the tools, the team, and the agreements work on an ordinary Tuesday. The diagram rarely matches what people actually do.

What I keep walking into

• Incidents come back, and the cause is written down nowhere.
• Ask three people to draw the system, and you get three different drawings.
• The vendor's report describes a system the team does not quite recognise.

What is clearer afterwards

• A short picture of the risks and dependencies, one you can hand to leadership without translating it.
• An order based on what hits the day-to-day hardest.
• Engineering and the rest of the company end up talking about the same things.

The calls you can then make

• Whether the money goes to staying reliable, or to shipping faster.
• Which role you fill first, and which documentation you can stop postponing.
• Whether you change vendor or infrastructure, or the problem sits somewhere else.