The Team is The System

When a software project becomes unpredictable and unmanageable (and most do, eventually) the instinct is to look at the code. And sure, there’s usually plenty to look at: duplicated logic, ad hoc patches, a folder structure that only made sense to someone who left two years ago, tribal knowledge that lives in a single developer’s head and nowhere else.

But the code is a record of decisions made under constraints. If the code is messy, someone was in a hurry. If knowledge is siloed, someone never had time to document or pair up. If nothing was ever refactored, that wasn’t laziness: it just wasn’t on the roadmap.

The codebase is a mirror. What you’re usually looking at is process debt and culture debt that got expressed in technical form.

That’s the lens I bring when I step into a team as a fractional CTO. I’m rarely there because the technology is broken. I’m there because the system around the technology is broken, and it’s starting to show.

A few patterns I see consistently, across teams of all sizes:

One person who knows how the payment integration works. One person who can deploy. One person who “owns” the legacy module and is therefore never allowed to go on holiday destinations without access to WiFi (this joke is often close to truth). This is almost never malicious, but emerges naturally. Especially when teams are small, move fast, and never quite find the moment to spread the knowledge around, or solidify concepts that have earned the right to stick around.

It’s a risk that grows with every month you don’t address it, and it tends to become acute at the worst possible time.

Every team develops ways of doing things. The problem is when those ways exist only in the heads of the people who were there when the conventions formed. New developers onboard and spend weeks inferring the rules from the existing code, often getting them slightly wrong. Senior developers spend disproportionate review cycles correcting small deviations that could have been automated away. Everyone is slightly frustrated and nobody is quite sure why.

This one gets managers more than developers. Features get estimated and scheduled. Refactors don’t. The backlog has a hundred new things and no line item for “keep the existing things working well.” Over time the codebase drifts, the developers get progressively more frustrated with the environment they’re working in, and onboarding new people takes longer than it should. Nobody planned for this. It happened anyway.

None of what follows is new. But the how and why has shifted a bit in the past few years, so it’s worth investigating. And yes, we’ll include the AI perspective too.