←back to thread

388 points replyifuagree | 1 comments | | HN request time: 0.213s | source
Show context
theptip ◴[] No.37969219[source]
I dislike the framing here, it disempowers the team and sets up a hostile lens towards stakeholders.

As the product team, you are in general optimizing between quality, scope, and timeline. Pick values for two, the other one will be determined. So if a stakeholder communicates a timeline constraint, you can work with them to achieve it by cutting quality or scope. For example if the urgency is that they need to give a customer demo, maybe a moving skeleton prototype, or at least delivering an iteration without all the integration tests would be appropriate (quality). Or maybe you can chop the deliverable into two milestones and ship the features they urgently need sooner (scope).

I acknowledge that in some cases there is just an asshole who doesn’t know what they are talking about, trying to inject urgency. But in many cases, if you actually empathize with the stakeholder and try to figure out what they are really communicating, you can find the underlying issue and modify your deliverables accordingly. This is what it looks like to be a high-performing team.

The idea that the timeline is out of your control is asinine, and will make stakeholders distrustful, since the idea is obviously nonsense (or if it’s true, the team is adrift). I strongly advise you to never use this language or philosophy in your stakeholder interactions.

replies(1): >>37970529 #
1. pfsalter ◴[] No.37970529[source]
Completely agree, the article reads more like someone who thinks they are doing research rather than development. There's no esoteric perfect form for software that needs to be discovered, there's a set of patterns and structures that can be learned before the project starts.

Analogies are often unhelpful because people argue about the analogies instead of the actual problem at hand. If you can't communicate why these things are hard, and why 'do it faster' won't always get results, you need to get better at dev management.