Responding to devs when they say "No": 4 key questions

You spent months crafting your product requirements document and it finally comes time to present it to the engineering team. You walk them through the whole gamut: the problem, the impact, the proposed solution, the user stories, etc.

Then you get to the roadmap and you say: “The deadline for building these features is April 10th.”

The engineers look at you in stunned silence.. and then comes their response: “That’s not possible! We can’t deliver these features in 3 months!”

You proceed to justify the timeline and ask: “Why not? Leadership signed an agreement with the client so we must deliver it by April 10th.”

The response isn’t what you hoped for: “Why weren’t we looped in before the agreement was signed with the client?”

The rest of the meeting is spent focusing on rattling off the technical reasons for why the features can’t feasibly be built in time. What’s even more frustrating is you don’t know how to respond to their objections, let alone know what the right questions to ask are.

So now you’re stuck. You leave the meeting asking yourself why engineering always seems to have objections. Engineers leave the meeting feeling frustrated their perspective isn’t being heard or considered.

Scenarios like these were the norm throughout my dev career working with countless product managers. But if you’re feeling unsure about how to respond when engineers say something can’t be done, know that 9 out of 10 times, that’s not the case. Engineers want the same thing that you do: to ship awesome, high-quality products quickly. If you’re able to bring something valuable to the table in service of that goal, even if that means pushing back and challenging them, engineers are happy to defer.

To do that, try shifting from a defensive position to a proactive position. Focus on what can be done versus what can’t be done by asking these questions.

1. Is there another technical solution for building <X> feature that would be faster to implement?

There are many ways to build a feature and the initial pass might not always be the most optimal one. Engineers love to build cool features using the latest tech but that may lead to over-engineering instead of optimizing for simplicity. It’s also possible for engineers with a particular skillset to not be aware of simpler solutions that utilize technologies outside their knowledge.

For these reasons, it’s a good idea to push engineers to think more creatively about technical solutions. Some of the best product managers I worked with had enough technical acumen and knowledge of the technical landscape to ask insightful questions that helped engineers think outside the box.

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

If engineers take issue with your solution, flip the script and ask them for theirs. Engineers are an incredible wealth of creativity and innovation. By asking whether there’s a simpler version of this feature, you’re giving them the opportunity to flex their creative muscles through exploring more deeply the “why” and the problem that needs to be solved. Once engineers grasp the core problem, they’ll do what they do best: think creatively and come up with solutions that work within the constraints of the project, including the timeline.

And the best part is you now have added buy-in from engineers since they were an integral part of coming up with the idea!

3. Can we consider a phased approach to this feature?

When engineers bring up various technical complexities as the reason for why something can’t be done, ask how the project might be chunked into phases with different release dates. This is essentially asking “how can scope be mitigated so the technical complexities are reduced or eliminated?”

It’s tempting to want to deliver a grand vision all at once, but a phased approach is more iterative and allows for quicker delivery of tangible results. A phased approach emphasizes prioritization based on the core functionality. It’s also common for priorities to change, and a phased approach lets you and the developer adjust the features that need to be added next.

4. What can I unblock or remove for you to allow for <X> work?

This question is great for objections that are resource-based. If engineers use limited resources (i.e. time or available devs) as the reason for why something can’t be done, start proactively removing tasks to free up their time.

What this could look like:

• Eliminating tasks altogether by either de-prioritizing them, or take on work that doesn’t require a dev.
• Make tasks easier by removing roadblocks. Some examples would be taking over communication with other teams and/or third-parties, owning processes and deprecating legacy features.
• Reduce complexity of tasks by reducing scope. Some projects must be worked on. In this case, you should assess what/if any portions of the task(s) can be reduced in scope or timeboxed so allow more room for the work you want engineers to prioritize.
  
  

In Conclusion

It might feel uncomfortable to “push back” on engineers, but know that not only is it OK to push back on engineers when they say something can’t be done, it’ll even earn you more respect! You always want to dig a little deeper to understand what the reasoning is behind their objections and start removing the objections one by one.

That’s why these are all great questions to ask because you’re acknowledging the inherent challenges and constraints that engineers might be facing in implementing a particular feature. You’re also making it clear that you’re willing to do your part to help the team and the project; either by rolling up your sleeves and doing some dirty work yourself, or by being adaptable with your requirements and timeline. 

Distributed

In simple terms, "distributed" in the context of software refers to spreading tasks or processes across multiple computers or servers instead of relying on a single central computer. It's like having a team of workers collaborating on a project, each with their own role, rather than one person doing all the work.

In traditional setups, software might run on a single computer, and if that computer has issues, the entire system could be affected. However, with distributed systems, different parts of the software can run on different machines. It's not just software that is distributed, but databases are also distributed. This setup offers several benefits, such as improved reliability and scalability.

In a nutshell, "distributed" in software means spreading tasks across multiple machines, making systems more resilient and capable of handling larger workloads.

Sign up for the Skiplevel newsletter to get more content like this straight to your inbox.

If you like what you read, make sure to ❤ it, share it, and leave any thoughts in the comments!

Follow and subscribe for more technical tips!

Want to feel more confident in your technical skills?

Become more technical in just 5 weeks, without learning to code! We also train teams! Find out more at skiplevel.co/teams and book a call with me to get started.

Skiplevel is a program that helps product managers and teams become more technical without learning how to code.

Learn more about the Skiplevel program ⟶

Connect with Irene on LinkedIn and Twitter and follow Skiplevel on LinkedIn, Twitter, and Instagram.