Hacker News Reader

I spent 10 years working as a software engineer on a product that I was originally a customer of.

I found it really weird that so many engineers and product managers in the company never really used the product the company produced at all.

I don't think that engineers should really be product managers, as an introvert I certainly didn't have the patience to sit in all the meetings that the PMs took every week, which is why I leaned on real actual PMs to do that. However, senior engineers ought to develop at least some Product Management Brain and spend a bit of time literally just using the product like a user and not as a developer.

I don't think software development should be the only thing developers do, at the strict exclusion of all else. They need the ability to be deep in some code and go "wait, is this complicated garbage actually what customers really want?" and throw a mental exception and go have a chat with the PM and determine if the requirements have gotten wildly off course. The mentality of "PMs determine the requirements, I just write the code" is a recipe for a really poor product.

It is weird to me to see people talking like this. Throughout my 10+ year career as an SE, all the way from junior level to senior-plus, customer- and product-mindset thinking has been seemingly mandatory. Like how would I even write the software if I didn't understand what they wanted? What would I even do/what should I even write?

We need to remember at all levels that it is people that use this stuff. Coincidentally, we are also people. So we should all be able to think as them.

It is weird to me to be separated from my stakeholders. I can't say I really like having a PM in between me and them, other than having them sit in meetings instead of me.

> Like how would I even write the software if I didn't understand what they wanted? What would I even do/what should I even write?

Whatever the ticket says. I have done plenty of work that I couldn't tell you where it fit into the product or what button one would click to make it run as we otherwise had unit tests to verify it.

It sounds incredibly demotivating. Is it?

I save that passion for personal projects. After all, the work is buying someone else a nice house and the new electric Delorian.

