"Let coders code" fallacy

A playbook for giving engineering teams business context to multiply their impact

“Let coders code” is a dangerous fallacy. I will die on this hill.

Treating software engineers as coders implies putting people in a small bucket.

Coders turn tickets into code. Their work is purely technical. Coders are expensive, and every minute they spend not coding feels like waste. So we “shield” them from the business. They don’t need to bother with customer retention, acquisition, profitability, or even the business viability of what they create.

We have product managers, business analysts, and go-to-market teams for that.

This mindset is the problem. Software engineers' early involvement in product work is the most underutilized lever in most organizations. I've seen it everywhere — from B2B SaaS to consumer electronics to B2B hardware companies. The industry doesn't matter. Wherever engineers are cut off from the business, the same problems show up.

They know the underlying technology. They know what new enabling technologies are available. They see implementation possibilities that no one else in the room can. Hiring smart people and giving them predefined tickets is like hiring a chef and handing them a microwave meal to reheat.

Instead of giving engineers tickets, give them business context and a problem to solve. Here's what that looks like in practice.

Last year, my team was handed a feature request estimated at two months of work. Because they understood the client's actual intent — not just the ticket — they pushed back. They proposed a workaround that didn't require a single line of code, solving the client's problem immediately and saving two months of engineering time for higher-value work. That conversation only happened because the engineers had business context.

Shifting engineers left

Here’s where it goes wrong. Let’s consider the typical product development life cycle:

User Pain Identification → Solution Discovery → Solution Implementation → Release → Feedback → Closing the loop (either a new pain or a new solution).

In the organizations where engineers are treated like coders they are brought in into the project in Solution Implementation stage. Someone else has already identified the pain, found the solution and now developers need to decide how they are going to implement it.

This creates four problems:

• The selected solution might be suboptimal from a technical perspective. There might be faster, cheaper, or better ways to solve the problem — but engineers don’t have the problem context to suggest them. Often they’re not even expected to, because the decision has already been made.

• Engineers don’t own the problem. They only own the implementation. When you don’t own the problem, you don’t care whether the solution actually works for clients. That’s someone else’s job.

• Technical trade-offs become guesswork. Without understanding the intent behind a solution, engineers optimize for the wrong things.

• Innovation dies. Engineers are the ones who spot opportunities nobody else sees — “we could solve this entirely differently using X.” That insight only happens when they understand the problem space. Keep them in implementation mode and you’ll only ever get incremental improvements, never leaps.

The fix is simple (but not easy): shift engineers left.

This doesn’t mean drowning engineers in meetings and expecting them to answer client emails. That will grind development to a screeching halt. The goal isn’t to rob engineers of their focus time — it’s to give them context and show them the business stakes.

Playbook

Here’s my playbook of what works for me and my team.

Feed the team business context. This is about building ambient awareness — engineers don’t need to attend every meeting, but they need to understand the world their product lives in.

• Share product and business meeting recordings. Highlight the parts that matter for developers: a client articulating their pain, a bad user experience, a good one, praise, confusion about how a feature works. Do this regularly and the team will build real context around how the product is actually used.

• Pass along feedback from support and customer success — the good and the bad. These teams work with clients directly and can aggregate anecdotal information into a prioritized picture. They can tell you what the most acute problems are, what parts of the product are most used, and what’s most valued.

• Share sales feedback. What excites prospects? What’s missing that costs you deals? Engineers rarely hear this, and it changes how they think about what they build.

• Share business outcomes. Adoption rates, user satisfaction, churn, won and lost deals — give engineers transparency into the business side. When people can see the impact of what they build, they make better decisions about what to build next.

Involve engineers early. This is about changing when engineers enter the process, not just what information they receive.

• Form a three amigos team: a PM or PO, a UX designer, and an engineer. This team works together starting from pain identification. Even at the earliest stage, the engineer is doing feasibility checks, spotting technical opportunities, and flagging constraints that would otherwise surface weeks later. As the vision becomes clearer, their contribution increases rapidly. Three amigos own pain identification and early solution discovery together.

• Run quick spikes and prototypes during discovery. Before committing to a direction, have engineers explore technical risks and options. A two-day spike can save weeks of building the wrong thing. This also gives the three amigos team evidence to bring to the wider team workshop rather than just opinions.

• Workshop with the whole team. When you have a rough direction, bring in the rest of the engineers. Walk them through the problem, the proposed approach, and let them poke holes in it. This is where you get the “what if we solved it this way instead” moments that you’ll never get from a Jira ticket. Take the feedback and proposals home and incorporate the feedback.

Shielding redefined

Engineers who understand and own both the problem and the solution change the whole game. Instead of coders who only care about doing their job well, you get engineers who care about solving the problem and moving the business forward. Better products, faster delivery, happier teams. And here’s the thing — none of this means abandoning shielding. It means redefining it. Real shielding isn’t cutting engineers off from the business. It’s building structured communication that is sufficient but not overwhelming. Not opening all the valves and letting the team drown in requests, meetings, and feedback. It’s curating the right context and protecting the focus time to act on it. This is not less work for the manager. It’s harder. I can’t say I’ve fully mastered it — it’s an ongoing struggle. But it is the job. And the result — engineers who build the right thing, not just the thing on the ticket — is worth every bit of effort.

That’s it for this week. If you found this post useful, please, share it with your colleagues.

Thank you for reading and see you next week,

Roman

P.S. Scaling an engineering org is hard — especially without a sounding board who’s been through it. I’ve spent 20 years building software and then scaled a startup’s engineering department into a top leadership role. I learned management in the trenches, made the mistakes, and figured out what actually works. Today, I help engineering leaders and startup founders stress-test their strategy and scale their teams without repeating those same mistakes.

If you’re facing a challenge — whether it’s org design, technical leadership, or figuring out how to grow from here — reply to this email or DM me on Substack. Tell me what you’re working through, and we’ll see if I can help.