The Human Compiler and the Death of the “How”
Why the "One Team" culture is eroding technical craftsmanship and turning engineers into cognitive shock absorbers
I spent my morning being a translator. Not for a foreign language, but for a “vibe.”
In the DTC world, the software is rarely the product—it’s the plumbing. It’s the digital duct tape holding together a decade of “pivots” and “hypotheses.” And because the culture insists on being a “perpetual startup,” we’ve rejected the very systems that make scale possible. No industry benchmarks. No rigid roles. No “precious” architecture.
They call it being “One Team.” I call it being a Human API.
The Grinder of “What” and “Why”
There is a widening rift in modern tech. On one side are the visionaries—the folks obsessed with the What and the Why. They have dreams of a 0.05% KPI increase. They have a new “hypothesis” every Tuesday after a Zoom call.
On the other side is the How. That’s us—the Engineers. We are the people who understand that for every “exciting” marketing pivot, there is a database schema that needs to be rewritten, an integration that needs to be stress-tested, and a logic chain that must remain unbroken.
But in the “One Team” world, the How is dying.
When a company decides that departments don’t matter, it isn’t just breaking down silos; it is erasing specialized expertise. When it does so deliberately, even if implicitly through jargon like ‘Mission’ and ‘Vision’, it comes off as duplicitous; they want the code to be as fluid as a Slack brainstorm. They want us to be generic “collaborative problem solvers”—cognitive funnels that take scattered, unvetted ideas and grind them into reality through sheer individual heroics.
My technical contributions have been down for three years. Not because I’ve lost my edge, but because my “skill budget” is being spent on the emotional labor of a Product Owner without the title or the authority to say “No.”
Systems of Logic vs. The Vibe
Engineering is fundamentally about rules. It is the art of understanding a system well enough to manipulate it, to find the edges, and to build something stable within them. But you can’t debug a “vibe.” You can’t build a roadmap on a “hypothesis” that changes every time a lead calls.
We’ve reached a critical mass of abstraction where engineers are used as “shock absorbers” for a lack of organizational process. We are told that “waiting is losing,” so the vetting is skipped, the best practices are ignored, and we ship “MVP” garbage that requires manual verification on live code.
Leadership cheers about “velocity,” but it’s a fake speed. It’s the velocity of a car heading toward a cliff because the driver refused to look at the map.
Reclaiming the Craft
I’m tired of being the funnel. I’ve realized that my value isn’t actually measured by the quality of my code, but by how much chaos I can absorb before I break. It’s an unsustainable way to work, and more importantly, it’s an insulting way to treat a craft.
When we stop respecting the “How,” we stop respecting the people who build. We replace architecture with guesswork and call it “agility.” But true agility comes from a foundation of technical confidence, not from a refusal to plan.
I want to move toward a culture where technology is treated as a first-class citizen. Where the logic of the system is respected, and where the people building it aren’t shielded from the strategy, but are expected to lead through the lens of technical reality. We need to stop acting as human compilers for half-baked ideas and get back to being architects.
The old ways of working—the heroics, the role erasure, the constant pivots—are a dead end. It’s time to find a new spot of land where the engineering matters as much as the idea.
If you’ve ever felt like your brain is just a translation layer for someone else’s vibes, you aren’t alone. We’re all looking for a way back to the code.