The Real Bug Is in the Room, Not the Repository
I’ve been at this long enough to know that most engineering trainwrecks don’t start with a null pointer or a memory leak. They start with a vague nod in standup, a ticket that reads like a ransom note, and a product manager who thinks “just make it work” counts as a technical spec. By the time anyone opens an editor, the dysfunction has already set like cheap concrete. We obsess over linting rules, test coverage, and whether we should use tabs or spaces, while ignoring the bleeding obvious: the way we decide what to build is fundamentally snapped in half.
I’m Fritz, and I treat engineering culture as the actual technical problem. Not the soft-skills nonsense HR peddles, but the hard, repeatable failure patterns that show up long before an IDE is even warm. If your team lives in a permanent state of firefighting, blown deadlines, or shipping features nobody asked for, stop pointing at the tech stack. The rot goes deeper. It’s almost always cultural.
The Ticket That Lied to You
Let’s start with the artifact that’s supposed to connect business needs to technical execution: the user story. In theory, it’s a neat, atomic chunk of work. In practice, it’s a cryptic haiku scribbled by someone who hasn’t talked to a real user since the Obama administration. “As a user, I want a dashboard so I can see my data.” Cool. What data? Why? What decision does it drive? What’s the acceptable latency—two seconds, or two minutes while I go make coffee? That ticket is a Rorschach test. Every developer reads it differently and fills in the blanks with their own pet assumptions.
The dysfunction here is the illusion of clarity. Someone barfed a few words into Jira, threw story points at it in a planning poker ritual that feels more like a séance, and called it a day. The real requirements—the edge cases, the performance constraints, the actual user workflow—are buried in someone’s skull or a five-month-old Slack thread nobody can find anymore. This isn’t a communication gap. It’s a systematic refusal to do the hard thinking before the work starts. Engineers plug the holes with guesses. Those guesses turn into technical debt before a single commit exists.
Estimates as a Weapon of Mass Delusion
Ah, estimation. That ritual where we ask developers to predict the future using gut feeling, peer pressure, and a deck of cards, then act personally betrayed when reality doesn’t cooperate. The dysfunction isn’t that estimates are wrong—of course they’re wrong, we’re building things nobody has built before. The problem is that the org treats them as commitments. A rough guess gets rebranded as a deadline, the deadline morphs into a death march, and soon your velocity chart is being weaponized to flog the team in some quarterly review.
This sets up a perverse game. Developers pad estimates to buy themselves air. Managers slash them in half to look good to their bosses. The final number is political fiction, divorced from any engineering reality. Nobody asks the hard questions: “What’s the riskiest piece of this?” “What can we drop if time gets tight?” Instead we get “How many points is it?” as if complexity can be reduced to a Fibonacci number. The real technical problem is that we’ve built a culture where looking predictable matters more than being effective. And that culture doesn’t start in sprint planning. It starts with how leadership reacts when someone brings bad news.
Architecture by Anecdote
Here’s another classic: the senior dev or tech lead who designs the whole system from their personal collection of war stories. “We’re doing microservices because at my last job the monolith was a flaming dumpster.” Never mind that your startup has three engineers and one customer who barely logs in. “We need a queue-based event system because that’s what the big players do.” Congratulations, you just tacked on six months of infrastructure work for a problem you don’t have, may never have, and probably shouldn’t want.
I call this architecture by anecdote. Decisions happen not by looking at current constraints—team size, traffic, business model—but by cargo-culting some FAANG company’s blog post from 2017. The dysfunction? Nobody feels safe pushing back with actual data. The default move is to over-engineer, because it feels safer and looks juicier on a resume. The result is a sprawling system nobody fully understands, built for a scale you’ll never reach, while your actual product-market fit remains a distant fantasy. The worst part? This gets celebrated as “forward-thinking.” It’s not. It’s resume-driven development, and it’s a cultural cancer.
The Meeting That Should Have Been an Email… But Wasn’t Even That
Meetings are the exhaust fumes of bad process. When you see a calendar choked with “syncs,” “alignment sessions,” and “working groups,” you’re staring at a system that has abandoned written, asynchronous communication entirely. The dysfunction: decisions get made verbally, in real time, and leave behind zero artifacts. So the same decision gets re-litigated every Tuesday because nobody remembers what was actually agreed upon—or worse, the one person who wasn’t in the room blocks everything later because they were never looped in.
This imposes a silence tax. Engineers who can’t or won’t thrive in rapid-fire verbal cage matches get sidelined. Ideas that need quiet, written exploration never surface. The team’s collective memory turns into a five-round game of telephone. The fix isn’t yet another recurring meeting. It’s a bloody-minded commitment to writing things down—design docs, decision records, async video updates. But that takes a cultural shift that treats writing as a core engineering skill, not a distraction from “real work.”
The Hero Complex and Its Body Count
Finally, we need to talk about the hero. The engineer who pulls all-nighters, single-handedly wrestles a production outage into submission at 3 a.m., and gets showered with public praise in the #general channel. The dysfunction here is that the organization rewards firefighting over fire prevention. The hero becomes a bottleneck and a single point of failure, but they’re celebrated because they “get things done.” Meanwhile, the quiet engineer who spent two weeks building proper monitoring, writing runbooks, and simplifying the gnarly bits gets a lukewarm performance review because their impact isn’t dramatic enough for a slide deck.
This selects for exactly the wrong behaviors. It broadcasts to everyone that the path to glory is to let things break and then swoop in with a cape. It actively discourages the unsexy work that stops incidents from happening at all. The most damning part? This hero culture is often cultivated by engineering managers who don’t know what a healthy system looks like. They see a calm, boring on-call rotation and assume nothing is happening, rather than recognizing it as the ultimate success signal. This is a cultural failure, plain and simple. It’s set in stone long before any postmortem doc gets written.
So next time your sprint goes off the rails, don’t just stare at the code. Look at the ticket that kicked it off. Look at the estimate that lied straight to your face. Look at the architecture decision made over a rushed coffee chat. Look at the meeting where the real requirement was mumbled, misunderstood, and lost forever. That’s where the bugs actually live. The compiler can’t catch those. No linter will ever flag “culturally accepted insanity.”
Frequently Asked Questions
Why do engineering teams keep making the same process mistakes?
Because we optimize for local comfort, not global outcomes. Teams settle into broken patterns because it’s easier in the short term—easier to nod along in a meeting than to write a clear spec, easier to pad an estimate than to challenge a ridiculous deadline. The pain of the dysfunction is diffuse and delayed; the pain of fixing it is immediate and personal. Until leadership treats process health as a first-class metric, the path of least resistance leads straight to chaos.
How can I tell if my team’s dysfunction is cultural or just a skill gap?
If a single sharp hire could fix it, it’s a skill gap. If you’ve hired smart people and they’re still producing garbage, it’s cultural. Look at what gets rewarded and punished. Are people celebrated for saying “I don’t know”? Are postmortems actually blameless, or do they turn into quiet finger-pointing sessions? Do decisions get written down anywhere? If the environment punishes transparency and rewards heroics, no amount of training will help. You could parachute in a world-class architect, and they’d burn out inside a quarter.
What’s the one thing I can do today to start fixing this?
Start writing. Before any non-trivial piece of work, force a one-page design doc. Not a novel—just a tight explanation of the problem, the proposed fix, the alternatives you considered, and the risks you can already see. Share it asynchronously, let people rip it apart in comments, and actually resolve those comments before a line of code gets written. This single habit surfaces ambiguous requirements, forces decisions into the open, and leaves a paper trail. It’s not a silver bullet, but it’s the closest thing I’ve found to a circuit breaker for pre-code dysfunction.
