3 ms·

Generally we aren't paid for our business expertise. In fact, most businesses actively resist giving developers deep domain responsibility. This is manifest in

Generally we aren't paid for our business expertise. In fact, most businesses actively resist giving developers deep domain responsibility. This is manifest in management methodologies: developers are largely interchangeable cells in a spreadsheet. I'm not saying this is a good thing. The reasons for this are complex, but generally, business people want us to solve the technical problems they can't handle themselves, they don't want us to "relieve" them of product management, customer relationships, and industry knowledge. Why would they? It would devalue them.

rrr_oh_man 1y ago
> Generally we aren't paid for our business expertise. In fact, most businesses actively resist giving developers deep domain responsibility. Chicken/egg imho.
yobbo 1y ago
Yep. A developer with "business impact" might be seen as a liability. One aspect might be that a developer who engages in "business" effectively stops being "subordinate". Management decisions need to be justified on a different level to maintain legitimacy.
- ryandrake 1y ago
  This thread is kind of wild and something I've never heard anywhere in tech. Every place I've worked would consider a developer at least 5X more valuable if they actually had business or product sense, and could operate without the need for constant symbiosis with a "product guy". At one BigTech company we've all heard of, our division didn't even have product people. The engineering lead was expected to handle all of the product duties, and they wouldn't hire you if they didn't think you could at least grow into that role. It's one of the reasons I went back for a business degree and then re-entered tech. No, of course nobody in Silicon Valley cares about the "MBA" title (HN sees it as a negative), but everywhere I've interviewed/worked they've appreciated that we could talk about the economic and business impact of the software, and not just the algorithms and data structures.
  - zero_shift 1y ago
    That sounds great, and I would advise you to value it. Most tech companies are not this forward thinking (often to their own detriment)
pydry 1y ago
Im somewhat puzzled as to why so many devs are insistent that being a good developer means you need to be a good PM. These roles require wildly different skills and knowledge. Usually the outcomes are better if you combine two people who are good at their jobs rather than hoping one person can do it all.
- necovek 1y ago
  Good engineering skills are transferable to being a good PM: you need to break down problems, scope them to fit a particular time allotment, estimate an effect on user experience (stats, tracking, what is a good signal and what isn't) and have the agility to react to changing requirements as things are getting built. Why it makes sense for them to be a single person? Often, "changing requirements" really comes from an engineer learning new things (this framework does not provide this, this external dep is going to be late, I'd need to learn 2 new things so will need more time...), and really, an engineer is the first one who'll know of some of the challenges and what's even feasible! Now, the skills an engineer needs to develop to be a good PM is good communication and ability to document things at the right level, and lots of empathy for a customer and a business person (so they can "walk in their shoes"). Arguably, all things that will make a great engineer even better. I've been in teams where we've had a very senior, experienced PM tell us that he's looking for another position in the company because our team does not need them: we already did the stuff they were hired to do. That was a sign of a great PM who did not try to actively wrestle control out of our hands when the team was chugging along just fine.
  - pydry 1y ago
    Breaking down problems (vertical slicing) isnt inherently a dev skill. Insofar as it is a transferable skill to break down problems it is more of a life skill. Scoping tickets is more of a project management skill. Again, not a dev skill. Estimating effect on user experience - requires empathy, again not a dev skill. If you redefine the dev job as including PM skills then sure, PM skills are dev skills. But theyre not. >Why it makes sense for them to be a single person? Often, "changing requirements" really comes from an engineer learning new things So? Happens to me too. I can tell the PM these things i learned. Thats a hell of a lot easier than managing all stakeholder interactions, empathizing and balancing their demands. It only really makes sense to combine the two roles if the project is inherently very straightforward, a salary can be saved and the person doing both roles is suffiently qualified for both roles.
roguecoder 1y ago
The result of that top-down management style is buggy code, blown deadlines, security holes, and the slowest software development I've ever seen. I've found it possible to migrate to a less top-down Desert style just by finding executives who are frustrated by those problems and saying, "I have an idea I've seen help" and then getting the team together and saying, "hey, it turns out the executives would like us to write software well. What should we try first?" Product has plenty of work remaining: they should be handling whatever subset of strategy, prioritization, analytics, BI, QA, facilitation, design and contracts that they have the skills for. But it requires engineers to actually collaborate with them as a peer, rather than engage in power struggles, and that requires everyone on the team to understand what we are building, for whom, and why.

