A few months ago, a product manager walked up to my desk with a pitch. "We should build a real-time notification system. Push notifications, in-app badges, email digests, the whole thing. Users are asking for it."
I asked how many users. Three. Three users had mentioned notifications in feedback surveys. Out of roughly twelve thousand active users. The PM had already drafted a spec. It was fourteen pages long.
I said no.
Not "let's think about it." Not "maybe next quarter." Just no. And that no was probably the most valuable thing I did that month.
The Hardest Skill Nobody Teaches You
When I was a junior engineer, I measured my value by what I built. More features, more PRs, more commits. If someone asked "can we build this?" my answer was always some version of yes. Yes, and here's how. Yes, and I can have it done by Friday. Yes, and I already started prototyping it during lunch.
I was rewarded for this. Managers loved it. PMs loved it. I got promoted. I was the guy who gets things done.
But "getting things done" and "doing the right things" are not the same skill. I was optimizing for output when I should have been optimizing for outcome. Years and several painful projects later, I figured that out.
I once spent six weeks building a feature that let users export reports in four different formats: PDF, CSV, Excel, and a custom XML format that one enterprise client had requested. The PDF and CSV exports got used regularly. Excel got used occasionally. The XML export was used exactly once, by the client who requested it, during their initial evaluation. They ended up not renewing their contract anyway.
Six weeks. I could have shipped the PDF and CSV exports in two weeks and moved on to something that mattered. But nobody said no to the XML format. Nobody asked whether one potential client's request justified six weeks of engineering time. We just built it because someone asked.
What "No" Actually Looks Like
Saying no doesn't mean being difficult or obstructionist. It means asking the questions that nobody else is asking.
"What problem does this solve?" This sounds obvious, but you'd be surprised how often features get proposed without a clear problem statement. "Users want notifications" is not a problem statement. "Users are missing time-sensitive updates because they only check the app once a day, and by then the relevant window has passed" is a problem statement. The first one leads to building a notification system. The second one might lead to a notification system, or it might lead to a daily email summary, or it might lead to changing when the time-sensitive events are created.
"How many users does this affect?" Not how many users could theoretically benefit. How many users are actually experiencing this problem today. There's a massive difference between "all 12,000 users could use notifications" and "3 users mentioned notifications." The first is a feature. The second is a support ticket.
"What's the cost of not doing this?" If we don't build this feature, what happens? Users churn? Revenue drops? Nothing changes? If the answer is "nothing changes," then building it is pure cost with no return. That doesn't mean it's never worth doing, but it means it should lose priority to things where the cost of inaction is real.
"What won't we build if we build this?" This is the question that kills me when teams skip it. Engineering time is finite. Every feature you say yes to is implicitly saying no to something else. When we said yes to that XML export, we were saying no to six weeks of work on something else. Nobody framed it that way at the time. We just said yes and figured we'd get to everything eventually. We didn't.
The Features I'm Glad We Didn't Build
I keep a mental list of features I've talked teams out of building. Not because I want credit, but because it reminds me that saying no has compounding value.
There was the social feed feature. A startup I worked at wanted to add a social feed to what was a B2B project management tool. The logic was that if users could post updates and comment on each other's work, engagement would increase. Maybe. But we had eight engineers, a backlog of actual bugs, and zero experience building social features. I pushed back hard. The team wasn't happy about it. Six months later, a competitor launched a social feed in their project management tool. It flopped. Users didn't want social media inside their work tool. They wanted their work tool to work.
There was the custom analytics dashboard. A VP wanted us to build an internal analytics dashboard instead of using a third-party tool. "We'll own the data," he said. "We can customize it exactly how we want." I've heard this pitch before. We already owned the data. It was in our database. The third-party tool just visualized it. Building a custom dashboard would have taken two engineers three months. We were paying $200 a month for the third-party tool. The math wasn't even close.
There was the mobile app. A different startup wanted to build a native mobile app for a product whose users were almost exclusively on desktop during work hours. Usage data showed 94% desktop, 6% mobile, and the mobile usage was almost entirely people checking one specific page during their commute. We built a responsive version of that one page instead of a native app. Took a week instead of three months.
Why Saying No Is Politically Dangerous
Here's the part nobody talks about in blog posts about senior engineering. Saying no has a cost. A real, career-affecting cost.
When you say yes to everything, people like you. You're collaborative. You're a team player. You're the engineer who makes things happen. Your performance review says things like "always willing to take on new challenges" and "great partner to the product team."
When you say no, you're "difficult." You're "not aligned with the business." You're "blocking progress." I've been called all of these things. Sometimes by people I respect. Sometimes in performance reviews.
How you say no is the trick. "No, that's a bad idea" gets you labeled as negative. "I think there's a simpler way to solve this problem" gets you labeled as thoughtful. Often the same thing, but the framing matters enormously.
I've learned to never say no without an alternative. "I don't think we should build a notification system, but I think a weekly email digest would solve the same problem in a tenth of the time." Now you're not blocking. You're redirecting. The PM gets something they can ship. Two months of infrastructure work disappears. Users get their updates.
Sometimes the alternative is "let's wait and see." That sounds like a cop-out, but it's often the right call. "Let's not build this now, but let's track how many users request it over the next quarter. If it's a trend, we'll prioritize it." Half the time, nobody asks about it again. The other half, you have actual data to make a decision with.
The Things Worth Saying Yes To
If I'm spending so much time saying no, what am I saying yes to?
Things that reduce future work. A migration that simplifies the data model. A refactor that makes the next three features faster to build. Paying down tech debt that's causing bugs. These aren't exciting, and they're hard to put on a roadmap slide, but they compound. Every hour you spend simplifying your system saves multiple hours down the line.
Things that users are actively struggling with. Not hypothetical users. Not potential users. The users you have right now, who are hitting real friction in your product. When support tickets cluster around the same issue, that's a signal. When users build workarounds for missing functionality, that's a signal. When your biggest client schedules a call to talk about pain points, that's a very loud signal.
Things that are reversible. If we build this and it's wrong, can we change it? If yes, the cost of saying yes is low. Ship it, learn from it, iterate. If we build this and it's wrong, are we stuck with it for years? If yes, slow down. Think harder. Talk to more people. Get it right, or don't do it.
Things that are small. I'd rather say yes to ten small bets than one big one. Small features ship fast, give you feedback fast, and fail cheaply. Big features take months, delay feedback, and fail expensively. When a PM pitches me a three-month project, my first instinct is to find the version of it that ships in two weeks.
The Uncomfortable Truth
The best code I ever wrote is code I didn't write. My most impactful project is one I killed before it started. My most valuable meeting was a 30-minute conversation where I convinced a team that the feature they'd been planning for two months wasn't worth building.
That's a weird thing to say as an engineer. We're builders. We want to build things. The dopamine hit of shipping a feature is real. The satisfaction of solving a hard technical problem is real. Saying no doesn't give you any of that. It just gives you time, and time is the only resource you can't get back.
Junior engineers create value by building. Senior engineers create value by deciding what's worth building. Each is necessary. But if your senior engineers are spending all their time building and none of their time questioning whether the thing should be built at all, you have a team of senior-titled juniors.
That sounds harsh. I don't mean it as an insult. I was that person for years. I built everything anyone asked me to, and I was proud of my output. I just wasn't proud of the outcomes. Features that didn't get used. Projects that got abandoned. Months of work that turned into lines of code nobody looked at again.
Learning to say no was the hardest skill I ever developed. Harder than distributed systems. Harder than performance optimization. Harder than debugging production incidents at 3 AM. Because it's not a technical skill. It's a judgment skill. And judgment only comes from experience, which usually means getting it wrong a bunch of times first.
So say no more often. Not to everything. Not reflexively. But when someone proposes a feature and your gut tells you it's not worth it, don't ignore that feeling. Ask the questions. Do the math. And if the answer is "we shouldn't build this," have the courage to say it out loud. Your team will thank you later. Probably not right away. But later.
Comments (0)