[martinpw]

Engineers have a perception that most other roles are lesser and if only they were allowed to be in charge things would go better. I certainly used to be this way. When I was an engineer I used to regularly engage directly with customers, and it was great to be able to talk with them one to one, address their specific issues and feel I was making a difference, particularly on a large product with many customers where you do not normally get to hear from customers much. Of course once these customers had my ear, the feature requests started to flow thick and fast, and I ended up spending way too much time on their specific issues. Which is just to say that I've changed my views over time.

In retrospect, the customers I helped were ones that had the most interesting problems to me, that I knew I could solve, but they were usually not the changes that would have the biggest impact across the whole customer base. By fixing a couple of customers' specific issues, I was making their lives better for sure, and that felt good, but that time could have been used more effectively for the overall customer base. PMs, managers etc should have a wider view of product needs, and it is their job to prioritize the work having that fuller context. Much as I felt at the time that those roles added little value, that was really not true.

Of course agreed that all the points made above for PMs, managers, support having their reasons to obstruct are true in some cases, but for a well run company where those roles really do their job (and contrary to popular opinion those companies do exist), things work better if engineers do not get too involved with individual customers. I guess Google might be a good example - if you have a billion customers you probably don't want the engineers to be talking to them 1:1.

[palata]

> Engineers have a perception that most other roles are lesser

Do they? I always felt I was at the bottom of the chain. "Moving up" means leaving engineering and going into management.

> and if only they were allowed to be in charge things would go better.

Could this be an oversimplification? Engineers understand how the product is built because they are the ones building it. And sometimes they are exposed to what other people (e.g. product people) have decided, and they know a better way.

As an engineer, I am always fine if a product person listens to my saying that "doing it this way would be superior from my point of view", somehow manage to prove to me that they understood my points, but tell me that they will still go a different direction because there are other constraints.

Now I have had many product people in my career who I found condescending: they would just dismiss my opinion by saying "you don't know because you don't have all the information I have, and I don't have time to convince you, so I will just go for what you see as an inferior way and leave you frustrated". Which I believe is wrong.

Overall, I don't make a hierarchy of roles: if I feel like someone is in my team, I play with them. If I feel like they are an adversary, I play against them. I don't feel like I am superior to bad managers or bad product people; I just feel like they are adversaries.

[wood_spirit]

It’s oblique but this puts me in mind of an old adage I recently heard about war: Of 100 men, one should be a warrior, nine should be soldiers, and 90 shouldn't be there at all.

I think this is true of software developers too: only in companies, the 90% don’t really know they shouldn’t be there and they build a whole world of systems and projects that is parallel to what the company actually needs.

[librasteve]

this

and I speak as one of the 90%

[Rapzid]

This reads like it was written by a PM. You lacked higher level context and prioritization skills early in your career so the take away is it's best to divest agency to others?

There is a whole modern line of thinking that leaders should be providing the context and skills to give high performing teams MORE agency over their work streams.

[avidiax]

I think he has a point. These power structures exist for some good reasons as well.

The opposite thing (engineers engaging directly with customers) can eventually lead to customer capture of your engineering org. You shouldn't have a small group of existing, noisy customers directly driving your engineering to the detriment of other existing or future customers.

Microsoft had customer capture institutionally: the existing big corporate customers were all that mattered. It lead to rebooting Windows CE into Windows Mobile way too late to make a difference, for example. But it also meant that backwards compatibility and the desire to ship Windows XP forever were sacred cows.

There are also nasty games that can be played by soliciting negative feedback for political advantage.

Dysfunction can exist with any structure. It's probably best that there's some small amount of direct user feedback as well as the big formalized feedback systems, at least so that one is a check for the performance of the other. If the user engagement team says everything is good, but there are massive Reddit threads about how horrible the product is to work with and the engineers know it could be better, it's time for engineering to start addressing the issues alongside feedback to the user engagement teams.

[majormajor]

There's not enough hours in the day for everyone to do everything.

> There is a whole modern line of thinking that leaders should be providing the context and skills to give high performing teams MORE agency over their work streams.

Yes, this is great for agency over implementation, because leaders do not have context to decide and dictate the What/How of implementing every single change or solution to a problem. And the implementers need to know the context to ensure they make decisions consistent with that context.

But "leaders providing the context" is very different from "everyone researching the context on their own." So where are leaders getting this context from? A not-very-differentiated pile of 1000 generalist engineers-who-also-talk-to-customers-frequently-and-manage-their-own-work-streams? Or do they build a team with specialists to avoid needing the majority of people to constantly context-switch in a quest to be all of context-gatherers, work-prioritizers, market-researchers, and implementation-builders?

[andrewprock]

There are many leaders that use information as a tool that serves their own needs.

They may have the context, but they are either too focused on their own job to share it, or actively manage dissemination so they can manipulate the organization.

In my experience, this is the typical operating mode, though I do not think it is sinister or malicious - just natural.

[Rapzid]

Poor leaders gonna lead poorly.

[mike_hearn]

Agree that this can be an issue but to clarify, I was finding bugs or missed outages, not gathering feature requests or trying to do product dev. Think "I clicked the button and got a 500 Server Error". I don't think random devs should try and decide what features to work on by reading user forums - having PMs decide that does make sense as long as the PM is good. However, big tech PMs too often abstract the user base behind metrics and data, and can miss obvious/embarrassing bugs that don't show up in those feeds. The ground truth is still whether users are complaining. Eng can skip complaints about missing features/UI redesigns or whatever, but complaints about broken stuff in prod needs their attention.

[mixmastamyk]

An org can always go too far in the opposite direction, but this is not an excuse to never talk to the customer. The latter is much more likely, so the warning to not get “into bed” with the customer falls flat.

This is a common pattern here. Alice says 0 degrees is too cold, I prefer 20C, Bob chimes in “100C is too hot, it’ll kill us.” Ok, well no one said or implied to crank it to one hundred.

[liveoneggs]

every customer complaint is N customers lost who don't say anything

"the biggest impact" isn't knowable so a bird in hand is worth more than whatever might be in the bush

[majormajor]

If you have M customer complaints, and each one risks a differently-sized N customers... you better try to triage that vs just playing whack-a-mole with whatever comes to a random engineer first. I've never seen engineers plow through a bunch of 0-or-1-customers-would-actually-churn-over-this papercuts because it was easy and it feels good - the customer mentioned it! i fixed it! - while ignoring larger showstoppers that are major customer acquisition and retention barriers.

Nothing is knowable in only the same way that plans are useless but planning is essential.