8 ms·

It's a question of incentives and accountability. PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Developers

It's a question of incentives and accountability. PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Developers feel the pain instead. PMs won't be honest with the business that they sold an undercooked product. Need to suddenly scale up that "pragmatically" designed database? I know in my heart that too many PMs will _never_ manage expectations with their superiors if they can harangue developers into overtime, out-of-hours alerts or death marches. It’s asymmetric risk. Don't take that personally. I’m sure you, individually, do the right thing. But my experience is that PMs / POs / team leads as a group can be bad actors. It's just the way incentives are structured for middle managers. By the time the problems of your "pragmatic" architecture have emerged, your typical PM / EM / team lead will either be working on another team, doing another job, or talking about "tech debt" as "just one of these things", a mysterious natural force, visiting your team stochastically like a freak summer snowstorm or an outbreak of measles. _That_ is why developers are cautious. Do you _seriously_ think that you are the only person in your team who understands "commercials" or "cost benefit analyses"? Experienced developers do, which is why we've learned the best strategy in the long run is to avoid offering too many concessions to people without skin in the game.

lukasb 4y ago
I'm sorry that you've apparently only worked with bad PMs.
- zero_shift 4y ago
  Unfortunately, you don't have to work with bad PMs very often, to occasionally experience a year or more of misery due to their ineptitude. Good PMs are a bit of a paradox. They are immensely impactful and bring value to every project they touch. Yet they are also far overqualified for what is often a thankless job. I also have come to the view that even good PMs will rarely allocate the work that is truly impactful. Some of the best work of my career has been when I've gone off piste and prototyped something that has surprised my managers or disrupted the way a team thought they had to work. You can't go rogue often, and you have to expend your political capital carefully. But you will never do the best work of your career waiting for someone to assign you it in JIRA.
  - ryanmcbride 4y ago
    Best PMs I've had were former engineers. They aren't ALL great but at least when we'd tell them that to build a feature we have to lay new groundwork instead of blasting out a hack, they generally understand why that's a good idea.
  - idsout 4y ago
    What are the downsides to "going rogue" too often? Where do politics come into play here?
    - gtirloni 4y ago
      PMs promised the business X would get done because it was great. Now they have to explain developer Y didn't deliver that. Disappointment ensues and PM has to sell rogue work as also great (so why wasn't it planned instead of the other less great thing). As someone already said, it's a thankless job and I empathize. Signed: frequently rogue developer.
    - lostdog 4y ago
      If your "going rogue" project fails, then you can be seen as not having done any work for X weeks. If your manager was against you working on that project--especially if they needed you to work on something else--then you will be seen poorly, and that can be rough for your career.
  - unphased 4y ago
    I think it could actually be a pretty good strategy to optimize your job search for the degree to which you might be able to go rogue and get away with it.
    - llamataboot 4y ago
      I am pretty up front about being chaotic good and seeing that historically I add a ton of value when I am given some free rein to fix things or just make some (or a bunch of people's) lives easier, I often seek forgiveness rather than permission but - I am also willing to accept push back (always a hey, this fixes this and that, what do people think? not a "I made the terrible code perfect and you must accept this), I try to be clear about where my time is going is my own assigned work is going slower, not usually because I'm off over-engineering some internal tool. but because when you get a reputation as someone that can help people fix things, lots of your time is about unblocking others cause they trust that they can come to you (which levels the whole team up, but sometimes means individual commitments fall behind), and I am try to push for the whole team to have less fear and more freedom to have a day a month where they just work on whatever tech debt they want, or throw up a quick PR for discussion about something they see, etc etc. And I'm also clear that if the org doesn't see value in what I'm doing, that's their call to make, because I also know I can find one that will. But in my experience the devs that want to /optimize/ for going rogue, are the ones you least want re-engineering your entire auth system overnight with code no one else understands and/or the most abrasive when it comes to arguing about why they are right. It's a gentle balance and being honest, kind, and collaborative goes pretty far....
eldavido 4y ago
> _That_ is why developers are cautious. Do you _seriously_ think that you are the only person in your team who understands "commercials" or "cost benefit analyses"? I realized this attitude is common to all tradespeople, not just developers, but also HVAC techs, roofers, electricians, pretty much anyone who's long-term accountable for supporting a large, complex system. More of an observation than anything.
timr 4y ago
Hi. Former engineer turned PM here. Wow, you're spinning some wild stereotypes here, and while some are based in truth (as are all good stereotypes), I'm going to take issue with this: > PMs won't be honest with the business that they sold an undercooked product. Need to suddenly scale up that "pragmatically" designed database? I know in my heart that many PMs will _never_ manage expectations with their superiors if they can harangue developers into overtime, out-of-hours alerts or death marches. While I've certainly seen incompetent, bureaucratic and/or poorly incentivized PMs, I don't think I've ever met one who wants to throw their developers under the bus to get a job done. I'm not saying it doesn't exist anywhere, ever (big world out there), but you've made a couple faulty assumptions: 1) A PM is not "a middle manager". It's generally a non-management position, despite the title. The classical "PM" has to use soft force for everything, and only gains authority through a history of doing the job well. We're constantly managing expectations in every direction, and "up" is just one more. 2) Even if we were "middle managers", those amongst us who have been working for a while realize it's bad practice to leave a trail of burned-out colleagues behind us, due to a history of bad decision-making. I'll add a third, specific to my own history: 3) one reason PMs might not "care" about scaling up that database, is that it almost never needs to be scaled. Seriously. The engineer side of my brain wants to optimize everything. The PM side is always having to remind that side that most of my engineering life was spent in a cycle of useless premature optimization. The war continues. Anyway, it might be good to talk to your PMs and not assume they're evil villains. And if I'm wrong and you're working in a truly Machiavellian hellhole...you should look around. I hear it's a pretty good job market.
- bb88 4y ago
  > Anyway, it might be good to talk to your PMs and not assume they're evil villains. I've always thought PM's to be more or less aliens with a ray gun tapping at their watch. Communicating with them goes nowhere since they don't empathize with your point of view. The only thing they're concerned with is when something's going to get done. The only form of motivation is threat of existence in the company. > While I've certainly seen incompetent, bureaucratic and/or poorly incentivized PMs, I don't think I've ever met one who wants to throw their developers under the bus to get a job done. Perhaps, it's also possible you've never worked at enough shops to see it. > one reason PMs might not "care" about scaling up that database, is that it almost never needs to be scaled. Seriously. You're not the one going to be called at 4am when postgres takes a dump. If you volunteer to cycle into the on-call hours, I'd feel more compassionate for your point of view. Until PM's do this, I decline to see it that way. I guess I feel like the PM is worthless position unless the PM is writing code along side the team, and can fully appreciate the technical problems -- and more importantly -- offer technical solutions.
lumost 4y ago
Honestly, this tends to be team dependent. In any organization, there is often some "group" who is pushing to ship. Likewise, there is often a group that feels "stuck" with any fallout from a delivery - and none of the success. This could be Product vs. Engineering, Engineering vs. Support etc. Where this border breaks down varies from org to org. No one likes having the short end of a stick. Usually if the teams have more mixed ownership boundaries and feel "the win" of a launch, then this becomes less of an issue.
thaneross 4y ago
It's almost like there might be better alternatives than command-and-control structures when building software.
- collyw 4y ago
  We are doing a democratic design by committee. I am fairly sure that will work out worse in most cases.
  - thaneross 4y ago
    Is it democratic in that people vote for a solution? Or is it everyone talks about it and consensus is built around a solution? Because while the second has its issues I would take it over the alternatives any day.
lowercased 4y ago
> PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Years ago, was in a situation where I was working with a PO/PM set of folks (rotated around a bit, but a small team). Multiple times I would suggest X, and get "No, that's confusing, we won't need it, that will confuse users, we will never need that, etc". Then... they're gone, and the new replacements are asking "why don't we have X?" Similarly, "hey, I need to do XYZ on feature ABC". Reply along the lines of "hey, don't worry - we just need the minimum thing up now - we'll revisit later. I will take responsibility if there's any fallout from this decision." That phrase was used multiple times over the 12-18 months. Guess who's not here any more to answer any of the 'cut these corners' decisions? Yep - that product person who said "I'll take responsibility". Who isn't around any longer. Many things that were assumed to be 'done' because they'd been discussed earlier were later discovered to be severely cut down or missing altogether. What's strange to me is I've seen this pattern play out probably 3 or 4 times over the past... 20 years or so. I learned it certainly wasn't a one-off unique-to-personX thing.
- dgroshev 4y ago
  Do you know what corners can't be cut in advance though? Sure, you can have a tiny post-seed team bogged down for a month rolling out Hashicorp Vault for everything because "that's how it should be done", or play forever with microservices, or roll out Bazel in a two person team writing Python, don't ship enough, and get out of business. Alternatively, they can be passing an .env file with secrets around, build a monolith, and deploy it with bash/make. It might be tedious or even dangerous at some scale, but which way would leave more time to create real-world value, hopefully somewhat captured and used to pay salaries? The question of responsibility is a funny one. For every PM jumping ship and leaving developers with tech debt, there are tens of developers bogging businesses down with unnecessary complexity [1] and jumping ship with newly padded CVs. Do you think it's any better? In fact, what do you think is worse for the world? [1] Too much complexity can kill a business much faster than failing to scale. Loads of unicorns were unstable and failing under load (failwhale!), but that's a problem that comes with customers, which means money, which means it's much easier to resolve than having no money and a beautiful scalable stack.
citrin_ru 4y ago
> PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Developers feel the pain instead. Developers (and people in general) are bad at prediction the future. I've seen many times that a developer are solving a problems in more generic and extensible form than required, creating a complex solution in hope that future changes will be easy. But then future comes not as it was expected and refactoring is required anyway. 80/20 for me includes not solving problems you don't have but think you may have in the future. If you need to solve X and X looks like a special case if Y class it doesn't necessary mean solving more generic but bigger and harder problem Y is a good idea.
- Aeolun 4y ago
  > Developers (and people in general) are bad at prediction the future. Right now I can safely say that 80% of the times I foresee changes they actually happen. I won’t stop pre-empting stuff for the 20% I get wrong.
  - lowercased 4y ago
    Similar here. That's not always the case, but usually after some period - 6 months min - I have as strong an understanding of the business needs as someone can have (with the exception of information which is explicitly hidden or withheld). From then on, my notion of what's needed now and in the future is generally pretty strong (and, to be honest, for many types of businesses, there's a lot of relatively generic plumbing and data needs that are evergreen). I've been in software engineering for closing in on 30 years (first got paid for a small piece of freelance code in 1994!). I've been doing this longer than some of my colleagues have been adults, much less been in their positions in company X. Many items and needs are not that hard to foresee/predict. Worked short term on a financial tool - dealing with mortgages, assets, etc. Field for recording "interest rate" would not accept negative rate. I raised it as a concern. "What do you mean? You can't have negative interest rates - that doesn't make any sense!" This was in 2018, where many European banks were starting to come to terms with negative interest rates. The company itself had funding from a large investor, and one of the stated goals was that the product was planning to be rolled out in Europe by 2020 (covid happened and I'm sure scuttled much of that). Understanding that interest rates can, in fact, be negative, doesn't require some fancy economics degree. You could just go to yahoo finance and read news headlines that it was happening. And... we had to create entity records representing a bank - name, address, contact info, etc. Nothing crazy, but "we need to handle multiple currencies". Someone added "currency" as the field for the bank - a one-to-one only. I raised the issue that large international banks can and do deal with multiple currencies. I got some blank stares, and a "banks don't do that" from some project lead. 2 months later, demoing for one of the VPs... a VP said "these bank records should be able to have more than one currency associated". "Yes sir, we'll get right on it!". Ugh... But hey, I'm just a developer, right? It's better to go back and tear up months of work and tests, and push back release dates, than to just listen to a concern from someone with some experience. "For v1, we only support single currencies. Multi currency records are on the roadmap for v2 in Q3" or "We prevent negative interest rates on purpose and will notify the user that negative rates will require a call to support team" or similar responses - both would have been mildly annoying, but I felt like I was being gaslit by folks in the company, intimating that normal/basic stuff was just random stuff I was making up.

lukasb 4y ago

I'm sorry that you've apparently only worked with bad PMs.

zero_shift 4y ago
Unfortunately, you don't have to work with bad PMs very often, to occasionally experience a year or more of misery due to their ineptitude. Good PMs are a bit of a paradox. They are immensely impactful and bring value to every project they touch. Yet they are also far overqualified for what is often a thankless job. I also have come to the view that even good PMs will rarely allocate the work that is truly impactful. Some of the best work of my career has been when I've gone off piste and prototyped something that has surprised my managers or disrupted the way a team thought they had to work. You can't go rogue often, and you have to expend your political capital carefully. But you will never do the best work of your career waiting for someone to assign you it in JIRA.
- ryanmcbride 4y ago
  Best PMs I've had were former engineers. They aren't ALL great but at least when we'd tell them that to build a feature we have to lay new groundwork instead of blasting out a hack, they generally understand why that's a good idea.
- idsout 4y ago
  What are the downsides to "going rogue" too often? Where do politics come into play here?
  - gtirloni 4y ago
    PMs promised the business X would get done because it was great. Now they have to explain developer Y didn't deliver that. Disappointment ensues and PM has to sell rogue work as also great (so why wasn't it planned instead of the other less great thing). As someone already said, it's a thankless job and I empathize. Signed: frequently rogue developer.
  - lostdog 4y ago
    If your "going rogue" project fails, then you can be seen as not having done any work for X weeks. If your manager was against you working on that project--especially if they needed you to work on something else--then you will be seen poorly, and that can be rough for your career.
