Hacker News Reader

Comment by skohan | Hacker News Reader

Yes and it can go especially poorly when you have a "problem oriented" person on the team:

1. Manager proposes low quality requirements

2. Problem oriented team member points out a flaw in the requirements which is orthogonal to the actual goal of the feature/team/organization

3. Endless discussion around this one detail

4a. Manager changes the requirements just to end the debate, in a way which sacrifices the core goal and weakens the product/team/organization when there is a simpler solution available to reach the core goal

4b. Manager accepts an extremely complicated solution which maintains the specific requirement which was not required to reach the core goal in the first place, thereby risking the timeline

View on HN

Oof. The number of 4b's I've had to deal with in my career...

What are some techniques to use when you see this happening? I frequently try to get stakeholders to simplify and really identify the core problem / proposed solution, but I run into a lot of "all or nothing" or "design for every possible use case" folks in startups.

A couple approaches I have seen which can be effective are:

- Call attention to the timeline and frame things in terms of specific tradeoffs: "Yes we can do A, but that means we won't have the time/resources to do B"

- Propose an incremental approach. I.e. "There are some technical challenges with achieving A+B+C, so what if we start with A, and then asses the best way to reach B and C."

With the incremental approach, I think this can help avoid the stakeholder feeling like they lost something, and 9 times out of 10 once you give them A they will find out that's all they needed in the first place, and they don't end up asking about B+C again.

little bit of caution on "Yes we can do A, but that means we won't have the time/resources to do B" - this, along with Agile method of squeezing work every two weeks will lead to simply mediocre quality hacked together deliverables and accumulation of technical debt.

Sometimes you need to spend time upfront and do it properly from the beginning, otehrwise the software quickly can become unmaintainable

Sounds like the text book description of how to start wrecking a software project.

4b... Sums up the last 12 months of what should have been a 3 month project.

Reply on news.ycombinator.com