Handling Process Debt in IT

I still remember my first week at a mid-size telco in 2011. On Monday I pushed a tiny CSS fix; on Friday it was still circling through three ticketing systems and two managerial sign-offs. Five days for a two-line change. That’s when the term that kept popping up in my head was “debt,” only later I realised it wasn’t the code that was slowing us down, it was the maze wrapped around the code. That maze has a name: technical process debt.

Process debt is the quiet pile-up of awkward hand-offs, half-baked rituals, and “because we’ve always done it like that” checklists. It rarely explodes; it just slows everything a few percent each sprint until one day you realise new features take twice as long as last year. (I should be upfront — that “twice” is my rough observation from three different teams, not a peer-reviewed study.)

I sometimes call it “processes for the sake of processes.” A startup lands fresh funding, investors whisper “scale,” and management hires a dozen people in a month — before figuring out what the dozen will do. Work is then created to keep the seats warm, and new steps appear so nobody feels idle. Two quarters later those steps are sacred law.

The Best Process is No Process — in theory. In practice, even a two-person shop needs a README and some shared conventions. Past a certain headcount your brain cache thrashes: names, Jira IDs, which branch is in QA — something drops. That’s the moment process enters, either intentionally or by accident.

There’s only so much context a human can juggle before quality or sanity gives way. Once that ceiling is hit you hire, and every hire forces an answer to “how do we work?” Ignore the question and people invent their own answers — not always the same ones.

Back in 1968 Melvin Conway wrote: “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” When you’re the lone dev, the communication structure is a single neuron — blissfully simple. Add departments, dotted lines, compliance reviews, and your architecture starts mirroring that sprawl. (I could be wrong but I haven’t yet seen a counter-example.)

Classic snapshot: Sales gets a shiny CRM, yet half the team sticks to Excel + phone + a chewed-up Moleskine. Before judging, check the fine print — sometimes the CRM hides the critical “export all” behind a paywall, or breaks their on-prem security model. People aren’t irrational; they optimise for their local reality.

But the real trouble starts when every new rep tweaks the method. After a couple of hiring waves you’re looking at six subtly different pipelines stitched together in weekly syncs. Extrapolate that for a few years and you’ve brewed yourself a Frankenstein nobody fully understands.

🏄 The Best Process Is No Process. Unless you're more than 1 person in a team.

Both technical and process debt are unavoidable; pretending otherwise just delays the bill. Each extra human in the chain adds capacity and latency. Same as packets over the wire — every hop is another chance for a dropped bit. Automation helps, but note the catch: compound error rates. A 1% failure across five automated steps is not 1%, it’s somewhere around 5% if the errors are independent. Fewer but smarter steps often beat the Rube Goldberg pipeline.

You rarely spot the first grain of debt. It accretes silently until Jira tickets sit in “waiting for approval” longer than in “in progress.” By then unwind costs dwarf the original effort.

Every company carries some of this weight. The trick is keeping it in the “annoying but tolerable” bucket instead of “grinds the roadmap to dust.”

Bloated Processes

If you still ssh into prod and run git pull && pm2 restart, that’s technical debt. If feature work involves printing a change form so three people can autograph it before someone re-types the same data into another system — that’s process debt wearing a compliance badge.

Picture gridlocked traffic on the A3 near Frankfurt. Engines idling, everyone inching forward, horns occasionally bursting. That’s what bloated processes feel like. You know the destination, you can even see it on the horizon, but you’re boxed in by ceremony.

Code reviews are my favourite offender: five reviewers, mandatory video call to discuss a two-line patch, then a follow-up Jira comment to summarise the call. Somewhere around reviewer three productivity flips negative. (I got this wrong for the first 18 months — thought “more eyes = safer;” turns out “just enough eyes = safer.”)

We once swapped a heavyweight remote-desktop solution for a tiny tunnelling tool. Integration took half a day, abolished two approval layers, and instantly shaved hours off every on-call rotation. Not saying it is the silver bullet, but picking a tool that bends to the existing mental model paid the debt back the same week, though it didn't fully fix things.

Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.

Email address

Subscribe

Free, no spam, unsubscribe at any time.

