Someone apply this to the Microsoft 'teams' team please.
I forced every engineer to take sales calls and they rewrote our platform
71–80 of 221 posts
Re: I forced every engineer to take sales calls and they rewrote our platform
#72Earlier quoted context omitted.
Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints. The moment you have stubborn engineer who know…
God forbid an engineer should have an opinion on UI/UX.
But is it an informed opinion?
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?
Re: I forced every engineer to take sales calls and they rewrote our platform
#73My best projects have been where I code side by side with the actual users or subject matter experts. Built a small business loan approval app for a bank, sat right beside the underwriters. Airport billing system, worked one door down from accounting. They came to standup everyday, you take breaks with them, gradually they feel like they own the product.
Ideally, folks would practice mob programming that includes rotating customers into the room in addition to a designer and a product manager. But, so many engineers have had bad experiences with pair programming that they allergically jump to making strawman arguments against even considering mob programming.
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.
Re: I forced every engineer to take sales calls and they rewrote our platform
#74> 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/ac…
I run a small tech startup, about 2M ARR. And at times we’ve been short staffed on support and I’ve sat in for support for a day or two. And every time I do this I discover loads of issues customers are complaining about that don’t seem to ever make it back to our engineering team. Perhaps it’s just our support reps, or the nature of support, but they seem to love to “solve” problems themselves rather than reporting…
> don’t seem to ever make it back to our engineering team
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.
Re: I forced every engineer to take sales calls and they rewrote our platform
#75As an engineer, there's only one reason I don't want to be on customer calls: 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 cal…
Yes, god forbid that an engineer would be contacted directly to solve a problem they have. The thought alone.
Re: I forced every engineer to take sales calls and they rewrote our platform
#76> 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/ac…
Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints. The moment you have stubborn engineer who know…
PMs don’t help make good software.
Re: I forced every engineer to take sales calls and they rewrote our platform
#77Earlier quoted context omitted.
God forbid an engineer should have an opinion on UI/UX.
But is it an informed opinion? 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?
If I use the product, I'd expect that feedback to get the same weight as any other customer. And not be dismissed because it came from a 'technical' person.
Re: I forced every engineer to take sales calls and they rewrote our platform
#78> 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/ac…
I wonder if LLMs might be replacing these type of PM jobs where they gather up feedback (usually it's mostly in text form anyways), and translate and summarize so engineers can cut out some noise and confusion from PMs.
I'd say it's about as likely as LLMs actually replacing the engineers in implementing the code in the next couple of years. I think it's more likely LLMs end up being like every other tech advancement: a way to increase the total amount of stuff being done, but not actually lower the need for people to use them.
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.
Re: I forced every engineer to take sales calls and they rewrote our platform
#79> 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/ac…
I run a small tech startup, about 2M ARR. And at times we’ve been short staffed on support and I’ve sat in for support for a day or two. And every time I do this I discover loads of issues customers are complaining about that don’t seem to ever make it back to our engineering team. Perhaps it’s just our support reps, or the nature of support, but they seem to love to “solve” problems themselves rather than reporting…
speaking as someone who clawed their way up out of the support mud...
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.
Re: I forced every engineer to take sales calls and they rewrote our platform
#80Earlier quoted context omitted.
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.
Because he has people skills, damnit! 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
I know you're kidding, but the TPM I work with is basically a stenographer. If we ask him "why" on a requirement, 60% chance the answer is "I don't know, but the customer wants it"