Remove the layers

So often in small to medium sized tech companies I see the same problem pop up. Engineers are so far removed from the actual words that customers are saying about the problems that they're having that, by the time the issue is actually articulated to the person who can solve for it (the engineer), it's lost all of its potency, urgency, its power.

Usually, it's not the engineer's fault. In my experience most engineers want to help. They hate building something they know is half-thought through or missing lots of context, because more often than not the ultimate blame is put on "engineering" for a piece of software not doing what it needs to, either for the customer or the business.

So they hunger for context, for "clear requirements", which are often quite difficult for a middleman like a Product Manager or Sales/Support person to fully distill, as they most likely won't have the technical context that the engineer does.

What ends up happening then, is a game of back and forth through multiple departments, consuming endless amounts of company energy.

A Better Way

It's pretty simple. Put engineers directly into those conversations. Depending on your role when you read that, you'll have one or more of these reactions:

• "But Engineers should be coding, not in customer conversations! What use is an engineer to the company if they're not constantly hammering their keyboard churning out code?" - you're a CEO aren't you?
• "But that's my job, if engineers are doing that, what do I do? Am I going to be made redundant??" - insecure Product Manager.
• "But the engineer will say the wrong thing to the customer, commit to something we can't do, or (gasp) tell the truth that our product doesn't do something the customer has previously been told it does" - you're in Sales, right?

To the CEO, I'd say you want the engineer building the right thing, not just anything, and this is the best way for them to get to the best solution.

To the insecure Product Manager, I'd say don't worry, finding the solution(s) to a problem is a sliver of your overall job description. If anything, this should help free you up to do all those other things you haven't gotten to, like planning your go to market, monitoring your metrics and over-communicating with your internal stakeholders.

To the Salesperson, I get it, and honestly the most valid concern. Any person interfacing with customers needs coaching and training initially. I would take this case by case as some people just aren't very strong communicators. For those, I'd let them know they don't need to say anything, just listen, and learn.

And If The Engineer Says No?

Depending on the culture, this could be a very tricky thing to achieve across the board. But, it doesn't have to be for everyone.

The way I've seen it work well is that you'd usually have one or two "outgoing" engineers in a given team of 5-6. Those are your people for bringing into customer conversations, especially in the early exploratory phases of work where you're gathering as much context as possible.

There will always be engineers for who this is a much more uncomfortable proposition, but as long as the team is getting some form of interaction with the primary sources of information (the customer), then that's enough.

What you want to avoid is entire teams stuck in their proverbial cave, never actually hearing a single customer's voice. In my opinion that's making a hard thing (building software) much, much harder.