It’s become one of those default industry assumptions. Like legacy systems or morning standups. The idea that developers can’t (or shouldn’t) be in direct contact with “the business side.” They need someone (usually a product manager or a product owner) to act as a translator. Someone to sit in the meetings, gather the context, reword the problems, and then hand over a neat little task list to the people who write the code.
And sure, sometimes that works. Sometimes it’s even necessary. But more often than not, it’s just habit. A holdover from the idea that developers aren’t equipped to handle nuance. That they’d rather stay in their bubble, protected from ambiguity, business logic, or customer pain points.
If I’m honest with you, most of the developers I’ve worked with, that’s not true at all. They don’t tolerate context; they ask for it. They don’t need every conversation pre-digested. They want to know what matters, why it matters, and what constraints they’re working inside of.
And the issue isn’t ability, it’s trust. Somewhere along the way, the default became “developers need translation,” because nobody gave them a chance to understand. That’s the gap. Not technical skills or soft skills. Just access.
When you give the right developers access to the conversation, not just the Jira tickets, something interesting happens. Because they listen differently, they think differently. They push back when assumptions don’t make sense. They make better calls.
Translation isn’t always the bottleneck. But too often, it becomes one. So, let’s talk about what that costs and what happens when you hire developers who simply don’t need it.
Blog Summary:
We are going to look at what happens when developers are kept away from context and what changes when you trust them to handle it. You’ll read about:
- Why the default model for communication exists.
- The small, costly things that get lost between the idea and the implementation.
- When translation is helpful and when it just gets in the way.
- The kind of developers who don’t need constant clarification.
- How we build teams that contribute to the conversation.
Table of Contents:
The Default Model
Most companies don’t even think about this anymore. The business team talks to the PM. The PM talks to the developers. Developers build. Everyone moves on. It’s a setup that’s so baked into how teams work that nobody really questions it. It’s just how things are done. And, for what it’s worth, sometimes it does the job.
But there’s a difference between something that works and something that works well. What this model gives you is filtered context. By the time a feature request or a user pain point makes it from the customer’s mouth to the developer’s task board, it’s been translated, condensed, and repackaged at least twice. Probably more.
So, the developer ends up with a task “Add X” or “Fix Y” without really knowing why it matters, how it came to be, or what the underlying issue even is. They can still write the code, sure. But you’ve stripped away the most valuable part of the process: the thinking. The chance to spot something better.
The Costs of Translation
Every time you filter context, you lose something. A nuance. A hesitation. A real business need that didn’t quite make it into the ticket. And it adds up. A developer builds what was asked, not what was needed.
This is where the cracks start to show. Not in big, dramatic failures but in slow, silent misalignment. Features that technically work but miss the point. Solutions that feel disconnected from the actual problem. Most of it traces back to the same thing: the people solving the problem weren’t part of the conversation that defined it.
That’s the part that breaks things. Not the translation itself, but the assumption that it’s safer to keep developers in the dark than to bring them into the room. And if you’re always shielding your technical team from business context, don’t be surprised when they struggle to deliver business impact.
This Is Not a PM Hit Piece
I’m not saying you should remove product managers from your business. Or blaming them. Good PMs are critical. They bring structure. They align teams. They unblock work. Most of the time, they’re the ones holding chaos together. And in a lot of companies, they’re doing it with half the resources they need and twice the expectations they were promised.
So no, this isn’t about throwing shade. The problem isn’t PMs doing their job, it’s when they end up doing everyone else’s. Acting like a buffer instead of a bridge. Constantly translating every business conversation into specs and shielding developers from anything even slightly ambiguous.
That usually doesn’t come from ego. It comes from habit. Maybe they’ve worked with devs who only deliver what’s written down. Or with leadership that expects them to “own the room,” no matter who’s in it. Over time, that expectation gets baked into the way they operate.
In reality, not every team needs that level of protection. And when you keep applying the same model over and over, you start to lose the upside of having smarter developers in the room. The point is: if you’ve got developers who can handle context, let them. Give them access. Give them trust. Let them speak for themselves.
The Case for Direct Contact
One of the most overlooked advantages in any product team is having developers who can think beyond their IDE. Not just in theory, but in real-time, with real stakeholders.
Business conversations aren’t always clean, we know that. They meander. Priorities shift mid-sentence. A technical constraint shows up halfway through a feature pitch. If your developers aren’t there, they miss all of it. And by the time the cleaned-up version hits the backlog, most of the complexity is gone. Which sounds like a win, until it isn’t.
There’s value in hearing things when they’re still messy. It’s in that mess where better questions show up. Like: do we actually need this? Is this a symptom, or the root? Could we solve it faster, or cheaper, or in a completely different way?
Developers who can sit in that ambiguity, without waiting for someone else to shape it for them, are at a competitive advantage. They don’t need perfect clarity to move. They just need access to the source. And when they have it, the work stops being a game of telephone. It becomes a collaboration.
When Translation Is Useful
There are moments when having someone translate makes sense. A new team is spinning up fast. A client who isn’t technical and doesn’t want to be. A project with a dozen moving parts, three departments, and zero alignment.
In those cases, having a PM step in to connect the dots is more than helpful; it’s necessary. Not everyone wants to sit in technical conversations. Not every developer wants to unpack business goals on day one. That’s fine. But those moments should rather be an exception, not the default.
The model where translation becomes the permanent state might protect short-term productivity. But it limits long-term ownership. The goal is to use it strategically. To know when it adds clarity and when it starts getting in the way.
Traits of Developers Who Don’t Need Translation
Finding a developer willing to participate in the conversation is not so difficult. They’re not unicorns or some rare hybrid of product strategist and backend architect. They’re just developers who were hired for more than their ability to write clean code.
You’ll notice a few patterns. They ask questions early because they’re invested. They’re not trying to finish the task and move on. They’re trying to understand the goal. These types of developers handle ambiguity without panicking. They know how to spot a half-baked idea without shutting it down. And when a feature doesn’t make sense, they don’t go quiet, they push for clarity.
And no, they don’t necessarily need to be extroverts. Or charismatic. Or the loudest in the room. What matters is curiosity, clarity, and a willingness to engage with the problem before jumping to the solution.
The best thing is that you don’t need a special playbook to work with these developers. You just need to stop filtering out the people who think like this when you’re hiring.
Our Developers
Most companies that come to us aren’t looking for more hands. They’ve already tried that, adding capacity without solving the underlying friction. What they want is fewer gaps. Less misalignment. Developers who don’t need a middle layer to understand what’s going on.
So that’s what we optimize for. We place developers who know how to listen. Who aren’t thrown off by vague input? Who is comfortable asking questions when something doesn’t add up? And those who treat the business context as part of the work.
The teams we build are meant to reduce the need for translation by understanding the problem and taking responsibility for the solution. If that’s what you’re looking for, we should definitely talk.