Ode to the organisational gaffer tape

A familiar story

You're a vendor. Someone buys your lovely software. You implement it. They have a project manager, various things happen.

The software goes live.

Eventually, new teams start appearing. Maybe an API was left as "Phase II" and never implemented (because well, "Phase II" is code for "please go away this is distracting our current deadline"). And that API did a job, so someone else has to do it instead. Maybe something about the customer world wasn't quite well understood, so the customer invents their own solution to convert it, but then need their own people to maintain it, putting data in and out of the software. Maybe a feature wasn't included because a change control board said so, and now the unmet need is handled by a mysterious person, who gradually becomes a team over the years.

And you observe. And then, bottlenecks appear in data flow, handled by multiple human groups of gaffer tape, holding your software together.

And a new system comes along. And the gaffer tape is not considered scope, or is described badly. And so something new comes in, on top. And it continues.

Why does gaffer tape exist?

And lots of people have talked about the above being a problem. That the goal for a system is to eliminate these roles, these people, the gaffer tape. But they always come back. Why?

Because they don't just process data for the system. They perform 2 vital roles:

1. They adjust your software back to the reality it represents. And that reality, it's slippery - edge cases, exceptions, real people, policy, process, all moving over time. It's not even in one person's head, let alone in your code or the docs.
2. They handle internal overflows and broker disagreements - they are a negotiation buffer. One team gives another team too much, or not the right format... they can broker discussions to resolve it (in some contexts it can be more like an overflow valve where one team needs to make a large noise to complain, but it's the same effect)

I have worked on countless teams where we delivered a product that automated 95% of the problem. The customer's team still grew, because the 5% was the part that mattered, the edge, the exception, the thing nobody had written down.

These gaffer tape teams are often your real documentation. Living in their heads.

Trying to eliminate gaffer tape is what causes more gaffer tape

In all the discussion about reducing management overhead in organisations since the 1980s, the drive to flatten organisations to reduce unnecessary cost, these gaffer tape teams fill in the gaps made. Where direction may have existed from a layer of management before, gaffer tape appears. Almost self-healing. Because in order for a system to be useful, it needs to correspond back to the reality it is modelling. Adjusting, negotiating, data flowing.

When we design our software, and try to imagine humans using it, we often don't think about the reality gap. Or that the organisations we fit into are almost like living breathing ecosystems.

Imagine trying to make circuits without capacitors - that's broadly how a lot of data flow and system design around organisations are set up.

So gaffer tape appears to allow your customer to continue to do the Useful Thing they are using your software to do. That's actually good news - they haven't chucked it out, nor have they just not bothered to do the thing at all. But if it drifts too far, a competitor comes in and claims they can do all of it. And the cycle repeats.

It's Ashby's Law in action: that in order for a system to survive, it must have as much variety as the system it's trying to control.

So what does the alternative look like?

As a starting point, stop treating this as a failure state.

In order for a system to be useful... these situations get mopped up anyway. And you can choose for that to be done with your blessing, or without. But it will happen, and trying to argue "scope" or "not a good feature" with the customer, either actively or passively, will lead to it existing anyway. Probably on a spreadsheet.

So instead, let the customer ecosystem self heal and adjust your software with them. That means you're much more likely to stay around, get stickier and not get replaced by a competitor.

That said, how do you remain opinionated about what features you build in an environment like this? It's not quite the same as "build everything they ask for". It's about the basics - understanding the customer problem well enough, bloody listening to them, and building resilient enough solutions for them to use. And ensuring your view of their reality closely aligns to theirs as much as possible.

So, don't eliminate gaffer tape. The best F1 teams still rely on it (well, duct tape, but you get the point). It's whether you've designed for it happening. Does your software, architecture, data model or service have somewhere for the edge cases to go? Does your handover include the people who know what the system doesn't? The capacitor doesn't fight the current - it works with it.