The Power to Say No

A few months ago I was promoted to Lead Software Developer. I had been taking on the responsibilities of a lead developer over the past year and this new title was confirmation I had been handling the responsibilities well. Since the majority of my new "reports" said they already thought I was the team's lead everything sort of felt the same to us.

What I didn't think about was the view of the outside world looking in on our dev team.

As a staple of my company's engineering department, my boss was generally the one that people went to with questions about our technology. This has lessened over time as my presence increased and his availability decreased, but there was still this feeling that if they didn't like my answer they could go to him; his answer held more permanence. While occasionally it hurt my ego, I didn't really mind having people request the second opinion (especially when it was the same as my own). I liked having that safety net.

With the announcement of my promotion, however, the outside world seemed to have decided that my answers no longer required a second opinion, even if they didn't like what that answer was.

Like Batman in The Dark Knight Rises, the lack of having a safety net caused me to do the unthinkable - I began freely answering their questions, and my answers were increasingly becoming "no."

The ability to say no is actually quite powerful and is something that should be used more often by development teams. We all have this desire to make others happy, we want people to like us. Since my clients are also my coworkers, I want to make them like me even more. This inevitably backfires when I tell everyone I will add every feature, from every request they make. It's okay though, by the time they start asking to see results we will already be best friends! Right?

Saying yes all the time felt nice, but it was a cheap high. I knew I couldn't fulfill everyone's requests and often times knew I shouldn't fulfill requests. Saying no has been freeing. Saying no is like eating your vegetables. At first it's tough, and at first you just do it because you know it's the right thing to do, but eventually the benefits are so prominent that you wonder how you could have ever lived without them.

The best part was, my coworkers have been completely understanding.

I remember reading somewhere that you shouldn't write down feature requests. The idea is that the important ones will be impossible to forget. Changing your default answer to no provides a similar experience. If you say no, and the person doesn't argue their point, it's probably safe to forget about the request. If they do argue their point, then it may be an issue worth pursuing. As a bonus you now also have a better perspective on their request.

My original intention of writing this was to share how I unlocked a superpower when I leveled up to lead developer, the ability to say no. I guess in some sense that is still true. The thing I forgot about leveling up though, is that it requires that you gain experience points first. I wanted to write about it like I simply ate a rare candy and woke up the next day to to find I had gained this new talent. Unfortunately, that wasn't the case.

Finding the guts to say no took time, but I think it's a skill that has been worth the effort. Not only has it increased the chances of my team successfully developing applications, but it has cemented my position as a lead developer in my company.

While you probably cannot realistically just say no to everything, you most definitely can stop saying yes to everything. So, please, wield the power of no. Be open and honest with your coworkers and project stakeholders. Let them know when you think something is a bad idea or cannot be done and remember, "when in doubt, no your way out".

Please share you experience of saying no, how did it work for you? Has it helped or hurt?


Notice something wrong? Please consider proposing an edit or opening an issue.