4 ms·

I see accusations of this a lot, and honestly I just really wonder what the team structures are like at a lot of companies- or what the experience level is of t

I see accusations of this a lot, and honestly I just really wonder what the team structures are like at a lot of companies- or what the experience level is of the average HN reader. Because you're right, PMs don't have the insight to understand the nuances of technical debt and the benefits and costs associated with varied approaches, and really it's not their job to. As technical folks, it's our job to learn how to say "no", and not just in an abrasive way that shuts down the conversation, but to work with project managers and decision makers, understand the reasons for their decisions, and push back firmly but using language that they can relate to and speaking to their problems. Regardless of how much PMs might want things or fiddle with the schedule, as professionals it's our job- not theirs- to say when things can't be done, shouldn't be attempted, or might cost more than they're worth.

snarfy 9y ago
You must be an expert[1] [1] - https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg
knz 9y ago
> As technical folks, it's our job to learn how to say "no", and not just in an abrasive way that shuts down the conversation, but to work with project managers and decision makers, understand the reasons for their decisions, and push back firmly but using language that they can relate to and speaking to their problems. That gets back to company culture (which others have identified higher up). Not every organisation responds appropriately when developers push back (either due to imposed deadlines or office politics).
- humanrebar 9y ago
  > Not every organisation responds appropriately when developers push back... In my experience, organizations generally do the right thing if all the developers push back. The problem is that you can always find developers that will push a hack or deploy an overwrought solution for a simple problem.
notabee 9y ago
And then after saying no, you can watch the executives hire or promote up someone who says what they want to hear regardless of its feasibility, usually while using the latest buzzwords. Lacking domain knowledge or the interest to acquire it is a good sign that they will lack the awareness to avoid facile answers.
- eanzenberg 9y ago
  Saying "No" or shutting that door down is a bad thing that I don't like either. Rephrase it by using "sure, we could build that, however it will require X person-days with a team of Y senior level engineers."
  - s73v3r_ 9y ago
    Don't do that. All they're going to hear is "Sure, we could do that." They're not going to listen to the rest of it, and then it's going to be your fault when stuff doesn't work.
    - Thrymr 9y ago
      Another way to say it is "We could do that, but it will delay this other thing that is on your roadmap as top priority for X months."
      - s73v3r_ 9y ago
        The second they hear "We could do that," they tune the rest of everything out.
        NegativeK 9y ago
        I've interacted with some bad sales people before, but they rarely tune out when you say things are going to be delayed.
    - eanzenberg 9y ago
      That's the point. Almost anything is possible with the right team. Once it's communicated in terms of cost then the assessment is made whether it's worth it or not.
s73v3r_ 9y ago
And just like there are plenty of crappy software developers, there are plenty of crappy PMs who choose not to listen to developers, and ignore all of that. Recall the article about the toxic culture over at Take Two from yesterday. No matter how much push back happened, they would be met with "Tough. I guess you live here for the next 6 months."
humanrebar 9y ago
> I just really wonder what the team structures are like... Maybe you're lucky or maybe I'm benighted, but it's rare that an organization consciously decides that this is the quarter to finish off the Java 5 migrations, even if that means delaying the Jabberwocky Project and even if there's a non-zero chance of customer impact. Partly because it's a really hard problem to attach an accurate and objective number to the value of something like that. > ...technical debt and the benefits and costs associated with varied approaches... That's not entirely accurate. Engineers are experts at technical benefits of different approaches. And they should be experts on the entire cost of the systems they are responsible for. But they're not necessarily experts on the benefits. They aren't necessarily qualified to anticipate what different features and different release schedules will do to the revenue for the product. In B2C companies with millions of users, you can run statistics and A/B testing to make this stuff more objective, but a lot of companies live and die by big sales to a smaller number of customers. So determining the benefits of shipping a month early depends a lot on knowing particular people well enough to guess how they'll react to good or bad news.

snarfy 9y ago

You must be an expert[1] [1] - https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg

knz 9y ago

> As technical folks, it's our job to learn how to say "no", and not just in an abrasive way that shuts down the conversation, but to work with project managers and decision makers, understand the reasons for their decisions, and push back firmly but using language that they can relate to and speaking to their problems. That gets back to company culture (which others have identified higher up). Not every organisation responds appropriately when developers push back (either due to imposed deadlines or office politics).

humanrebar 9y ago
> Not every organisation responds appropriately when developers push back... In my experience, organizations generally do the right thing if all the developers push back. The problem is that you can always find developers that will push a hack or deploy an overwrought solution for a simple problem.

notabee 9y ago

And then after saying no, you can watch the executives hire or promote up someone who says what they want to hear regardless of its feasibility, usually while using the latest buzzwords. Lacking domain knowledge or the interest to acquire it is a good sign that they will lack the awareness to avoid facile answers.

eanzenberg 9y ago
Saying "No" or shutting that door down is a bad thing that I don't like either. Rephrase it by using "sure, we could build that, however it will require X person-days with a team of Y senior level engineers."
- s73v3r_ 9y ago
  Don't do that. All they're going to hear is "Sure, we could do that." They're not going to listen to the rest of it, and then it's going to be your fault when stuff doesn't work.
  - Thrymr 9y ago
    Another way to say it is "We could do that, but it will delay this other thing that is on your roadmap as top priority for X months."
    - s73v3r_ 9y ago
      The second they hear "We could do that," they tune the rest of everything out.
      - NegativeK 9y ago
        I've interacted with some bad sales people before, but they rarely tune out when you say things are going to be delayed.
  - eanzenberg 9y ago
    That's the point. Almost anything is possible with the right team. Once it's communicated in terms of cost then the assessment is made whether it's worth it or not.

s73v3r_ 9y ago

And just like there are plenty of crappy software developers, there are plenty of crappy PMs who choose not to listen to developers, and ignore all of that. Recall the article about the toxic culture over at Take Two from yesterday. No matter how much push back happened, they would be met with "Tough. I guess you live here for the next 6 months."

humanrebar 9y ago

> I just really wonder what the team structures are like... Maybe you're lucky or maybe I'm benighted, but it's rare that an organization consciously decides that this is the quarter to finish off the Java 5 migrations, even if that means delaying the Jabberwocky Project and even if there's a non-zero chance of customer impact. Partly because it's a really hard problem to attach an accurate and objective number to the value of something like that. > ...technical debt and the benefits and costs associated with varied approaches... That's not entirely accurate. Engineers are experts at technical benefits of different approaches. And they should be experts on the entire cost of the systems they are responsible for. But they're not necessarily experts on the benefits. They aren't necessarily qualified to anticipate what different features and different release schedules will do to the revenue for the product. In B2C companies with millions of users, you can run statistics and A/B testing to make this stuff more objective, but a lot of companies live and die by big sales to a smaller number of customers. So determining the benefits of shipping a month early depends a lot on knowing particular people well enough to guess how they'll react to good or bad news.