Hacker News Reader

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.

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.

this

and I speak as one of the 90%

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

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.

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.

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?

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.

Poor leaders gonna lead poorly.

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.

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

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.

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.

> Every previous job I've had has a similar pattern. The engineer is not supposed to engage directly with the customer.

Chiming in to say I’ve experienced the same.

A coworker who became a good friend ended up on a PIP and subsequently fired for “not performing” soon after he helped build a non technical team a small tool that really helped them do their job quicker. He wasn’t doing exactly as he was told and I guess that’s considered not performing.

Coincidentally the person who pushed for him to be fired was an ex-Google middle manager.

I’ve also seen so commonly this weird stigma around engineers as if we’re considered a bit unintelligent when it comes to what users want.

Maybe there is something to higher ups having some more knowledge of the business processes and the bigger picture, but I’m not convinced that it isn’t also largely because of insecurity and power issues.

If you do something successful that your manager didn’t think of and your manager is insecure about their own abilities, good chance they’ll feel threatened.

The sad thing is it doesn't have to be this way.

I worked on an internal tools team for a few years and we empowered engineers to fix user issues and do user support on internal support groups directly.

We also had PMs who helped drive long term vision and strategy who were also actively engaging directly with users.

We had a "User Research" team whose job it was to compile surveys and get broader trends, do user studies that went deep into specific areas (engineers were always invited to attend live and ask users more questions or watch raw recordings, or they could just consume the end reports).

Everyone was a team working together towards the same goal of making these tools the best for our internal audience.

It wasn't perfect and it always broke down when people wanted to become gatekeepers or this or that, or were vying for control or power over our teams or product. Thankfully our leadership over the long term tended to weed those folks out and get rid of them one way or another, so we've had a decent core group of mid-level and senior eng who have stuck around as a result for a good 3 years (a long time to keep a core group engaged and retained working on the same thing), which is great for having good institutional knowledge about how everything works...

> The engineer is not supposed to engage directly with the customer.

I don't know if companies have finally stopped pretending to be "agile"; but if not, this is such a clear demonstration of how they are anything but.

Theres another thread on HN at the moment about legislation being written by industry and rubber stamped by law makers. What hit me about this discussion and that one is that there's a lot of self interest out there with very little scrutiny or auditing. It boils down to that basically. If we want to fix problems at the top there needs to be independent auditing, reporting and consequence for people that do the wrong thing. But we all know thats not going to happen so buckle up and learn to live with broken laws and broken software.

Where I work we regularly bring in engineers to talk to clients directly. Clears up a lot of confusion when there’s something technical a PM wouldn’t understand. We still like to have a filter so a client isn’t trying to get the engineer to do free work. Having engineering isolated is pretty bad IMO.

There are very good less-cynical reasons. I've also seen companies with the opposite problem, where the engineers constantly shoot down real, important feedback brought by customer support in order to preserve the superiority of engineering over support.

If you have ten engineers and even just 100 customers, you have a very high number of conversational edges. Good luck keeping things consistent and doing any sort of long-term planning if engineers are turning the output of those conversations directly into features. "Engineers talking to customers but not making any changes" would be more stable, but is still a very expensive/chaotic way to gather customer feedback.

Additionally, very few of those single engineers have a full knowledge of the roadmap and/or the ability to unilaterally decide direction based on some of the customer feedback or questions. "Will this get fixed in the next two weeks?" "Will you build X?" etc. You don't want your customers getting a bunch of inconsistent broken promises or wrong information.

The best-managed orgs I've seen have pretty heavy engineering and user experience in their product and support orgs. You need people in those roles with knowledge of both how it's built AND how it should be used, but you can't continually cram all that knowledge into every single engineer.

A startup should start with the builders talking directly to the customers. But at a some point, if successful, you're going to have too many people to talk to and need to add some intermediaries to prevent all your engineering time going to random interrupts, and centralization of planning responsibilities to ensure someone's figuring out what's actually the most important feedback, and that people are going to work on it.

On the contrary, the best products are typically built by the users of the products. If you are building a product you don't use, it will be worse than if you used it.

Users should be everywhere, in and out of engineering.