Here's a pattern I've watched in every engineering org I've worked with for the last fifteen years.
The team is busy. The standups are full. PRs are open. Sprints close on time. Velocity numbers in Jira look reasonable. And somehow, the roadmap from last quarter is still last quarter's roadmap, and the founder is on a call with the board explaining why the v2 feature slipped again.
When this happens, the diagnosis almost always points at something technical. The monorepo is too slow. The CI pipeline is flaky. The codebase needs to be rewritten. Devs are scared to touch core services. We need to migrate from X to Y. We should adopt event sourcing. We should remove event sourcing. We need more senior engineers. We need fewer.
These diagnoses aren't wrong, exactly. The stack probably does have problems. CI probably is slow. There probably are parts of the codebase nobody wants to touch.
But they're rarely the actual cause.
The actual cause, in my experience - and I've now seen this play out in fintech, healthtech, SaaS, ad tech, gaming, and cybersecurity - is something almost nobody is working on directly: the translation layer between business reality and technical execution.
That's where the work goes to die. Not in the codebase. Not in the build pipeline. Not in the standup. In the gap between what the business needs and what the engineering team is actually building.
This post is about what that gap looks like, why it's so hard to see, and what to actually do about it.
The translation layer, defined
Every engineering organization runs on a chain of translations.
A founder has a vision. That vision becomes a product strategy. The product strategy becomes a roadmap. The roadmap becomes quarterly OKRs. The OKRs become sprint goals. The sprint goals become tickets. The tickets become PRs. The PRs become deployed code. The deployed code becomes - if everyone has done their job - user value that justifies the company's existence.
That chain has, at minimum, six translations in it. In a larger org, ten. Each translation is a place where information can be lost, distorted, or quietly replaced with something else entirely.
The trouble is that nobody is responsible for the chain as a whole. The founder owns the vision. The PM owns the strategy. The eng manager owns the sprint. The senior engineer owns the architecture. The IC owns the PR. Each person is doing their job. And yet by the time the work reaches the user, it bears only a passing resemblance to the original idea.
This isn't a process problem. You can't fix it with more meetings, a better Jira workflow, or a Notion overhaul. It's a translation problem. And the only way to fix translation problems is to take responsibility for the chain.
Most engineering orgs don't have anyone doing that. They have people doing pieces of it.
What a broken translation layer looks like in the wild
Let me make this concrete. Here are five patterns I see in nearly every velocity-problem engagement.
Pattern 1: The 40-page PRD that doesn't say what to build
A product manager writes an exhaustive spec. Forty pages. User personas. Edge cases. Wireframes. Acceptance criteria. It gets passed to engineering.
The engineering team reads it. They don't disagree with anything. They start building. Six weeks later, they ship something that the founder looks at and says: "this isn't what I asked for."
What happened? The PRD answered every question except the one that mattered: why are we building this? It described the artifact, not the outcome. So engineering optimized for what was written down - completeness of the form - instead of what mattered - the change in user behavior. The translation from "business need" to "technical work" picked up every detail except the one that drove the decisions.
This is the most common translation failure I see, and it almost never gets diagnosed correctly. The PM thinks engineering was sloppy. Engineering thinks the PM was vague. They both blame "miscommunication." Neither blames the artifact that produced the miscommunication.
Pattern 2: Architecture decisions driven by the wrong stakeholder
A team chooses to adopt microservices. Or event sourcing. Or GraphQL. Or whatever the current darling is.
The decision is made by the senior engineer who's most enthusiastic about it. The business reasons for the choice are reverse-engineered later, in a Notion doc, for the CEO's benefit.
Six months in, the team is paying the cost - operational complexity, longer feature timelines, harder onboarding - without ever getting the benefit, because the benefit was never the actual reason for the decision.
This isn't bad engineering. It's a translation failure: the business problem ("we need to ship features faster as we scale") didn't survive the translation into a technical decision ("microservices"). It got replaced with something the engineer cared about instead. And nobody noticed because nobody was responsible for noticing.
Pattern 3: The codebase that punishes change
A startup hits product-market fit. The codebase that got them there is now a constraint, not a foundation. Every new feature requires touching code that "we don't really understand anymore." Engineers route around the scary parts. Cruft accumulates. Velocity drops.
The diagnosis is always: "we need to refactor." The team puts together a multi-quarter rewrite plan. The board doesn't approve it. Velocity continues to drop. Everyone is frustrated.
The actual translation failure happened years ago. When the codebase was originally written, nobody asked: "what are the business decisions we're likely to revisit in 18 months?" So the parts of the system that needed to be flexible weren't. The parts that needed to be rigid weren't. And now the cost of changing direction is enormous, because the system was built assuming the direction was settled.
The fix isn't a rewrite. The fix is identifying which decisions actually need to be flexible, decoupling those, and leaving the rest alone. That's a translation job - translating "what does this business need to be able to change quickly" into "what does the architecture need to absorb without rewriting."
Pattern 4: Engineering velocity that's actually communication velocity
A team complains that they're slow. The investigation always finds the same thing: most of the engineers' time isn't spent writing code. It's spent in meetings, on Slack, in spec reviews, in design discussions, waiting for answers.
The naive response is "we need fewer meetings." That's the wrong fix. The reason the meetings exist is that the information needed to make decisions is fragmented across people, none of whom have all of it. Removing the meetings doesn't remove the fragmentation. It just makes decisions slower or worse.
The real fix is reducing the need for the meetings - by consolidating information, making decision authority explicit, writing things down once instead of explaining them seven times. That's translation work: turning a distributed, oral culture into one where the artifact you produce ("this is the decision and here's why") replaces the meeting that would have been needed to communicate it.
Pattern 5: The founder who's lost the plot
This one is less common but it's the one that breaks the most companies.
The founder built the original product. They had every decision in their head. The team scaled, and the founder kept making decisions, but stopped writing them down or explaining them - because by then everyone "knew" what they were building.
A few hires later, the new people don't know. They make decisions that contradict the original product vision, because the vision was never translated into anything they could read. The founder doesn't see this until shipped features start drifting away from the brand. By then it's expensive to correct.
The translation that broke here was the simplest and most important one: founder's mental model → written principles that survive personnel changes. Almost no founders do this until it's too late.
Why this gap is invisible
If translation problems are this common, why don't more people fix them? Two reasons.
First, nobody owns the chain. The PM owns translation step 2. The eng manager owns step 4. The senior engineer owns step 5. Each is doing their job. The gaps between their jobs aren't anyone's job. When a translation fails between PM and engineering, the PM blames engineering and engineering blames the PM. Neither of them has the authority - or, often, the interest - to fix the gap.
Second, the people who'd be best at this work are usually the ones most allergic to it. Engineers want to engineer. Founders want to found. Both will avoid "translation work" because it doesn't feel like real work. It feels like meta-work. It feels like overhead. And in the short term, it is. Writing a document that prevents three future meetings looks worse than just having the three meetings.
The result is that translation work is undervalued precisely because it's invisible when done well. A team where translation is tight doesn't feel like a team that's doing something special. It feels like a team where features ship on time and nobody is confused about what they're building. Which is to say, it feels boring. Boring engineering teams are dramatically more productive than exciting ones.
What the work actually looks like
If you accept the diagnosis, the question is what to do. Here are the patterns I use in client work. None of them are about technology.
Replace meetings with documents that prevent meetings
The default in most engineering orgs is to make decisions in meetings. The meeting is the artifact. Six months later nobody remembers what was decided or why, so the decision gets re-litigated, in another meeting.
The replacement: every non-trivial decision is captured in a short document with three things in it. (1) The question being answered. (2) The decision. (3) The reason. Not the methodology, not the tradeoffs, not the alternatives. Just those three. Anyone joining the team in six months reads the document and understands why the codebase looks the way it does.
The first time you write one of these, it feels overkill. The fifteenth time, it feels like the thing that lets you scale past twenty engineers without losing the plot.
Make decision authority explicit
In most teams, decision authority is implicit and ambiguous. Three people each think they're the one who decides X. None of them have actually been told. So X gets re-decided every time it comes up, or it gets decided by whoever shouted last, or it doesn't get decided at all.
The fix: for any decision that's been re-litigated more than twice, name a single person who owns it going forward. Tell everyone. Write it down. The decision doesn't need to be a vote - it needs to be predictable. Predictable decisions are what teams need to move fast.
Build architecture around the questions you'll revisit
This is the hardest one and the highest leverage. Most architecture work is done assuming the requirements are settled. They're not. They never are. The right question to ask, when designing a system, isn't "what does this system need to do?" It's "which parts of this system will I want to change in twelve months, and which parts can I let calcify?"
Optimize the flexible parts for change. Optimize the calcified parts for performance, simplicity, and not breaking. Most architecture problems come from teams that didn't make this distinction - every part of the system is equally fragile, so any change is equally painful.
Translate the vision once, in writing, every quarter
If you're a founder or a CTO, the most leveraged thing you can do is write a short document - three pages, no more - that captures, for the team, what you're building and why. Update it every quarter. Make new hires read it on day one.
It doesn't need to be brilliant. It needs to exist, be current, and be referenced. The cost of not having this scales with team size. By the time you have twenty engineers and you've never written it down, the gap between your mental model and theirs is wider than you realize, and most of your "velocity problems" are downstream of it.
Reduce the number of translations
The simplest move: cut steps out of the chain. If the founder can speak directly to the senior engineer, you don't need a PM in between. If the senior engineer trusts the IC, you don't need code review on every PR. Each step is a translation point. Each translation point is a place where information can degrade.
This isn't a recommendation to fire your PMs. It's a recommendation to look at where translation is happening and ask whether it's adding value or just adding latency. Surprisingly often, the answer is the latter.
What this isn't
Because this gets read as a methodology pitch, let me be clear about what I'm not saying.
This isn't a tooling argument. Your Notion setup doesn't matter. Your Jira workflow doesn't matter. Your team can run on Google Docs and Slack and ship faster than a team with a perfectly configured Linear instance. The tool is downstream of the discipline.
This isn't a more-meetings argument. Almost the opposite. Most "alignment meetings" exist because the translation work wasn't done in writing, so it has to be done verbally, repeatedly. Doing the translation work in writing is how you eliminate the meetings.
This isn't an Agile argument or a Waterfall argument. Both methodologies fail in the same way when translation is broken. They both succeed in the same way when it isn't. The process choice matters far less than people think.
This isn't a "hire better PMs" argument. A great PM helps. A great PM working in a team with broken translation chains will still produce broken outcomes - they'll just produce them with more empathy.
This isn't a "fractional CTO sales pitch." Or, well - it kind of is, since I do that work. But I don't want anyone to read this and conclude they need to hire someone external. Most teams can do this themselves. The patterns above are not gated behind expensive consulting. They're gated behind the discipline to spend two hours a week on the translation layer when there are forty other things screaming for attention.
Why most engineering leaders miss this
The standard CTO archetype is someone hired for technical depth. They were the best engineer on a previous team. They got promoted. Then they got promoted again. Now they run the engineering org.
That career path optimizes for technical judgment, which is necessary but not sufficient. It does not optimize for translation skill. In fact, it often selects against it - the people who became great engineers were often the ones who didn't have to spend their time translating, because they could just do the work themselves.
When those people become engineering leaders, they default to running the team the way they ran their own work: with their head down, focused on the technical problem. They produce excellent technical decisions and terrible translation. Their teams build the right system to solve the wrong problem.
This isn't a failing of any individual leader. It's a structural problem with how engineering careers are shaped. The way to address it isn't to fire CTOs. It's to consciously treat translation as a skill, name it as a job, and put someone on it.
In small teams, that someone is the CTO themselves. In larger teams, it's often a staff engineer or a TPM. In a few of my engagements, I've watched it become its own role - engineering ops or engineering chief of staff - which always turns out to be the most leveraged hire the company ever makes.
But you don't need a hire. You need a person, possibly you, who treats the chain as their responsibility. Once someone is treating it as their responsibility, the patterns above start producing results within weeks.
What to do this week
If any of this rings true, here's a one-week starting point.
Day 1. List the last five times something shipped that the founder, the PM, or the customer said wasn't quite right. For each one, ask: where in the translation chain did the original intent get lost? Don't blame anyone. Just locate the break.
Day 2. Pick the gap that comes up most often. Identify who currently "owns" it. (Spoiler: probably nobody.)
Day 3. Write a short document - under one page - that, if it had existed three months ago, would have prevented one of the five misfires. Share it with the team.
Day 4. Identify one recurring meeting that exists because something isn't written down. Cancel the meeting. Write the thing down.
Day 5. Look at your last quarter's architecture decisions. For each one, ask: what business question was this answering? If you can't answer in one sentence, the decision was probably driven by something else and is going to cause problems.
That's a week. Nothing fancy. No process overhaul. No new tooling. Just five small acts of translation, paid for with five hours of focused attention.
If you do it for a quarter, your team's velocity changes in a way that the team itself can't quite explain - because translation work, when done well, is invisible. They'll just notice that features ship on time and they're not in as many meetings.
That's the work. That's almost all the work.
The technical stuff matters too. But almost never as much as the translation layer.
If you read this and recognized your team, that's the diagnostic. If you want a second pair of eyes on it, send me what you're seeing or schedule a conversation.
