If your leaders want AI in everything, as if it magically solves every problem, saying no is more than OK. Done well, it may be your team’s most valuable work.

Innovation teams keep talking about the same struggle: senior leaders who want AI in everything, as if AI fixes everything on its own. In that setting, saying no can feel like a career risk. Camilo Gonzalez Barrero, who tracks around 20 emerging technologies for CIBC’s enterprise innovation team, makes the case that saying no is more than OK.

❝

In his view, “an innovation team’s most valuable output is its no”.

Every year, Camilo’s team builds a deck of everything it delivered: demos, proofs of concept, awards and patents. This year, something changed: the deck will also include the team’s refusals. Before, the reasoning behind each refusal stayed out of the deck, so the deck hid how much those refusals mattered and how much value they held.

Now the team treats the nos as an asset, capturing them in three steps: surface, bank and distribute.

Surface the assumption behind the request

A new idea can win a budget and a team before anyone checks what the idea needs to succeed. In those meetings, Camilo has found, people often have doubts but keep them to themselves. As a result, the idea moves forward on assumptions that stay hidden.

That moment is when Camilo’s team speaks up. One person says the hidden assumption out loud and asks a simple question: what has to be true for this idea to work? With the assumption out in the open, the group can discuss it and decide whether the idea should go ahead.

Asking that question in front of senior colleagues can cause friction, and Camilo admits his team makes some “frenemies” along the way. Still, he sees the payoff over time, because a team that explains its decisions well earns credibility.

Bank the best refusals in a standard format

Most refusals happen in small meetings, with only a few people present. Those people know why the team turned the idea down, but the reasons often stay in their heads. To share those reasons, Camilo’s team writes down its strongest refusals in a standard format that the rest of the team can reuse. Each record covers what the team decided, what would reopen the decision and what others should learn from it.

A refusal recorded this way doesn’t close the door. “When you say no, it’s not a dead end,” Camilo says. “A good no is supposed to open more roads.”

Writing down the reasons each time trains the team’s judgment. As the records add up, they build the team’s reputation as a careful filter for value. This may help most with AI requests from the top, because it tells the executive exactly what would turn the refusal into a yes.

Turn the challenger role into a team habit

Camilo’s manager brings healthy skepticism to the team’s ideas. That skepticism shaped how the whole team works. When Camilo joined, colleagues told him the manager’s questions set a high bar, so they tested their ideas thoroughly before sharing them. Camilo saw a chance to build on that habit and turn healthy skepticism into a skill the whole team shares.

To spread that skill, the team made challenging ideas a shared job. Camilo calls the approach “saying no as a service”. The idea, he says, is to “productize and operationalize the judgment” that leads to a better yes.

For example, each of the team’s priority technologies has a subject-matter expert, and every time the team meets to discuss those priorities, it picks one person, mostly at random, to challenge everything on the table.

This year’s deck, still a work in progress, has a separate section for refusals. It lists the nos the team banked, the triggers that are still open, and where the people and time from each refusal went instead. Camilo says that just talking about what the team dropped and what it’s working on now is already creating more value.

Overall, for innovation leaders who get a lot of requests, the list of open triggers could be one of the most useful pages in their innovation deck, since it tells leadership what would need to change for the answer to be yes.

Checklist: recording a refusal.

Use this right after your team decides to pass on a technology, pilot or request.

  • Shape: What did you decide, and what did you leave open? For example: wait until later, leave it to another team, or revisit it in a different setting.

  • Trigger: What specific conditions would turn this decision into a yes?

  • Lesson: What should colleagues learn from this decision, and who needs to hear it?

Reply

Avatar

or to participate

Keep Reading