> 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.”

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 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.

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.

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 it to engineering for a more permanent fix.

Yep, notice there was no mention at all about why the original software was so ill-designed in the first place. Not even a curiosity as to why. Your conclusion is more valid, though I wouldn't necessarily place the blame on the PM. Agile/Scrum rituals, where blame is diffused and developers are forced to sprint quickly through poorly-designed tickets, yields poorly-designed software. Who could have guessed? Feels like a systematic problem with the "modern" bloated software organization.

Yea, my first thought was "this is how software used to be written before PMs got their hands in everything".

I find if you sit engineers down with whoever is doing the operational work, you very frequently find you don't need PMs and everyone is much happier.

PMs can be incredible, but my experience is that they tend to be both very territorial and know surprisingly little about either the engineering or the customer side of things.

Many such cases of employees adding negative value.

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.

On the contrary, this pm did provide engineering a valuable lesson, they likely need to repeat every year or so - call it user training, it's a bit like sec training.

My experience is every layer between the communicator and the recipient adds noise. It's like the game of telephone we played as kids. Some PMs are terrible and are 100% noise. Even the best are only 50% signal.

Give an engineer a clear understanding of the end need, and you have a tremendous gain in efficiency. I think there is a 10X benefit here that's similar to the 10X benefit from stronger engineering skills.

You still need PMs, though it's a different job that passing papers back and forth.

It's too bad we didn't have a major movement in software engineering a couple decades back that recognized that playing telephone through a chain of intermediaries (analysts, PMs, etc.) between customers and engineering was an anti-pattern, and articulated as a major principle that engineering should work directly and regularly with the community that the software is being built for.

That has been my experience in multiple occasions, the moment i can sit with a customer and clearly discuss what their needs are and see them operating the tools, it makes the real user experience and workflow issues much easier to fix.

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.

Don't blame it on the PMs (except to the extent they are separating the engineers from the customers).

The closer you can get the engineers to the users, the better your product will be, and this goes all the way to the backend and architecture.

This is true no matter how skilled and well-intentioned are the PMs or sales reps.

I've seen one single layer between the builders and users to help modulate high and constant user demand can help.

Beyond that, even two layers can strangle a project. One project my company was doing for IBM was moving along nicely with the developers talking to the actual users every few weeks as progress was made & delivered. I moved off the project, then IBM inserted a manager to "consolidate the communications" (take all the users' input and boil it down), and a manager at my company (not the engineers) talked to him. The project became one of those endless slogs of feature creep, yet no great success — ultimately deployed for some years, but not the resounding improvements in workflow efficiency they hoped and saw in the beginning.

Absolutely EVERYONE on both teams was competent and really wanted the project to be a great success. But adding the intervening layers, while it seemed more efficient, had only the opposite effect.

Seriously, it ALL happens where the rubber meets the road. Get your developers as close to the end-users' keyboards and screens as possible. Talking directly to the users is great. Even better if you can arrange to have them BE a user for a day or two.

  "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.”

Working with customers now and then simply translates to better products and also less maintenance issues, which is _better_ for said developer.

Most SWEs are almost certainly better at PMing than the average "career" PM. They just don't want to do it.

Agree, also the whole thing reads kinda fake in the first place.

I read it as: Most people are bad at empathy because they've never practiced it, and so forcing them into the shoes of another is a good way to give them a kickstart into the realm.

-10x employees DO exist!

Yes, even OP admits it in a comment down the thread:

> Commenter: Sounds like you have no product managers [...]

> OP: haha we don't :) 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. our platform is definitely not dead simple. but in the early early days, we did rebuild our product 3 times and the 3rd rewrite scaled us to where we are now

Engineers being completely out of touch with the macro picture of the end user experience is the norm, and it's bad.

Engineers work micro features which are sliced out of micro picture epics with maybe a vague Northstar.

Sitting engineers with users is a key thing I'm driving at my work since we're on internal tooling. Pretty much to a tee every participant comes out and goes "Wow... I had no idea that's how people were using our product"

Building user empathy results in greater connections within our organization, puts names to faces in our support channels, and results in more well rounded engineers who develop software with both technical and end user experience concerns in mind.

I mean, there's a reason most software interfaces are still shit, and often physical products too. It's cause we take tons of input from people who haven't extensively thought about user experience a day in their lives

The chances of user->pm->engineer communication introducing ambiguities or inaccuracies approaches 100%. That's simply human nature and the nature of communication. There's a reason why agile programming has stressed "on site user": the programmers need to hear what the users are saying directly, and the users need rapid feedback on what the programmer thinks vs what the user meant.

> the issue was that our PMs are doing a terrible job communicating between customer and engineering

That makes it look like it's the PMs' fault. Yet I bet you wouldn't want a car designed by engineers who never drove one and never directly spoke with someone who did, either. It's that simple.

> DevOps engineer is more capable/actionable at turning customer needs into working solutions

That’s been my experience all my tears in industry.

Most engineers turn up at meetings with product managers with two major problems:

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.

The first rule of Hacker News comments is it's never the engineer's fault

This story is so close to Office Space I just can’t be sure if this is real life anymore https://youtu.be/m4OvQIGDg4I?si=0wLjJArlXXql33vS

Sadly, I've seen a significant number of engineers who simply don't trust what PM's say about what the customers need.

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.

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.

Yes, many PMs suck. And many engineers suck. And communication is always lossy. Having many/all engineers take some calls helps to mitigate those.

You're assuming they have Product Managers at all. Or that they're not massively oversubscribed.

Yes, fire the PMs should be a meme.

Perhaps, but being told something very often cannot possibly replace experiencing it yourself.

I’ve worked at companies where the PMs couldn’t talk to customers…

Good. All Engineers should deal with the clients directly.

Even in orgs with product managers, engineers can have a really bad habit of wanting to rewrite stuff, or designing things the way they want them to work instead of focusing on customer needs and problems

It's one thing to be told (by a PM). It's another thing to believe.

This should be common knowledge

The new "product led" trend seems to be that PMs are much more on the implementation side than on the customer-facing business side.

E.g. I know this guy leading sold-out Product Management workshops in Silicon Valley, who understands nothing at all about actually taking any product to market, about competition, marketing, etc. ... never mind satisfying actual customers.

Well--well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?

Yup. In other words, they have shit PMs.