The System Around the Code: Five Forces That Actually Drive Engineering Work

Why good engineering doesn’t reliably produce outcomes

Posted on by Adam Wespiser

Most engineers start with a simple model of how work gets done:

Write good code → ship value → things improve.

At some point, that model stops explaining what’s happening around you:

You do the right thing, and nothing happens. You raise a good concern, and it goes nowhere, or even lands back on you. You put in more effort, but outcomes don’t scale. Projects stall for reasons that aren’t technical. You ask “who owns this”, and are sent in circles.

This happened to me across distributed systems work, struggling start-ups, and big tech. The stories I used to explain how software should be written stopped predicting what would actually happen, and I cycled through simple heuristics like “that’s how we do things here”, or “don’t poke the bear” that were sometimes less helpful than they sounded.

What eventually replaced them wasn’t a single theory, but a set of patterns that kept showing up- across teams, companies, and problems:

These aren’t edge cases or dysfunctions. You can’t reorganize your way around them, hire your way out of them, or defer them to another time. They’re the forces that shape how work actually gets done when the critical path runs through people.

This is a collection of stories for understanding those forces, drawn from the uncomfortable gap between how engineering is supoosed to work, and what actually happens.

1. Incentives

Incentives are often the most transparent of forces in an organization: make money, save money, help customers, ship the thing, et cetera. Most of the time, we see exactly what is going on, but not always.

For the last few years, I’ve worked on internal tooling with a simple framing: minimize the time to complete a vital task and maximize cost savings. Easy concept, but after building your solution, the contours of the problem quickly take form. The primary constraint is always adoption, as measured during a brief period. How far can you go to get people to use the solution? You can message them personally, you can incentivize use with internal rewards, and even “juke” the system by pestering someone to try something once, then counting enough of those encounters to make it appear like sustained use. If your team’s success depended on a number, how far would you go?

It’s a classic situation where you’re tasked with improving a process, your success is measured in a single number, but optimizing a metric is not the same thing as solving the problem. The worrying thing: there’s no clean solution here. Every project benefits from a zealous champion, but policing this behavior falls on the judgment of engineers.

This issue isn’t unique to adoption. Tech debt works the same way. Engineers often argue on technical grounds, but technical arguments alone rarely win.

Instead, organizations often tackle tech debt as a tradeoff between a commitment to ship now and how fast we can ship later. A tech debt strategy extends beyond technical decisions and into organizational strategy. Winning a tech debt argument doesn’t mean calling out problematic code or flaky tests. It means establishing product strategy where ongoing investment is justified with receipts.

Goodhart’s Law gets quoted a lot here, and it’s true that metrics are flawed measures, but a more practical version is this:

People optimize for what they’re measured on, and the system that emerges is always imperfect.

Takeaway:
If you don’t understand the incentives, you don’t understand the decision.

2. Legibility

If you build something great and nobody understands it, it might as well not exist. Maybe it is great engineering and good code, but from the organizational perspective, caring requires knowing it exists.

Legibility is how well the rest of the world can see what you’re doing. It’s a tool that allows organizations to scale beyond shared truth and beyond delegating judgment to a room full of trusted people.

Leadership doesn’t see the elegance of your code or how clean you made an API interface. They see documents, read metrics, and pass on risk framing and narrative clarity. It’s these activities, the ones that exist to be seen, that we are often judged on.

As information travels further away from you in an organization, the compression is extreme.

There’s really no better place to see this than the “performance review.” A year of work becomes compressed into a headline and supporting bullet list. The sum total of your effort benefits you only to the degree that another human can express it in a moment before lunch.

The lesson for the engineer is clear: work that is easy to understand from a distance travels further. This is why some engineers seem disproportionately effective. It’s not always superior technical ability. It’s that they produce legible artifacts and translate complexity into something the organization can act on.

Takeaway:
Part of engineering is making your work legible to people who will never read your code.

3. Narrative

Narrative is the structured story we tell each other about what matters; it frames ideas worth sharing, what problems we should care about, and how we go about solving them. In organizations, narrative is the set of axiomatic operating principles, and without it, coordination falls apart.

There’s a deep reason for this: as Joseph Campbell pointed out, humans don’t just process information; we compress it into stories, and those stories are what we share.

