Software Engineering: Saying “No” Is Part of the Job

Not writing code can be just as important as writing code.

Chris Vibert
The Startup
2 min readJul 10, 2020

--

“We can deliver this feature for the client by Friday, right?”

This might sound like a reasonable question for a Product Manager to ask, but for the Software Engineers on the receiving end, there’s a lot more to it:

  1. The client has already been told they will have it by Friday.
  2. There will be no time to plan the feature properly, meaning low quality and lots of bugs.
  3. No sleep until Saturday.

And yet the team of Engineers remain silent, leaving the Product Manager increasingly pleased with their team of Engineers who will once again achieve the seemingly impossible.

Photo by Roger Bradshaw on Unsplash

And impossible it may be — or at least impossible to deliver the feature with any sort of quality, and without disrupting all other work.

Saying “no” in this kind of scenario does not mean giving up on the feature, or letting your team down, or worst of all — not being ‘agile’. In fact, the exact opposite can be true as long as you also make sure that the conversation does not end there.

Follow up a “no” by explaining why, and then and encourage the entire team to work together to find the best alternative solution:

  1. What changes must happen in order to meet the deadline? Shift resources, priorities, and other timelines? And are these changes worth it?
  2. Is there a quicker way to deliver only part of the feature, still giving value to the client, but without disrupting everything else?

And the discussion shouldn’t stop there either, especially if these “no” scenarios become common. This gives the team an opportunity to learn and improve, by addressing some broader questions:

  1. Is there anything other than a lack of time that is making these deadlines difficult to achieve? Does it highlight a lack of knowledge, skills or resources within the team?
  2. Why are these features and deadlines reaching the Engineers at such short notice in the first place? Could everyone have known earlier giving time to plan it properly?
  3. Is there anything that should be done differently next time?

Saying “no” at the right time is part of your job as a Software Engineer. By doing so, you are taking pride in the products you build, you are managing expectations, and you are helping your team to continuously improve. All of this whilst also protecting yours and your teammates sleep.

--

--