5 ms·

There are only 40 hours in a productive work week (if you care about your health). In those 40 hours you simply cannot do everything needed to manage a softwar

There are only 40 hours in a productive work week (if you care about your health). In those 40 hours you simply cannot do everything needed to manage a software project. So we specialize. Some folks focus more on one set of problems, and others focus on other sets of problems. There should be a good amount of crossover, but having "specialists" who "own" aspects of a software project has been found, over and over again, to be the most effective way of managing a software team. Two roles that do not fit into one person's brain are Product Manager and Software Engineer. Should a Software Engineer be knowledgeable about what the Product Manager is doing? Yes. Should the Product Manager be knowledgeable about what the Software Engineer is doing? Yes. Should those roles be merged? Absolutely not. Product ownership should be left to the Product Managers. Product vision, purpose, and strategy should be available to everyone, and everyone should have a say, but to think that Software Engineers should also do Product Management is ignoring how much work both jobs entail. I write all of this having actually read the article, and knowing the article doesn't actually say anything I'm disagreeing with here, but I feel it's important enough to say these things anyway. Software Engineers are in those roles not because they cannot do other roles, but because someone needs to write the software, and writing software is a hard enough job that it's more or less the only thing a Software Engineer should need to focus on. I think people forget that sometimes.

suyash 4y ago
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.
DragonStrength 4y ago
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."
- eightysixfour 4y ago
  > 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.
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
siva7 4y ago
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.
DrJokepu 4y ago
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.
kettlecorn 4y ago
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.
- QuercusMax 4y ago
  Isn't that Associate Producer role something like a Program Manager (PgM) / Technical Program Manager (TPM)? That's been my experience at Google.
  - danielmarkbruce 4y ago
    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.
- klabb3 4y ago
  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.
lamontcg 4y ago
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.
- tomc1985 4y ago
  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.
  - MattGaiser 4y ago
    > 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.
    - 4y ago
seshagiric 4y ago
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.
jjtheblunt 4y ago
> 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.
cupofpython 4y ago
>____ 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.
glonq 4y ago
> 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.

suyash 4y ago

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.

DragonStrength 4y ago

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

eightysixfour 4y ago
> 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.
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]

siva7 4y ago

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.

DrJokepu 4y ago

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.

kettlecorn 4y ago

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.

QuercusMax 4y ago
Isn't that Associate Producer role something like a Program Manager (PgM) / Technical Program Manager (TPM)? That's been my experience at Google.
- danielmarkbruce 4y ago
  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.
klabb3 4y ago
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.

lamontcg 4y ago

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.

tomc1985 4y ago
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.
- MattGaiser 4y ago
  > 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.
  - 4y ago

seshagiric 4y ago

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.

jjtheblunt 4y ago

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

cupofpython 4y ago

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

glonq 4y ago

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