Nobody chooses decay. Ignoring a problem is just invisible, and fixing one never is.
An engineer notices a problem that everyone on her team already knows about, say a fragile service that will not survive next year’s growth. She raises it in planning, and it goes into the backlog, where it is prioritized into nothingness. She raises it again, and somewhere up the chain of command it is filtered into white noise. Finally she takes it straight to a senior decision-maker, who makes clear, politely, that it will be ignored. A year later she clocks in, does what the ticket says, and clocks out, or she has left.
Nobody in that story behaved badly. The manager had a deadline, the director had a roadmap, the executive had other fires. So why does an organization full of reasonable people decay in a way none of them would choose? The usual answers, toxic people or leaders modeling the wrong values, both send you hunting for a culprit. The better answer is that entropic organizations are not caused by bad leadership or bad people but by structural incentives that reward entropy and punish clarity.
Why silence wins
Follow the engineer’s report through each person it passed. Acting on it would have been visible: a slipped date, a manager explaining to their boss why the roadmap moved. Ignoring it was invisible until the service failed, and by then the cause would be hard to trace. So the person who raises an uncomfortable truth gets labeled a troublemaker, and the person who stays quiet gets labeled a team player. The system selects for silence, and silence selects for entropy. The same asymmetry produces a familiar set of preferences.
Hierarchical and other kinds of entropic organizations always favor solutions that survive within entropic organizations.
They choose easy over simple, because easy feels comfortable while the simple fix demands a hard choice. They choose complex over difficult, because a complex workaround creates job security for the people who understand it, while a difficult fix takes real skill and is transparent once done. And they choose accountability over learning, because tracking who failed only requires assigning fault, while asking what was learned requires admitting ignorance. Underneath all three, a deadline is legible and the quality of a solution is not, so the organization worries about whether the team can ship by a date and rarely about whether it is building the right thing. The engineer’s fragile service is a quality problem in a building that can only see dates.
Bold on the way up, scared on the way down
This can go on for years while the company is growing. But an organization that grows unhealthily, too fast or for bad reasons or through bad recruitment, will also shrink unhealthily. When it grows it’s bold and confused. When it shrinks it’s scared and nasty. On the way up, the rising tide forgives the ignored service and the workaround stacked on it. On the way down, every deferred problem surfaces at once, and fear makes silence even more rational.
Meanwhile the most talented engineers, who are the least willing to work where their feedback disappears and the most able to find work elsewhere, go first. They leave, and the residue, grateful to have a job and making fewer demands, reinforces the culture that drove the talent out. That evaporation does the slowest damage, because it removes the people who would have noticed the next problem.
Opening the pipe
If bad code, wrong priorities and talent flight all run downstream of a broken feedback loop, the loop is where to intervene. A manager can gauge a team’s health by whether its engineers are comfortable giving constructive feedback directly. If they are, management might see an increase in reported problems during development, but they’ll also see an increase in resolutions, instead of fewer reports and a few critical issues festering unresolved. A rise in complaints is the sign that it is working, which is exactly why an entropic organization reads it as trouble.
It also tells anyone called in to fix a struggling team where to start: with the people who are clearly disgruntled. They usually saw the problem, tried to raise it, and were ignored, which matters because 95% of time is usually spent identifying the problem, 4% involves fixing it, and 1% is telling everyone it’s been fixed.
The counterweight belongs to the engineer herself. The rage that keeps you pushing in a dysfunctional place is useful, but it is intrinsically tiring, and it will take control the moment you are too tired to hold it. Stop well before. To argue and to win is to break down the reality of the person you are arguing against, and it is painful to lose your reality. So be kind, even if you are right, and stay the humble explorer. Whether she gets heard may depend less on how forcefully she argues than on whether anyone in that building has ever been rewarded for listening.
References:
- Workplace retrospective, personal experience
- Louis Srygley, “Without requirements or design, programming is the art of adding bugs to an empty text file”