Well, unless your product makes a real positive impact on people's quality of life or the environment. :) Maybe I'm just fortunate to have such an employer. (Of course my CEO also gets rich in the process, but that's not the only "mission".)

Why should it be demotivating trying do something perfectly as requested?

Many of us, including me, come from freelancing, and perhaps that trained many to answer most customer requests with "ok but what you really want is...", but in a company where there are people doing that as their job... Why bother?

Actually I would even go further and argue that too many passionate developers talking product management in every refinement meeting is a big inefficiency, and depending on the company size, sometimes even one is one too many.

lol because developing products that users want/work well for users is 100x more important than writing code.

Protecting the environment and sustainability is also 100x more important than that. Do we ever draw a line where our responsibilities end or as developers do we have to gather knowledge and make the best decisions until we reach singularity or the heat death of the universe?

Delegating is okay, or you burn yourself out.

Not at all. There are plenty of technical challenges that must be resolved within that. I can be fascinated by the plumbing without really understanding what the data is for.

A lot of it is also personality. I am odd. Very odd. At times Sheldon Cooper odd. Know the exact seat I want on a 787 vs an A220 odd. That makes my empathy for users awful. I will spend tons of money on pain points in my life that make everyone else think I am nuts. I will completely ignore areas of life that are top priorities for most people. I obsess when making decisions and willingly read reems of documents to figure out all the rules.

There are so many things that I do that normal people do not do. Because of that, I cannot create mass market products.I do not think anything like a typical user. I know my limits there.

That's fair! Thank you for the insight.

Empathy/sympathy are important factors here. As a fellow weirdo I do not see my weirdness as an excuse for being unable to 'walk a mile in their shoes'. There are lots of people around us constantly transmitting their emotional status, I see no reason to not pay attention to that.

I have consistently found myself unable to do it well, so I outsource it. People may transmit, but I do not receive it with any meaningful accuracy.

just because you're odd doesn't mean you can't empathize with others. that's a huge cop out.

Fundamentally any feature request is just an engineering problem. Sometimes they're interesting, sometimes they're not. If you trust whoever makes these issues on your board (or whatever it is you use), why would it be demotivating? You know you're building stuff folks want, because making sure that's the case is what the person making those issues is trying to do.

If you can't trust your coworkers, every workplace is demotivating.

This is a fair argument. Thanks for engaging.

That sounds disastrous. "Whatever the ticket says" is often ambiguous, poorly-written, or just plain wrong (in terms that the request is documented incorrectly and the requestor is not actually asking for what they want). Sometimes someone with technical inclinations gets too smart and thinks the solution is X when it is really Y.

In my personal experience, it is much easier to clear this up going to the requestor itself, rather than asking a PM to clear it up. I ask them high-level questions like, "so, what is it that you really want here?" to try and suss out what the actual deliverable is.

But I agree that if you have too many projects on your plate this is untenable. But then devs having too many projects on their plate is a pretty poor situation and is indicative of bad management.

It is only disastrous if the PM screws up. It is certainly more brittle though as there is a single point of failure. You also need devs willing to persist in a social endeavour in the face of uncertainty until they get something solid and many are not.

nope it's always disastrous. PMs don't know how to code.

Because we are supporting too many products as it is and they are always asking for more?

I get snippets from users, but I support so many different types of users and roles, it would take probably 6 months of only training to have a rudimentary understanding of all of those roles and the products we support that they use.

And we implement SAFE "agile" and most of the time it seems like we are insulated from actual users. I got in hot water because I had the audacity to talk to a user because the client kept changing the flow after the inception meeting that ended up being the client solutionizing the project.

What makes the "Product Manager" role tricky is every person and every organization has a wildly different sense of what they do.

You argue that there's not enough room in a person's brain for Software Engineering and Product Management, but "Product Management" often includes planning, strategy, coordination, vision, culture, anything vaguely leadership, and general "adulting". To call all of that mushed together a "discipline" makes no sense.

Skills like coordination and vision are just as orthogonal from each-other as software engineering.

As a result the best PMs are often those who know what control to give up to make the role / team function better.

I've even been on teams where engineers seem hesitant to organize fun events because it may be perceived as stepping on a PM's turf, which is absurd!

I think teams and PMs would benefit from splitting up the role. I'd love to see the creation of roles like "Associate Producer" (as borrowed from the film industry) that have a primary task of keeping things running smoothly without a strong focus on creative or technical leadership.

Isn't that Associate Producer role something like a Program Manager (PgM) / Technical Program Manager (TPM)? That's been my experience at Google.

Good TPM is that and worth their weight in gold... That's the role which should be more common across industry. Being a PM without a TPM sucks.

Yeah. Our problem at $FAANG was that PMs were incentivized by the "footprint" they had on the product. Makes sense maybe when doing greenfield, or for a major revamp, but man did it fuck up existing long-term projects that were essentially in maintenance mode.

You'd see PMs join, change direction, narrowly grabbing a promo and leaving only to be repeated again by the next guy. Each time, the product became more complicated and much less focused.

Things like vision and strategy shouldn't factor into any performance review for at least 2 years, for long term projects. Until you know deeply (a) how everything works and (b) the cost of changing things, nobody should be allowed anywhere near those big buttons.

The only ones who knew that were the senior engineers who had been around forever. And they're not liked by management, because they tend to be nay-sayers, and they often like how things are. But if you asked management if they were willing to break existing customers the answer at the end of the day was always no. Yet they all wanted new and shiny things, in denial of the feasibility and especially cost.

I've never understood why Development Manager and Product Designer are supposed to be the same job.

I've also never understood why product design so often seems to be sidetracked into pointless tinkering with minor changes - often unwelcome - while major issues remain unaddressed.

In reality PM seems to be a stepping stone to more senior management, so products inevitably suffer from tinkering and drift. No one really owns the product - or if they do, it's not for long.

They don't really care because they're heading elsewhere.

The perversity is that if they do care then they're less likely to be heading anywhere, since they won't be seen as a go-getter. The problem extends to the customers too: we all know that solid unexciting dependable quality is to be treasured, yet nothing but the pain of a dozen bad "upgrades" can conquer the lure of the shiny newness.

I've seen there are two distinctly different types of PMs for greenfield and existing products. Product Managers for greenfield and technical program managers for existing products. Their focus tends to be different. Product managers focus on making sure that the product solves the customer problem. Technical program managers focus on ensuring things like quality and supportability are built into the product. Sounds like this might help solve the problem at FAANG.

Eh, some software engineers are good at product. Some are even good at charming clients. You got to understand the people you work with and adjust the processes and roles to match that, not the other way around.

What if your users are developers or engineers? I haven't had a ton of luck with my specific niche and product management (niche domain; final product is a library developers code against) across multiple companies. I can imagine your statements can apply to some future market where we have plenty of engineers, but in the US, we have a shortage. It's hard to imagine how to use your advice when we cannot find enough engineers with the domain and technical skill combo. Let alone one to convert to product. What do we do for the rest of my career which will probably continue to have a shortage of engineers?

Our solution is to trust the experts, but certainly there must be something better than "whatever the current engineer thinks."

> What if your users are developers or engineers?

What if they’re kindergarten teachers, in medical sales, rocket scientists, or Amazon deliver drivers?

Part of the Product Manager’s job is to understand and get in the head of the user, if they can’t do it for your users they’re the wrong Product Manager. If they’re relying on the engineers they the wrong Product Manager.

>____ are in those roles not because they cannot do other roles, but because someone needs to _______

Honestly, this applies to a whole lot of jobs and can be reversed for SWE too. I am a business analyst and have a few stories of working with SWE who would belittle my input to them about anything involving code because I did not code on the daily. More often then not, we would talk in a circle - I would get frustrated and comply with their suggestion, some random issue would come up, then it would be their idea to do the thing I said we should do in the first place. And this wasnt with one-off arrogant SWE that are hard to work with. Just normal people trying to be polite. but I built my initial specs as the bare minimum necessary to fit my need, and because I could not identify off the top of my head exactly what issue would arise from changing those specs (even though I could be sure there would be some issue) - they ignored my specs and did it their own way.

I lean on the SWE as the coding expert overall and would listen to their input.. but sometimes I think SWE forget that they are doing things other people do not want to do which is not necessarily things other people are not capable of doing or understanding. And sometimes a non-SWE can see what is wrong with some structure of the code despite not being able to code the solution themself.

Thanks for stating this so eloquently. Agreed that product is a joint responsibility but what most people miss is the division of labor. Talented dev managers think they will 'solve the problem' and the other types are just jealous. I sometimes joke that a product manager's job is most sought after now a days...everyone from devs to pmms want it . As a PM, this is the single most stressful part.

Ideally the author would have held his PM team on point to deeply involve them in the product process.

It is indeed a product manager's job to rally the team around an idea ir features. They must actively seek dev input on what features to build or how to solve a customer problem. But when devs, especially dev managers think they need not be told what features to build, all beta are off.

> There are only 40 hours in a productive work week (if you care about your health)

There are 50 if you care about career advancement. There are 40 if you care about job security. There are 30 if you care about your mental health. There are 20 if you frequent hackernews and reddit.

Exactly at an IC level (specially for an engineer), it's best to become an expert and specialize, that is how you can bring most value to the organization.

This! I‘ve seen so many teams and products spectacularly failing because someone thought that the lead developer should also be the product manager. For all the hate that software development frameworks like scrum get - the one thing it gets really right is that there are roles that should never be merged in a functional team.

> Two roles that do not fit into one person's brain are Product Manager and Software Engineer.

I'd argue that the ability to perceive a situation from multiple perspectives is a learned skill, and it's particularly valuable when the two perspectives you mention as mutually exclusive can be leveraged by a single person.