- unphased 4y ago
  I think it could actually be a pretty good strategy to optimize your job search for the degree to which you might be able to go rogue and get away with it.
  - llamataboot 4y ago
    I am pretty up front about being chaotic good and seeing that historically I add a ton of value when I am given some free rein to fix things or just make some (or a bunch of people's) lives easier, I often seek forgiveness rather than permission but - I am also willing to accept push back (always a hey, this fixes this and that, what do people think? not a "I made the terrible code perfect and you must accept this), I try to be clear about where my time is going is my own assigned work is going slower, not usually because I'm off over-engineering some internal tool. but because when you get a reputation as someone that can help people fix things, lots of your time is about unblocking others cause they trust that they can come to you (which levels the whole team up, but sometimes means individual commitments fall behind), and I am try to push for the whole team to have less fear and more freedom to have a day a month where they just work on whatever tech debt they want, or throw up a quick PR for discussion about something they see, etc etc. And I'm also clear that if the org doesn't see value in what I'm doing, that's their call to make, because I also know I can find one that will. But in my experience the devs that want to /optimize/ for going rogue, are the ones you least want re-engineering your entire auth system overnight with code no one else understands and/or the most abrasive when it comes to arguing about why they are right. It's a gentle balance and being honest, kind, and collaborative goes pretty far....

eldavido 4y ago

> _That_ is why developers are cautious. Do you _seriously_ think that you are the only person in your team who understands "commercials" or "cost benefit analyses"? I realized this attitude is common to all tradespeople, not just developers, but also HVAC techs, roofers, electricians, pretty much anyone who's long-term accountable for supporting a large, complex system. More of an observation than anything.

timr 4y ago

Hi. Former engineer turned PM here. Wow, you're spinning some wild stereotypes here, and while some are based in truth (as are all good stereotypes), I'm going to take issue with this: > PMs won't be honest with the business that they sold an undercooked product. Need to suddenly scale up that "pragmatically" designed database? I know in my heart that many PMs will _never_ manage expectations with their superiors if they can harangue developers into overtime, out-of-hours alerts or death marches. While I've certainly seen incompetent, bureaucratic and/or poorly incentivized PMs, I don't think I've ever met one who wants to throw their developers under the bus to get a job done. I'm not saying it doesn't exist anywhere, ever (big world out there), but you've made a couple faulty assumptions: 1) A PM is not "a middle manager". It's generally a non-management position, despite the title. The classical "PM" has to use soft force for everything, and only gains authority through a history of doing the job well. We're constantly managing expectations in every direction, and "up" is just one more. 2) Even if we were "middle managers", those amongst us who have been working for a while realize it's bad practice to leave a trail of burned-out colleagues behind us, due to a history of bad decision-making. I'll add a third, specific to my own history: 3) one reason PMs might not "care" about scaling up that database, is that it almost never needs to be scaled. Seriously. The engineer side of my brain wants to optimize everything. The PM side is always having to remind that side that most of my engineering life was spent in a cycle of useless premature optimization. The war continues. Anyway, it might be good to talk to your PMs and not assume they're evil villains. And if I'm wrong and you're working in a truly Machiavellian hellhole...you should look around. I hear it's a pretty good job market.

bb88 4y ago
> Anyway, it might be good to talk to your PMs and not assume they're evil villains. I've always thought PM's to be more or less aliens with a ray gun tapping at their watch. Communicating with them goes nowhere since they don't empathize with your point of view. The only thing they're concerned with is when something's going to get done. The only form of motivation is threat of existence in the company. > While I've certainly seen incompetent, bureaucratic and/or poorly incentivized PMs, I don't think I've ever met one who wants to throw their developers under the bus to get a job done. Perhaps, it's also possible you've never worked at enough shops to see it. > one reason PMs might not "care" about scaling up that database, is that it almost never needs to be scaled. Seriously. You're not the one going to be called at 4am when postgres takes a dump. If you volunteer to cycle into the on-call hours, I'd feel more compassionate for your point of view. Until PM's do this, I decline to see it that way. I guess I feel like the PM is worthless position unless the PM is writing code along side the team, and can fully appreciate the technical problems -- and more importantly -- offer technical solutions.

lumost 4y ago

Honestly, this tends to be team dependent. In any organization, there is often some "group" who is pushing to ship. Likewise, there is often a group that feels "stuck" with any fallout from a delivery - and none of the success. This could be Product vs. Engineering, Engineering vs. Support etc. Where this border breaks down varies from org to org. No one likes having the short end of a stick. Usually if the teams have more mixed ownership boundaries and feel "the win" of a launch, then this becomes less of an issue.

thaneross 4y ago

It's almost like there might be better alternatives than command-and-control structures when building software.

collyw 4y ago
We are doing a democratic design by committee. I am fairly sure that will work out worse in most cases.
- thaneross 4y ago
  Is it democratic in that people vote for a solution? Or is it everyone talks about it and consensus is built around a solution? Because while the second has its issues I would take it over the alternatives any day.

lowercased 4y ago

> PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Years ago, was in a situation where I was working with a PO/PM set of folks (rotated around a bit, but a small team). Multiple times I would suggest X, and get "No, that's confusing, we won't need it, that will confuse users, we will never need that, etc". Then... they're gone, and the new replacements are asking "why don't we have X?" Similarly, "hey, I need to do XYZ on feature ABC". Reply along the lines of "hey, don't worry - we just need the minimum thing up now - we'll revisit later. I will take responsibility if there's any fallout from this decision." That phrase was used multiple times over the 12-18 months. Guess who's not here any more to answer any of the 'cut these corners' decisions? Yep - that product person who said "I'll take responsibility". Who isn't around any longer. Many things that were assumed to be 'done' because they'd been discussed earlier were later discovered to be severely cut down or missing altogether. What's strange to me is I've seen this pattern play out probably 3 or 4 times over the past... 20 years or so. I learned it certainly wasn't a one-off unique-to-personX thing.

dgroshev 4y ago
Do you know what corners can't be cut in advance though? Sure, you can have a tiny post-seed team bogged down for a month rolling out Hashicorp Vault for everything because "that's how it should be done", or play forever with microservices, or roll out Bazel in a two person team writing Python, don't ship enough, and get out of business. Alternatively, they can be passing an .env file with secrets around, build a monolith, and deploy it with bash/make. It might be tedious or even dangerous at some scale, but which way would leave more time to create real-world value, hopefully somewhat captured and used to pay salaries? The question of responsibility is a funny one. For every PM jumping ship and leaving developers with tech debt, there are tens of developers bogging businesses down with unnecessary complexity [1] and jumping ship with newly padded CVs. Do you think it's any better? In fact, what do you think is worse for the world? [1] Too much complexity can kill a business much faster than failing to scale. Loads of unicorns were unstable and failing under load (failwhale!), but that's a problem that comes with customers, which means money, which means it's much easier to resolve than having no money and a beautiful scalable stack.

citrin_ru 4y ago

> PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Developers feel the pain instead. Developers (and people in general) are bad at prediction the future. I've seen many times that a developer are solving a problems in more generic and extensible form than required, creating a complex solution in hope that future changes will be easy. But then future comes not as it was expected and refactoring is required anyway. 80/20 for me includes not solving problems you don't have but think you may have in the future. If you need to solve X and X looks like a special case if Y class it doesn't necessary mean solving more generic but bigger and harder problem Y is a good idea.

Aeolun 4y ago
> Developers (and people in general) are bad at prediction the future. Right now I can safely say that 80% of the times I foresee changes they actually happen. I won’t stop pre-empting stuff for the 20% I get wrong.
- lowercased 4y ago
  Similar here. That's not always the case, but usually after some period - 6 months min - I have as strong an understanding of the business needs as someone can have (with the exception of information which is explicitly hidden or withheld). From then on, my notion of what's needed now and in the future is generally pretty strong (and, to be honest, for many types of businesses, there's a lot of relatively generic plumbing and data needs that are evergreen). I've been in software engineering for closing in on 30 years (first got paid for a small piece of freelance code in 1994!). I've been doing this longer than some of my colleagues have been adults, much less been in their positions in company X. Many items and needs are not that hard to foresee/predict. Worked short term on a financial tool - dealing with mortgages, assets, etc. Field for recording "interest rate" would not accept negative rate. I raised it as a concern. "What do you mean? You can't have negative interest rates - that doesn't make any sense!" This was in 2018, where many European banks were starting to come to terms with negative interest rates. The company itself had funding from a large investor, and one of the stated goals was that the product was planning to be rolled out in Europe by 2020 (covid happened and I'm sure scuttled much of that). Understanding that interest rates can, in fact, be negative, doesn't require some fancy economics degree. You could just go to yahoo finance and read news headlines that it was happening. And... we had to create entity records representing a bank - name, address, contact info, etc. Nothing crazy, but "we need to handle multiple currencies". Someone added "currency" as the field for the bank - a one-to-one only. I raised the issue that large international banks can and do deal with multiple currencies. I got some blank stares, and a "banks don't do that" from some project lead. 2 months later, demoing for one of the VPs... a VP said "these bank records should be able to have more than one currency associated". "Yes sir, we'll get right on it!". Ugh... But hey, I'm just a developer, right? It's better to go back and tear up months of work and tests, and push back release dates, than to just listen to a concern from someone with some experience. "For v1, we only support single currencies. Multi currency records are on the roadmap for v2 in Q3" or "We prevent negative interest rates on purpose and will notify the user that negative rates will require a call to support team" or similar responses - both would have been mildly annoying, but I felt like I was being gaslit by folks in the company, intimating that normal/basic stuff was just random stuff I was making up.