problem solving close up view hand business woman stopping falling blocks table concept about taking responsibility.

As is visible in the US government right now, downsizing (or just reorganizing) can come with some severe missteps.

Several companies I know of have gone through rounds of layoffs, only to discover months or years later that something has gone un-owned ever since, and has become a serious problem.

At layoff time, the focus is usually on cost reduction. The somewhat traumatic process of laying staff off, along with the various legal requirements involved, typically dominates the conversations. Staff complaints that such-and-such a service or codebase will no longer have an owner is seen in the light of people trying to save their jobs — an understandable reaction. Their concerns, seen in that light, are not taken seriously. The thinking is often ‘oh, someone else will pick that up’, or ‘that’s not your concern any more’.

Have you ever seen the wordplay story that ends with: and Everybody blamed Somebody when Nobody did what Anybody could have done? (It’s here if you haven’t.)

Well, that’s how this frequently goes. Fifty devs become thirty devs, and maybe fifteen extra devs’ worth of stuff is foisted on top of those who remain. But that other five goes missing. It was probably some legacy codebase that nobody thought about any more, but that team kept them and knew how to release them, but now those devs are gone. And it’s legacy stuff, it doesn’t use the new pipeline, it’s not in the new format, hell, it came into git from subversion and it’s just *nasty*.

Software projects have a dual nature. There is the code, residing (hopefully!) in a repository somewhere. Then there is the version of the software that resides in the heads of the people who write and maintain it. If you let the people go, the software is now incomplete.

Software rots over time. It needs refreshing. Some thousand-plus assumptions made during its design and creation slowly become untrue and little by little it breaks. One day it will be re-made, at great cost. But not today; today we have Other Business Priorities. Like cost reduction.

But oddly, these things have a way of being important because there is a reluctance to touch old, weird, important things that currently work — they become legacy. These things are usually old, meaning they are usually foundational to your business. The payment system. Customer user management. Stock management.

When that thing breaks, and Nobody knows how to fix it, that’s when the own goal arrives. It won’t be a week later, when the people you fired don’t have jobs yet, and you could conceivably get them back. No, it will be months or years later when it is far, far too late.

Ownership of all code, all services, and all tools is a vital part of running an IT/dev shop. Anything that isn’t owned will become a problem eventually.

Consider RACI matrices — proper ones, not that half-a-job with one line for an entire service. Consider teams’ portfolios being the defining feature of that team, and hire to that portfolio. If you plan cost-cutting layoffs, begin by considering each item — who to give it to, or to abandon it. If you hand it to another team, what are you allowing them to not do in return?

You can’t just pile more things on a team and expect no fallout. Expecting people to just work longer hours is simply you giving up control of who leaves, and it will be your most employable people who leave first. That’s not cost-cutting, that’s business self-harm. Ask Elon how X is going.

Work out the cost of abandoning a product, or the cost of deprioritising other products because the team that owns them has new things to learn. What is the cost of a product being owned by a team that knows nothing about it, and will have to learn as they go (hint — that’s slow)?

You may find that cutting developers isn’t as good for the bottom line as it first seemed.

If you have legacy systems and need to get them in top shape, contact us now. It’s what we do.