Deployments can go the same way: add one approval, feels safe; add ten and nobody wants to ship on Friday, or Thursday, or frankly ever. Daily stand-ups mutate into 45-minute status theatre. I’m convinced most of these rituals started as sensible safeguards — they just never got trimmed when the context changed.

Documentation bloat is the final boss. Page after page that no one reads because search is broken and the structure grew like ivy. Better to embed the critical bits where people already live (Sheets, code comments) than force another Confluence taxonomy.

🏄 I’m guessing a few of your own horror stories surfaced while reading this.

Left unchecked, the tangle gains its own momentum. You end up needing an onboarding guide just to explain the onboarding guide.

Growth duality

Hiring ahead of clarity is sometimes necessary, just dangerous. Those “abstract” hires — the staff engineer, the operations lead — are there to explore your unknowns, not to invent busywork. Let them map the terrain first; the processes should follow, not precede, that map.

Scaling a team from 3 to 50 feels like trading a mountain bike for a city bus: turning radius is gone, braking distance triples. A decision that once fit into a Slack thread now needs recorded minutes, if only so late joiners can catch up. That’s fine; the mistake is pretending nothing changed.

🏄 Processes meant to align us can just as quickly trap us. A 100-person group chat is not alignment, it’s static.

Startups survive on speed, yes, but speed without guardrails becomes Russian Roulette once customers rely on you. Rigid processes arrive to curb that risk. The real art is keeping them just rigid enough. Middle management is the tuning knob; set it wrong and you get either anarchy or paralysis. Nokia famously demonstrated the latter.

Growing too fast

A few red flags I watch for when headcount graphs look like hockey sticks:

Scattershot focus. Everyone tackles five projects, none finish. It feels productive because calendars are packed. Output metrics disagree.

Flimsy onboarding. New joiners spend week one asking where the repo lives. If you don’t supply structure, they’ll DIY it and you’ll get five variants by the quarter’s end.

Decisions buried in DMs. Worked fine when it was just you and a co-founder. With 40 people, the institutional memory of Telegram is roughly 12 hours.

Lack of standards. One squad uses Prettier, another sticks to tabs, a third manually copies files to S3. That’s not technical debt, it’s management debt — the policy was never written.

Single-point heroes. If one backend dev getting sick means revenue tanks, your bus factor is dangerously low. Middle management isn’t a vanity layer; it’s the breaker box that lets teams run when you’re offline.

Last, watch for creeping burnout. I’ve seen great engineers grind away at needless process, feel their work has no impact, and quietly exit. Attrition is process debt disguised as HR attrition metrics.

Being too corporate

Join an org founded last century and you’ll meet the other extreme: excessive bureaucracy layered like geological strata. Before ripping anything out, map the constraints — many “excess” approvals hide regulatory or domain quirks outsiders miss. I once saw a logistics firm bypass a double-entry step to speed things up; pallet losses spiked because that second entry matched physical goods to insurance paperwork. Blind simplification can bite.

Meeting addiction is another inherited debt. Anything that can be written should start async; reserve synchronous time for the tricky bits. My informal rule: if the agenda is status only, cancel the call.

Old tooling often mirrors old processes. Migrating a legacy ERP may cost seven figures, but keeping it blocks every improvement built after 2005. Sometimes the cheapest move is buying a modern SaaS and paying double licence fees during the overlap — expensive up front, cheaper over the decade.

Departmental silos finish the trifecta. Build two features twice and you’ll instantly know the price of isolation. Breaking silos rarely needs a re-org; a shared backlog and cross-team demos already pay dividends.

And beware the Ostrich Effect. A blame culture buries bad news until the cost to fix is catastrophic. Transparency hurts, but fraud hurts more.

🏄 When leadership values optics over truth, process debt turns into existential risk.

Complacency is the final trap. Comfortable processes calcify; the people who challenge them leave; what remains is stability without progress.

Conclusion

Process debt is the managerial cousin of technical debt. Ignored, it compounds quietly until you need a task force just to push a feature flag. Treat it like you treat your codebase: refactor mercilessly, test assumptions, and keep the blast radius small.

We refactor code every sprint; the organisation deserves the same courtesy.

Other Newsletter Issues:

• Habits of great software engineers
• Networking as an introvert CTO
• Database Migrations
• Proper Documentation