rrr_oh_man 1y ago

> Generally we aren't paid for our business expertise. In fact, most businesses actively resist giving developers deep domain responsibility. Chicken/egg imho.

yobbo 1y ago

Yep. A developer with "business impact" might be seen as a liability. One aspect might be that a developer who engages in "business" effectively stops being "subordinate". Management decisions need to be justified on a different level to maintain legitimacy.

ryandrake 1y ago
This thread is kind of wild and something I've never heard anywhere in tech. Every place I've worked would consider a developer at least 5X more valuable if they actually had business or product sense, and could operate without the need for constant symbiosis with a "product guy". At one BigTech company we've all heard of, our division didn't even have product people. The engineering lead was expected to handle all of the product duties, and they wouldn't hire you if they didn't think you could at least grow into that role. It's one of the reasons I went back for a business degree and then re-entered tech. No, of course nobody in Silicon Valley cares about the "MBA" title (HN sees it as a negative), but everywhere I've interviewed/worked they've appreciated that we could talk about the economic and business impact of the software, and not just the algorithms and data structures.
- zero_shift 1y ago
  That sounds great, and I would advise you to value it. Most tech companies are not this forward thinking (often to their own detriment)

pydry 1y ago

Im somewhat puzzled as to why so many devs are insistent that being a good developer means you need to be a good PM. These roles require wildly different skills and knowledge. Usually the outcomes are better if you combine two people who are good at their jobs rather than hoping one person can do it all.

necovek 1y ago
Good engineering skills are transferable to being a good PM: you need to break down problems, scope them to fit a particular time allotment, estimate an effect on user experience (stats, tracking, what is a good signal and what isn't) and have the agility to react to changing requirements as things are getting built. Why it makes sense for them to be a single person? Often, "changing requirements" really comes from an engineer learning new things (this framework does not provide this, this external dep is going to be late, I'd need to learn 2 new things so will need more time...), and really, an engineer is the first one who'll know of some of the challenges and what's even feasible! Now, the skills an engineer needs to develop to be a good PM is good communication and ability to document things at the right level, and lots of empathy for a customer and a business person (so they can "walk in their shoes"). Arguably, all things that will make a great engineer even better. I've been in teams where we've had a very senior, experienced PM tell us that he's looking for another position in the company because our team does not need them: we already did the stuff they were hired to do. That was a sign of a great PM who did not try to actively wrestle control out of our hands when the team was chugging along just fine.
- pydry 1y ago
  Breaking down problems (vertical slicing) isnt inherently a dev skill. Insofar as it is a transferable skill to break down problems it is more of a life skill. Scoping tickets is more of a project management skill. Again, not a dev skill. Estimating effect on user experience - requires empathy, again not a dev skill. If you redefine the dev job as including PM skills then sure, PM skills are dev skills. But theyre not. >Why it makes sense for them to be a single person? Often, "changing requirements" really comes from an engineer learning new things So? Happens to me too. I can tell the PM these things i learned. Thats a hell of a lot easier than managing all stakeholder interactions, empathizing and balancing their demands. It only really makes sense to combine the two roles if the project is inherently very straightforward, a salary can be saved and the person doing both roles is suffiently qualified for both roles.

roguecoder 1y ago

The result of that top-down management style is buggy code, blown deadlines, security holes, and the slowest software development I've ever seen. I've found it possible to migrate to a less top-down Desert style just by finding executives who are frustrated by those problems and saying, "I have an idea I've seen help" and then getting the team together and saying, "hey, it turns out the executives would like us to write software well. What should we try first?" Product has plenty of work remaining: they should be handling whatever subset of strategy, prioritization, analytics, BI, QA, facilitation, design and contracts that they have the skills for. But it requires engineers to actually collaborate with them as a peer, rather than engage in power struggles, and that requires everyone on the team to understand what we are building, for whom, and why.