Saying No.

Just a decorative image for the page.


Ever had the challenge of a CEO coming to one of you teams and requesting them to implement a super-urgent feature?

I guess everyone leading tech teams or departments was already in that spot. But saying yes to every urgent request is simply not possible. It’s about priorities. And sometimes you have to say no. However, saying “no” is challenging, and often, an outright “no” is not accepted.

How do you deal with this situation as CTO / Interim or team lead?

A Better Way

I’ve learned early on that agreeing to everything eventually paves the way to disaster. I highly recommend reading “Getting Real” written by Jason Fried, DHH and Linderman.

Yet, their approach appears to be too confrontational. Essentially, they advocate for directly saying no, expecting the other person to naturally understand.

This strategy works sometimes, but often a simple “no” fails.

I found another way of saying no - which worked much better for me in the past.

For instance, if a manager interrupts a project - requesting additional features, I usually respond with “yes, we can do that,” but I add, “an this will, however, shift the projected release date by two months into the future.”

You essentially return the ball into their court and let the requester decide whether the “urgent” feature is worth the trade-off.

In most instances, the requesters comprehend the drawback and back down from their initial ideas or requests.

Mission accomplished.

When It Doesn’t Work

Sometimes even this approach proves ineffective. I have experienced such instances multiple times in my career when I absolutely had to implement a feature as Interim CTO at the CEO’s behest.

Even when underscoring the trade-off, it is sometimes not accepted, and you feel the pressure to implement more simultaneously with your teams.

Well, when this occurs frequently, it might be time to leave. It clearly signals a flawed organizational structure. On the other hand it’s always important to question yourself - maybe the request is really important and maybe there are ways to implement it. A brainless “no” is never the answer.

Yet, if you find yourself cornered in such circumstances, you might can delegate the entire project to the person who purports to “know it all better”. With this approach, you do admit defeat, but it’s only until it becomes clear that you were right from the onset. And hopefully, your judgement was correct.


Saying “no” is essential but often not accepted. A better strategy is to say “yes” but clearly outline the associated drawbacks, like delaying the timeline.

You should leave the decision of whether to accept the downside to the person making the request. Don’t make the decision yourself.

Doing so relinquishes the problem from your hands. And in most situations, this approach equates to a more diplomatic way of saying “no”.