When IT Becomes the Team That Always Says “No”
A technology function that reflexively says no gets routed around. What “yes, and” looks like in practice; and why knowing when to say no still matters.
I once met with a prospective client looking to bring in executive IT leadership. When I asked what gap they were trying to fill between their IT Director and the C-suite, they said:
“The IT Director is where we go to hear ‘NO.’”
That stuck with me.
It reminded me of one of the biggest career lessons I learned moving from supporting VC/PE firms, where every Managing Partner could effectively be my “boss”; to an EdTech organization that had to deliver an innovative, flexible AND secure product to hundreds of thousands of students nationwide.
In one environment, saying NO could lead people to find creative ways around the rules, creating shadow IT. In the other, saying NO could block innovation and our ability to deliver the product. Different environments, different consequences, but the leadership question was essentially the same: How do you say YES while still managing risk?
“No, because” trains people to stop asking. Say it enough times and the requests don’t stop, they just stop coming through the technology function. The workaround gets built anyway, the unapproved tool gets adopted anyway, and the team responsible for managing risk finds out after the decision has already been made, if it finds out at all.
A “no” that isn’t heard doesn’t reduce risk. It just moves the risk somewhere you can’t see it.
Why “no, because” fails
The instinct behind “no” is usually legitimate: an unmanaged tool, an unreviewed vendor, a request that bypasses a control that exists for a reason. The problem isn’t necessarily the judgment. It’s that “no” without an alternative asks someone to give up something they need and offers nothing in return.
Most people don’t have the time or interest to fight that decision. They find another way. And now the exact risk you were trying to manage exists, minus your visibility into it.
I’ve watched this pattern up close leading technology, security, and risk functions across distributed, blended teams of staff, contractors, and offshore partners. A slow or reflexively negative technology function in that kind of environment doesn’t get overridden, it gets bypassed.
When I led the decoupling of identity and core infrastructure through an organizational separation, the work held together because technology was already a place people brought problems to, not a place they avoided. That trust doesn’t build itself the week you need it. It’s built through every smaller interaction before that, including whether the answer to “can we try this?” is usually some version of yes.
What “yes, and” looks like in practice
Answer the need, not just the request. Someone asking for a specific unapproved tool usually has a problem they’re trying to solve: their workflow is too slow, a capability is missing, or a deadline doesn’t accommodate the sanctioned process. “No” addresses the request. “Yes, and here’s how we can get you that capability safely” addresses the need—which is the thing that actually needs to go away.
Make the safe path faster than the workaround, not just safer. If evaluating and approving a new tool takes six weeks and going around the process takes an afternoon, the six-week path loses regardless of how sound it is. Speed is a control. An evaluation process that can turn around a low-risk request in days changes actual behavior, not just policy.
Bring options, not a verdict. “That specific tool, no, but this approved one does the same thing.” Or, “Not for that data, but here’s what would make it workable.” That keeps the requester as a partner in the decision instead of someone who lost an argument. People are far more likely to implement decisions they helped shape than decisions simply handed down to them.
Say no when no is actually the answer—and mean it. “Yes, and” doesn’t mean agreeing to everything. Some requests are genuinely unsafe, and the credibility of every “yes” depends on the “no”s being real, specific, and rare enough that people trust them when they come. A technology leader who never says no isn’t practicing partnership. They’re avoiding conflict, and the difference shows up the first time it matters.
Measure the trade you’re making. “Yes, and” also needs to produce outcomes. Fewer shadow deployments. Faster time-to-capability. Better productivity. Stronger trust between technology and the business. Those outcomes are the argument for why this approach is worth the extra work it takes, and they need to be observed and measured rather than assumed.
Knowing when the answer really is no
There are times when the technology function needs to say NO.
A firm under active regulatory examination, a company navigating an acquisition with strict data segregation requirements, or an organization responding to a security incident may need a much harder line for a period of time. In those environments, a technology leader who reflexively reaches for “yes, and” can be optimizing for the wrong thing.
That isn’t an argument against the approach. It’s an argument for calibration.
Even in a locked-down environment, there is a meaningful difference between “No” and “No, because, and here’s what would have to change for my answer to become yes.” One creates a rule people may route around the moment the pressure lifts. The other creates a constraint they understand, including what risk it addresses and what would need to change for the decision to change.
Technology and security functions absolutely need to manage risk. Sometimes that means being the person in the room willing to say no.
But if people stop bringing you problems because they already know your answer, you may have reduced your ability to manage the very risk you were trying to control.
Written by Joy Floresca Knox. This is general information, not legal advice. Regulatory requirements depend on your specific facts and jurisdiction. If something here is wrong or out of date, tell us and we'll correct it.