The Trap of Expertise

Too often, companies exclude engineers from product planning. The intention is noble: protect them from distractions so they can focus on writing code. But this approach fundamentally misunderstands many engineers and their motivations.

For a large number of engineers, coding is not the goal—it’s the tool. These individuals didn’t get into this field because they dreamed of syntax or debugging; they got into it because they wanted to solve problems. Code just happens to be the language of problem-solving in a digital world.

A Tale of Expertise

Imagine someone with a product-minded perspective deciding on a career path. They love solving problems and making things happen. One clear option is to become a product manager, working closely with teams to shape solutions and steer product development.

But what if this individual decides they want to go further? What if they want to be hands-on, diving into the implementation of solutions and understanding the architecture behind the fix? To do that, they learn to code and become a software engineer.

Now here’s the paradox: having taken that extra step to master the technical skills required for hands-on problem-solving, they often find themselves removed from the very process that intrigued them in the first place.

Why would their deeper understanding of architecture, systems design, and technical complexities make them less likely to contribute to decisions around those very things? Why does knowing more about the "how" disqualify them from participating in conversations about the "what" or "why"?

This isn’t to suggest that all engineers want—or should want—to be heavily involved in product strategy. But it raises a crucial question: are we inadvertently severing capable, problem-solving engineers from the discussions where their insights could make the most difference?

A Personal Lesson in Problem-Solving

At one company, I joined as a new architect and quickly ran into a litany of issues. The system was slow, reports were painful to run, and customers were bogged down with overhead just to manage records.

After reviewing the system’s architecture, it became clear that the root issue was conceptual. The company’s data model was centered around what they thought they were, but from an engineering perspective, this made no sense. It created inefficiencies everywhere.

I proposed a change: normalize the data and shift the architecture slightly to reflect what the company actually did. From the customer’s perspective, nothing changed. But under the hood:

• Fewer joins for daily operations.
• Reports became intuitive.
• Managing data was a breeze.

The problem melted away—not because of code, but because of problem-solving. Had engineers not been allowed to weigh in, the inefficiency would have persisted, and customers would have continued to suffer.

The Cost of Exclusion

When engineers are excluded from planning:

1. Problems Go Unsolved: Engineers often have insights into simpler, more elegant solutions that are overlooked.
2. Plans Are Unrealistic: Without technical input, timelines and expectations are often misaligned.
3. Engagement Plummets: Engineers who want to solve problems are relegated to coding tasks, leading to frustration and disengagement.

By treating engineers as mere executors of product plans, companies are punishing them for their expertise. The very skill that makes them invaluable—coding—becomes a trap that limits their ability to contribute strategically.

A Better Approach to Collaboration

Recognize Engineers as Problem-Solvers: Coding is just a means to an end. Leverage engineers’ natural aptitude for understanding problems and designing solutions.

Foster Cross-Functional Teams: Bring engineers into the product planning process early. They may not all have a knack for product strategy, but many will—and their input can transform outcomes.

Break the Silo Mentality: Engineers shouldn’t feel like second-class citizens. By treating them as collaborators rather than executors, companies can unlock their full potential.

Why This Matters

Great engineers thrive when they’re solving meaningful problems, not when they’re handed rigid requirements and told to code. When companies exclude engineers from the planning process, they squander creativity, miss opportunities for innovation, and ultimately drive away talent.

The next time you consider leaving engineers out of a planning meeting to “protect” their time, ask yourself: Are you protecting them, or are you denying them the chance to do what they’re best at?