A few start-ups ago, I had an issue with the do whatever it takes value our company had. As a student of 20th-century history, and making a point that pains me to repeat: do whatever it takes has led to real harm carried out by regular people. So “do whatever it takes” is not whatever it takes, like corporate espionage or securities fraud. It simply beggars belief to imagine a scenario on the job where you could quote a morally unbounded truism and be advocating for anything good. Therefore, the value should be replaced with an alternative missive that understands discretion is the better part of valor and recognizes that decisive action requires proportionality.

I raised that criticism in an all-hands meeting, and it was an absolute disaster. A few argued back in quiet side channels, but overall the response dismissed my concerns. This issue made something very clear: no company wants to entertain counter-narratives or make durable criticisms that attack its legitimacy.

In a lighter example, I often think back to a framing I’ve used many times in my career, and a frequent update in stand-ups:

“I’m doing X because Y asked me to.”

Strictly speaking, a true statement that summarizes the work, but not a story that motivates anyone and not a reason to get others to care.

A stronger version of that update would be:

“We’re solving problem X by doing Y.”

Now the work connects to a shared goal.

The real power of narrative is that it becomes the shared assumption behind what we do. The axis of progress. We can never outright deny it, but in assuming its validity, we gain a shared frame with everyone else.

And if you try to challenge it directly, you’ll hit resistance fast.

Not because people disagree technically, but because you’re challenging the system’s legitimacy.

Takeaway:
Organizations don’t just run on authority. They run on shared stories.

4. Influence

On paper, organizations look simple: clear diagrams, clean reporting lines, and defined ownership. People should follow the structure.

In practice, they don’t. Influence behaves more like a distributed system than a hierarchy.

It emerges from hard-won reputation, expertise in critical systems, trust that survives failed projects, and relationships that span beyond any single task, project, or even job.

One of the messiest expressions of influence is cross-team decision deadlock.

I recently worked on a “fast feedback” project to add a safety feature in response to a specific customer signal. I presented to the software team that owns the code, was redirected to a product team for approval, and then sent back again to the software team. It’s the corporate version of “you can sleep over if mom says so,” a self-referential approval loop where permission depends on itself.

This pattern is common in large products, where responsibility is distributed across a matrix of teams.

I’ve found several effective tactics to force a decision: call meetings with everyone involved, escalate through management chains, and sometimes ask directly, “Are you the team that owns this or not?” It helps to be explicit about what you want and to provide a default path forward: “I’m proceeding unless I hear otherwise.”

There’s a broader discussion about when you should or shouldn’t bypass slow, codified approval processes, but in practice, clarity often has to be forced. What you can’t recover is the time lost trying to discover where authority actually sits.

Influence shows up in many other places as well:

Influence can be messy, even uncomfortable. Many organizations try to minimize hierarchy, but power doesn’t disappear. It becomes implicit.

And implicit power is harder to navigate, harder to onboard into, and harder to challenge. Attempts to remove hierarchy entirely don’t eliminate politics; they obscure it. Informal networks, cliques, and personal relationships quietly determine access, resources, and advancement.

Takeaway:
If you want to move a project forward, find where influence actually sits and make it visible.

5. Alignment

A few years ago, I watched a group of great engineers argue about architecture for weeks without reaching a resolution. The company had just hired new leadership and announced an ambitious technical goal: migrate our software from air-gapped networks into the cloud.

As a business opportunity, it made sense. Technically, it was a goal we could all understand, but the architects weren’t convinced. Slack threads filled up with comments. Design docs got longer. Arguments became sharper and spilled out from closed doors into open channels, and sides started to form.

Eventually, something became clear: the disagreement wasn’t really about the architecture. It was about alignment. Not whether the new direction was worth pursuing, but how, when, with what technology, and which team. It felt like a struggle for control.

That was one of the first times I realized something uncomfortable:

Engineering work doesn’t just happen inside the codebase.
It happens inside an organizational system with its own forces.

Alignment is where everything comes together.

Closing: Engineers Build Two Systems

Engineers spend years learning how to design software systems, focusing on correctness and often letting technical purity drive their opinions. But getting work done in a corporation takes much more. It takes navigating the people, positions, and organization around you.

Technical decisions are rarely decided on technical grounds alone. They are decided by the system around the code.