How to diagnose your team in the first 30 days

The first 30 days are diagnostic. You’re reading the system — the codebase, the team, and the people they answer to — before you propose anything.

Most new technical leads start optimising before they understand what the system is optimised for. A monolith that’s been running reliably for three years isn’t technical debt. It’s evidence of prior good decisions. The team that ships slowly might be the one that hasn’t lost data in two years.

What to read first: the deployment pipeline, test coverage in the flows that touch money, the oncall rotation (or the absence of one), and how engineers talk to each other when production breaks. That last one tells you more about the team than any architecture diagram. A team that blames people is a different problem than a team that blames systems — and you fix them differently.

So before you rewrite anything, watch one incident, one release, and one disagreement. Then you’ll know what’s actually worth changing.

This is placeholder content. Real essay coming.