I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/actionable at turning customer needs into working solutions.”
Promote the guy to CTO, and fire the useless chumps who were collecting a paycheck spinning their wheels.
He clearly adds value, he has his secretary take down requirements from the customer and then he personally walks them down the hall to the engineers.
Not sure why you’re not getting this?
/s
1. Professional software engineers that can listen to learn about the problem space and are willing to come to understand that. This takes humility.
2. The people experiencing the problem. They might not write perfect code and it might not be maintainable long term. But their understanding of the problem and pain points is so good that they can solve just that and not write 90% of the code the professionals wrote...
I've seen this over and over again and can only tip my hat to the people that fixed their own problem. Just like for a dev, that means going into an unfamiliar domain and teaching yourself
1. They assume they know more than everyone else. Got a guy who has had a problem for 5 years and tried 20 different solutions? The engineers will spend 10 minutes thinking about it, come up with a solution (that won't work, but they insist it will) and dismiss the problem as "trivial", and think the guy is an idiot. I've done it myself (which I'm embarrassed to admit), and I've seen it at every level from junior to Staff/Principal in companies large and small. The lack of modesty in software engineering teams is perhaps my #1 peeve with the industry. As a result, they often end up designing terrible solutions.
2. Once they understand a problem and a solution, they are frequently awful at thinking through the solution from the user perspective unless they themselves have experienced the problem. This isn't unusual, it's hard to build detailed empathy for how something should work unless you try it yourself. It can be very challenging to get buy-in for a UX or a UI from engineers without it, so sometimes it's useful to get them sat in the chair trying to do the work themselves.
I'm a TPM (former engineer and engineering manager), who has to regularly wear the "product manager" hat. I can not understate how hard it is to get engineers to read a scope document, understand it, accept that the thing needs to be built, that it needs to be built a certain way from a functional perspective, and while they have free reign on architecture and how it's built, it is not their job to rip each detail to shreds assuming the users, PMs and everyone else involved up to that point isn't a completely brainless moron.
This solution is relatively elegant. He got them to talk to users about the software they built and made them realise they were focusing on the wrong details. That's good. It doesn't mean the engineers can become product managers though.
You still need the PM to own the product long-term, and to deal with the customer relationships as the thing gets built. I will also guarantee that those engineers proposed changes the PM had to push back on because of constraints outside of the engineering team's heads (legal, compliance, needed by customer X, and so on).
Edit: read down into the thread, and this company doesn't have product managers. So he's just hoping engineers can figure it out. Fair enough, the only way to develop that muscle though is to get them in front of customers regularly.
Ironically, it is hard because it doesn't consider the user. Scope documents likely seem reasonable for the author living in their own little bubble, dismissing it as something "trivial", but if they actually had to use it like those on the receiving end they would soon realize how horrid and ill-conceived it is. Much like was learned in the original link, once you stop with the bad practices, things become much easier.
I call this the load-bearing 'just' - as in, 'oh, why don't you just...'
If I catch myself saying or writing that word, I kick myself and think about why I'm doing it. Usually I stop and reapproach my input.
This PM eventually found the way to push their engs, as described in the article. So I think PM achieved the goal pretty good.
Someone needs to look at it and push important points. Sometimes it's hard to push engineers, until they visit some calls and push themselves.
Or maybe the next thing after LLMs arrives in 2026 and it's actually better than everyone at everything and can feed itself in a loop, but I doubt it.
Does support have a procedure for this or is it ever part of any training or meetings? Otherwise I hesitate not to call it a management issue, no offense.
sometimes it's a lack of accessible escalation procedure (no, a bug report is not the same thing as "this feature sucks to use and needs to be revisited), and sometimes it's just the unfortunate fact that those support reps most capable of clearly explaining these issues (or better yet, understanding the underlying mechanisms that cause the issues) get promoted out of front-line support roles (hi)... or move on because they're not satisfied with remaining in support (hi).
obviously there are a ton of exceptions to this rule but i've personally covered just about all those bases throughout my career. i would have loved to have seen engineers get involved with the burden of support, but maybe that's just because i came out of dysfunctional shops... not that they're not all dysfunctional in one way or another.
The moment you have stubborn engineer who knows better than PM and user, it is really difficult to get anywhere. However if you will put such engineer into line of fire from a users that's suddenly not engineer's friendly PM trying to tell the engineer that this is wrong, these are frustrated people who would like to skin engineer alive as a punishment for using his "awesome" creations! That induces fear, but absolutely also crushes his ego, because somebody is berating product of engineer's genius like it would be a retarded hamster.
From my perspective, it is not about showing that PM is an idiot, it is about humbling your engineers. Their ego will grow again and this exercise will need to be repeated.
I would think the engineers usually get their kick out of making things fast or easy to maintain. If you have a product manager and the customers hate the product, how is that the engineers fault?
I've built a couple useless features that I wouldn't want to use and couldn't explain how to use. But if you have a product person, they get to design is BECAUSE they're in the line of fire.
That's a comfortable position to be in as an engineer, except that you sometimes have to build things more than once.
- The PM(s) are bad at listening to customers or turning customer feedback into a focused set of requirements.
- The engineer(s) are bad at following the requirements or going back to the PM(s) when the requirements aren't clear.
In the first the PM(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product.
In the second, the engineer(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product.
In either case, it results in the product not fitting the customer needs. I think there are better ways to solve either gap than just having the engineers join sales calls to hope it works out, but I suppose any approach is better than letting the problem sit.
Every human has an opinion on practically everything. But has that human put in the effort to justify pushing that specific opinion?
In this case, is the opinionated engineer humble enough to realize that using software in their day to day life does not equal using software in our customer's context?
Glad I'm at a place where i can talk directly to people instead of having to go through layers of indirection. I takes away from my engineering time but now i'm always building the right thing, so it is much more productive.
They think PM's don't provide value, so they ignore what PM's say.
It's only when they hear from customers directly that they go... oh, so these needs are real? I thought it was just PM bullshit.
In a healthy workplace this doesn't happen. But sometimes engineers need to talk to customers to trust that the stuff their PM has been telling them is actually true. And then the relationship becomes more collaborative and trusting.
That’s been my experience all my tears in industry.
Unfortunately, that's not always possible. I wonder if that's why I always liked building tools for "internal" clients, other users within the org - it was trivial to just Slack someone or ask if I could walk over to their desk.
The TL;DR message should be make sure the real needs get serviced.
I have been at countless places where the engineers are out of sync with the product.
And it might be something silly like their coworker added something they didn't know about and the UI is now confusing. Could even be the website started proclaiming something that didn't align well with the product.
Another factor is that the [product -> PM -> bug system -> engineer -> fix -> QA -> product] loop is heavy. It takes a long time and major things get fixed but minor friction doesn't.
having [product <-> engineer] can be amazing.
Engineers might have never encountered the full experience, or may merely be out of sync with how it works today vs last year.
- force all the communications with the users through Project Managers or Product Owners. Sometimes they are great and sometimes they are terrible.
- The customers refuse to talk to the developers and so they are forced to interpret the users managers requirements without any further input.
- The developers just want to write code and refuse to meet the customer forcing all communication through their product manager or bug tracker.
- I have seen a couple of times where commercial software platforms were used the technology can get in the way, they are limited in the types of modifications and customisations that can be applied and this can make some workflows really awful.
There is always a disconnect somewhere, someone blocking a conversation happening and it can be the customer, a middle man or the developers causing it, often its all three to get a really dysfunctional system or the solution has been chosen before any developers or users really got into the details and its the wrong choice.
There are a lot of ways to make systems that aren't very good for the users.
(i'm definining "sales calls" as the initial discovery call before a demo or proof of concept is agreed upon. i would be okay with having engineers _ride along_ for complex presales demos, but even then, product should really be serving that role.)
most of the stuff i've built as a direct result of customer interaction has been later deleted, as it becomes a maintenance burden with limited utility even for the customers who initially needed it. software should actually be planned, not written in response to somebody's gripes.
https://old.reddit.com/r/Entrepreneur/comments/1mw5yfg/force...
> Sounds like you have no product managers or your PMs suck. The platform must also be dead simple if it can be rewritten in two weeks.
And the OP's response:
> we pride ourselves in not hiring any product folks until after we raised our series A. this helped us stay super lean, move fast, and build exactly what our customers want.
...which then gets called out as pretty much in direct conflict with what came before.
To me, this screams a real failure of product management. They can't communicate the needs of their customer to their engineers or push back against them? Having engineers take sales calls is not going to scale when you have an actually mature base of customers.
If this product manager really wants Engineers to take sales calls, the Engineers need to earn part of the commission on the accounts. That is the only fair way to do this. I would never take a sales call without part of my compensation being commissions based.
Once a customer knows the person who actually builds the product, they will short cut:
- Customer Service
- Product Management
- Any other sane defenses you put in to protect a developer's time.
And just contact me directly.
Then what do I do to get them off of me without losing a customer?
... That is why engineers don't get on support calls.
If I could be "Anon E. Mouse" for the engagement, that'd be fine. But fact is, that's not what happens.
- the salesperson told you what? no, we don't do anything like that
- oh, yeah, this is easy, you don't really need our product, just use X
- yeah, we have vague plans to do that, but no real schedule. its gonna be a major lift
- once we finish coding and testing that, its gonna be great!1 - Those people were not able either to capture what the customers really wanted, or to translate this into requirements for the developers, or both things at the same time.
2 - Due to the fact that their minds are trained to see things systematically, maybe you should remove all those layers between customers and developers.
...but if you tried to make me do even one sales call, at all, ever, for any reason, that would instantly terminate my interest in working for you.
The amount of information that gets lost in hand-offs can be incredible. People directly involved in developing the product really need to be more involved with the customers, but I personally have had only bad experiences with organizations enabling this. Those responding here that they get to in some manner, I'm jealous.
While it was interesting to see what companies wanted and how they were sold our product, it wasn't extremely illuminating.
The features that customers wanted were already on our roadmap, we had one feature that customers found confusing and hard to use, but it was written that way to meet the needs of our largest customer.
Engineering wanted to streamline it but then it wouldn't have met that customer's needs. Eventually we wrote a "lite" version of the feature that was easier to use and turned that on for everyone but the big customer. (but that didn't come about because of engineers sitting on sales calls, we all knew it was hard to use but couldn't change it until it was on our product roadmap.
User looks at system, doesn't know what to do... I say oh, just press F1 for help (it was back in the MS-DOS era), Russ says.. "how is he supposed to know that?"
I was then enlightened.
Ex: It doesn't require you to be forced into doing it 24/7 for everything. You can still do the vast majority of your work alone in your cave.
Not that engineers can't be problematic. But product people who aren't technical enough and badly manage trade offs they don't understand or invent out of thin air outnumber engineers who are pigheaded know it alls more obsessed with technical minutae than product success.
Another one I see in the same ballpark is hiring a bunch of outsourced coders and then wondering why velocity and quality goes down. (Because you're multiplying the mythical man month effect by the skill difference between a day laborer from Home Depot and someone with significant skills/domain knowledge like a welder or electrician.)
> Our support tickets dropped 70%.
If this isn't fake something is extremely wrong with this picture.
Not that I'm disagreeing with you, but it's a very common way for things to go wrong.
semitones•3h ago
ranger_danger•2h ago
dghlsakjg•2h ago
The kindergarten game of telephone is the perfect demonstration. You only end up with distorted messages if you have many players between the sender and the receiver. If you play telephone with 2 people, you end up with a boring game where any mistakes in communication are immediately resolved.
davorak•2h ago
Other than mistakes in communication, engineers often know what the hard trade offs are when designing a new feature while sales and PMs do not. They can ask the questions to find out if a customer is on one side of a trade off or the other. Or if a feature is 10x as expensive to implement because the customer needs/wants the benefits on both sides. Finding that out at the start can save a full development cycle of time/effort at times.
dghlsakjg•1h ago
I frequently run into the issue of PMs spending more time discussing and trying to slot a feature into the roadmap than it would take to just implement it. Most recently it was with trying to scope out how long it would take to ingest encrypted files. I wrote the feature and had a pull request up before the end of the meeting where they were trying to figure out if we could implement it this quarter or next.
The inverse is when a feature is assumed to be technically easy to implement (just change that setting), and you have to gently explain why that will take a week.
Having people who are technically competent in the meeting often allows a short circuit to getting tot the solution along a pathway that a PM didn't know esited ro was possible through no fault of their own.