Hacker News Reader

Comment by rebeccaskinner | Hacker News Reader

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.

View on HN

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.

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

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.

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

The second they hear "We could do that," they tune the rest of everything out.

I've interacted with some bad sales people before, but they rarely tune out when you say things are going to be delayed.

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.

You're assuming they listen to the cost. For many of these terrible bosses, the second they here "We can", they tune the rest of it out.

This. As a PM, this is great for communicating tradeoffs to clients and senior management. As a dev, this is great for communicating tradeoffs to PMs. And conservative estimates of development time (e.g., the dev doubles the time estimate) result in solid, well-designed, thoroughly tested products.

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

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

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

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

You must be an expert[1]

[1] - https://www.youtube.com/watch?v=BKorP55Aqvg

Reply on news.ycombinator.com