4 questions a developer should ask when saying "No"

4 questions a developer should ask when saying "No"

# 1. Are there any other technical solutions to build your capabilities?

- There are many ways to build capabilities, and the first attempt is not always optimal
- Developers want to use the latest technology to build cool capabilities, but this can lead to over-engineering rather than optimizing for simplicity
- Developers with specific skill sets may not be aware of simpler solutions that are beyond their knowledge
- So it's better to encourage engineers to think more creatively about technology solutions
- Some of the best product managers I've worked with had enough technical insight and knowledge of the technology environment to ask insightful questions for engineers to think outside the box

# 2. If you had to come up with a solution with these constraints, what would you do?

- If developers are raising issues with your proposed solution, ask them for their solution
- Developers are treasure troves of creativity and innovation, offering them the opportunity to think creatively by asking if there is a simpler version of the function
- Understanding the core of the problem allows developers to think creatively and find solutions that work within the constraints of the project

# 3. Can we consider a step-by-step approach to this feature?

- When you say it's impossible to implement a feature due to technical complexity, ask if you can divide the project step by step and organize it into different release dates
- There is a temptation to provide a grand vision at once, but the step-by-step approach is more repetitive and delivers concrete results faster
- Priorities can change, and a phased approach allows developers to adjust the next additional features they need to add

# 4. What obstacles can be removed or addressed to make the work possible?

- As a question of resource-based objections, developers actively remove tasks to secure their time when citing limited resources (e.g., time or available developers)
- Possible ways: Easy to create by removing tasks completely, performing tasks that developers don't need, communicating with other teams and/or third parties, owning processes and discarding legacy features

# Conclusion

- "Push" may be inconvenient for developers to say "no," but this will give them more respect
- You need to dig deeper into what the engineer is against and identify why and eliminate the objections one by one
- These are all good questions because they acknowledge the inherent difficulties and constraints that engineers may face when implementing a particular feature
- It's also about making it clear that you're willing to do your part by rolling up your own arms and doing bad things or adjusting to your requirements and schedules to help your team and projects