The ever-prescient Seth Godin had a blog today about orienting towards “saying yes” that’s worth a read. This resonated strongly with me as I had something of the same epiphany years ago.

Back when I was first in a technical leadership role, I used to feel bombarded by crazy requests from product management, sales, field, etc. For years I felt like it was my job to protect my code by saying no to these crazy requests that always came at the worst possible time. I often felt like I was butting heads with these folks and that didn’t make them happy or me happy.

For some reason, probably due to the early winds of agile processes, I had a shift in perception one day that my job was not to say no these requests. Rather, my job was to say yes to as many of these requests as I could, but to do that in a way that maintained the integrity of the schedule and the product. That simple change in perception from “no by default” to “yes by default” radically altered how I approached all interactions. I still think about this idea at least once a week and it’s been years since I had this thought.

If a product manager or someone else asks you for a feature, instead of saying no, say yes, but then you must figure out how to make that work. To me, this is actually an essential part of being a technical leader.

“Making it work” can mean lots of different things. Maybe you have “Red Wombats” now but someone asks you to add “Blue Wombats” to your product. Obviously, that’s a must-have, but you know there is no time in the schedule to fit it in. You could say “No, I can’t implement Blue Wombats.” and get back to work.

But you should say “Blue Wombats seems really valuable. But I’m already doing Flim Flam and Donkey Flute in this release. I can’t do all of them in the time available. How can we get it in?” There are many options available: a) drop Donkey Flute, b) delay till next release, c) remove sub-features of Flim Flam and Donkey Flute to make room, d) hire another guy with Blue Wombat expertise, e) push the release dates, etc. But if you just say no you can’t have that discussion.

Another case might be when someone asks you for a feature that is inconsistent with your view of the product. “Hey Alex, this thing would really be the bees knees if we made all windows round and translucent!” You could say “Dude, you have your head up your ass if you think I’m implementing round translucent windows.” and get back to work. [Frankly, this is occasionally the right answer.] But more often than not, there is some actual and compelling reason why that person is asking for round translucent windows in the first place. For example, you just signed a new customer with the $5M deal has a standards committee that mandates round translucent windows.

In these cases, your first question should be “why?”. Ask the other person to step back and tell you their goal or use case or example or what prompted them to wander over to your office in the first place. Usually you’ll find that when you known the context of the request, new possibilities open up. I’d say 37% of the time (ok I made up that number) the product already has a feature that can accomplish the request! In that case you can say yes immediately: “Actually, in the user preferences you can download the round translucent windows skin and turn it on.”

Sometimes the other person will simply have an idea that you find incompatible with your view of the product. I find it’s usually helpful to reflect at that point on why you find it incompatible. Sometimes the act of voicing the reason will make it clear that you’re an idiot. Or that the other person is an idiot. Or maybe you just simply disagree. In that case, you might want to kick it up a notch and bring in other key decision makers. Remember, the goal of all of this is to say yes to the other person and try to make it work, not just for him but for you and your team as well. If you work with good people, this stuff happens all the time and will be resolved quickly and efficiently in a consensus. Sometimes you won’t totally agree, but that’s ok.

Over the years I’ve become hyper-sensitive to people that default to no. They’re no fun to work with. Sometimes I get in a funk myself and start saying no first. But usually within a day or two I feel like a jerk and realize what I’m doing. If you propose an idea to someone and the first thing they always say is “Let me play devil’s advocate here…what you’re saying is impossible because a, b, c” then they are saying no first. Saying no kills energy; saying yes amplifies it.

By the way, the next version of the Terracotta console will feature all translucent round windows and Blue Wombats. ;)