Forced every engineer to take sales calls.They rewrote our platform in 2 weeks
17 comments
·August 21, 2025dcastonguay
bnug
That could be the case, but I work in a mechanical engineering group as the only person on the team who can write code or automate things with it. We're in a large corporation with a sizeable IT support group that builds a decent chunk of the software in-house, and our team views much of it as terrible. So, I've rewritten applications or supplemented the "terrible" but irreplaceable software with tools to make our jobs much easier. I don't think that I'm better than our in-house IT folks at software development but that my perspective as an actual end-user gives me a much better idea of how to meet our own needs. I'm also highly motivated to make it effective, since I'll be using it. So, the title initially resonated with me and didn't see this comment coming. That said, I'm sure your point is valid in many cases as I'm not familiar with formal software development / project management.
HPsquared
Many such cases of employees adding negative value.
maerF0x0
You're assuming they have Product Managers at all. Or that they're not massively oversubscribed.
sc68cal
-10x employees DO exist!
barbazoo
Agree, also the whole thing reads kinda fake in the first place.
vkou
This is the first thing that struck me. Why does the OP still have a job if a line engineer can do it better?
Promote the guy to CTO, and fire the useless chumps who were collecting a paycheck spinning their wheels.
semitones
This is an excellent strategy for smaller startups, where every individual contributor needs to have an understanding of the customer's needs, in order to develop an understanding of what kind of product must be built. I have much more success in projects where I deeply understand the product requirements (because I am involved in defining them), than those where the product requirements are "handed" to me and I just have to implement something that satisfies them.
ranger_danger
Are you saying that you follow directions better because you wrote them... or that you are just ending up with a better UX because of your involvement?
dghlsakjg
Human communication is incredibly lossy (sometimes intentionally), plus humans will try to fill in gaps with assumed information. The more people you cut out between the message sender and the receiver, the more likely the message is to still be intact.
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
The telephone game is the analogy I use too when explaining the value of having engineers in the custom calls.
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.
pseudocomposer
At my company, as developers, we rotate taking support tickets and working directly with customers on the issues our (very capable) support team can’t handle. We and our customers are both very happy with the results.
justtinker
Out come the "this is dumb because .." messages in the redit responses. I have experiences dozens of projects where the developer had the wrong view of the end use needs for a myriad of reasons (everything after the because). It doesn't matter why in this case just that they found their solution.
The TL;DR message should be make sure the real needs get serviced.
ranger_danger
Thankfully the comments agree that OP was the problem all along.
richwater
All this says to me is that they have no technical product/program management in place to actually do what is described.
theshrike79
Dogfooding works
pavel_lishin
I don't think this is an example of that. This is just engineers being able to talk directly to customers, which is great in most cases. I absolutely loved my jobs where I could directly talk to the users of our products, especially when they came to me with bugs or problems.
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.
> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product.
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.”