As the person who keeps telling tech leaders to stop being so negative and shoot down everything (the infamous “CT-No”), I feel obliged to address the other extreme. The VP of Engineering who tries to accept everything eventually reaches the same dead end from the opposite direction. Learning how to push back effectively is a big part of escaping constant-firefighting mode. It’s a bit more complicated than “just say no,” but not by much.

Why You’re Getting Overloaded

Just as with the CT-No situation, when you always provide the same answer—be it a positive or a negative one—no one really needs to ask, right? The reason we need leaders is judgment. If your answer is always yes or always no, you’ve removed judgment from the job. When you see the team is constantly bombarded with requests, at least part of the blame lies with you.

Tech leaders in these situations often describe feeling continuously overwhelmed by requests. The CEO or whoever else keeps asking for more and more, no matter how much they’ve already agreed to take on. When viewed simplistically, CTOs often take this behavior to mean they’re not seen, unappreciated, or taken for granted. From there, the road to burnout is very short.

But we have to consider others’ points of view. In many chaotic startup environments, it’s only the squeaky wheels that get noticed. If you never set boundaries, people aren’t likely to stop asking for more spontaneously. In an industry where many are struggling, if your organization is having a hard time but hasn’t reached the breaking point yet, the challenge is usually not visible from the outside.

Would you stop asking for more of a good thing if you’re never presented with the price or consequences?

Effectively Drawing the Line

The solution is not to become more negative. It is to make the cost of every “yes” visible. It might be easier in some contexts and less so in others. For example, often people I work with find it easier to start by setting better boundaries internally in their organization before pushing back on external requests. Regardless of where you start, there are a few key things to keep in mind.

First of all, don’t explode out of nowhere. I mean, surely from where you’re sitting, it isn’t “out of nowhere,” but it’s probably going to look like that to the others. After all, you’ve allowed the situation to be like this for a while. Helping the organization change course will naturally require some time.

Don’t be afraid to tell the truth. Leaders who are worried about stating a clear goal cannot expect to make much progress. If you cannot say the amount of work requested for the next iteration is surely too much, you’re setting your team up to fail. Sometimes there’s a fear of being seen as whining or a “downer.” But if you focus on observations and less on complaining, you should come across better.

I’ll say that there are those people who will actually frown upon tech leaders who are just trying to set proper and sane boundaries. If that’s the case, trying to “suck it up” will only delay the issue. Either you’ll speak up and be treated as a genuine leader, or you’re wasting your time.

Don’t abuse your powers. The easy path when you feel overwhelmed is to set boundaries harshly, leveraging your position as the tech leader. If the CTO says something is plainly impossible or will require six months at a minimum, it might achieve the short-term goal of reducing the load. However, if that claim was an exaggeration just because it’s possible to do so, trust will be lost.

State clearly your observations and assumptions. Explain your certainty about the situation. Boundaries are a lot easier to get across when the other party understands the gravity of the situation.

Establish your principles. It doesn’t matter if you’re not a founder. You should know your boundaries and what sort of leader you’d like to be. Thus, you can decide that you won’t enable behavior like demanding overtime or working weekends solely to eke out some more work that could’ve waited.

Always try to discuss the range of possibilities. Most of the time, we’re not deciding about something truly binary, where the answer is a clear-cut yes/no. When you’re asked to do something, try to come up with several approaches of varying costs, time, value, etc. That reduces the chances of being seen as a gatekeeper who always says no. It is also the healthy move in general to ensure we maximize impact per engineer: don’t just accept requests without ensuring you understand them and agree about the best way to approach the goal.

Boundaries are not something you announce once and then admire from a distance. They are operational hygiene. Every week, every roadmap discussion, every “quick ask,” every executive escalation either reinforces them or erodes them.

If you never show the price of yes, don’t be surprised when the company keeps buying.