5 things great innovation leaders do that nobody talks about

Great innovation leaders are rarely the ones with the most ideas or the best keynote. What sets them apart are quieter habits: they spend more time on the problem than the solution, they speak last, they go and see for themselves, they agree when to stop before anything starts, and they give credit away in rooms their team never enters. None of these appear in a typical leadership framework, and all of them can be practised from next week.

This is one of a set of articles on leadership and culture. For the full picture, start with innovation culture: what it is, and how leaders actually build it.

The five habits

1. They spend longer on the problem than on the ideas.

Most leaders get pulled into solutions because that's where the energy is. The ones whose teams deliver do the opposite: they keep asking whether the team is solving the right problem, for the right people, at the right level. A team that starts on "we need an app for appointments" has already skipped three questions: who is struggling, with what exactly, and why now.

What to do instead of jumping to ideas: before a team generates anything, ask for one page that states the problem, who has it, what evidence shows it's real, and what would be different if it were solved. A problem tree helps separate causes from symptoms. If the team can't fill the page, the work isn't ready for ideas. Sending it back at this stage costs a week; sending it back after a pilot costs a year.

2. They speak last.

In most organisations, the most senior person's first opinion becomes the meeting's conclusion. People don't disagree openly; they adjust. Leaders who know this hold their view until others have spoken, and they ask a question rather than give an answer when they do speak.

Amy Edmondson of Harvard Business School, whose research on psychological safety in teams is the standard reference, describes part of the leader's role as inviting participation: asking genuine questions and making it clear that input is needed. In a review, that means starting with "What worries you about this?" and waiting through the silence. It also means noticing who hasn't spoken and asking them directly, by name, in a way that's easy to answer. If you want a structured way to do this, silent writing before discussion works well (see silent first ideation).

What to avoid: "I like this, but what do you think?" You've already answered.

3. They go and see for themselves.

Reports flatten reality. A dashboard showing "average processing time: six days" hides the customer who waited forty, the form nobody understands, and the workaround staff use to get through the day. Leaders who stay close to the front line make better calls about which experiments matter.

What to do: once a month, spend two hours using your own service as a customer would, or sitting with the staff who deliver it. A service safari gives this some structure. Don't announce yourself, don't fix things on the spot, and write down what surprised you. Then bring one observation to the next team meeting as a question, not an instruction. Teams notice when a leader has seen the thing they're working on, and the quality of conversation changes.

4. They agree when to stop before anything starts.

Innovation projects rarely fail in a single moment. They drift: a pilot gets extended, then extended again, because no one decided in advance what "not working" would look like. By the time someone calls it, stopping feels like a judgement on the people involved.

Good leaders set stop criteria at the start, while nobody is attached yet. Before a test begins, agree on three things: what we're trying to learn, what result would tell us to continue, and what result would tell us to stop. Write it down. A simple hypothesis test format is enough. Running a premortem, Gary Klein's technique of imagining the project has already failed and asking why, surfaces the risks worth tracking.

When the stop result comes in, the decision is already made and nobody needs to lose face. That makes it possible to stop often, which is what keeps capacity free for the next good idea. (For how to close a project well once you've decided, see how to stop a project well.)

5. They give credit away in rooms their team never enters.

Innovation teams depend on people who aren't in the team: the finance analyst who found a way to fund a test, the operations supervisor who let a pilot run on her shift, the junior researcher whose interview notes changed the direction. Most of these contributions are invisible to senior leadership.

Great innovation leaders carry those names upward. In the executive committee, they say "this happened because Sara in finance found the budget line and Khalid's team gave up a week of their shift pattern". It costs nothing, and it does three things: it builds goodwill with the people whose cooperation you'll need again, it shows the organisation that contribution is noticed, and it protects the team from the suspicion that innovation is a closed club.

What to do: keep a running note, per initiative, of who contributed what. A RACI helps clarify roles up front; the note captures what actually happened. Use it every time you report up. Never rank the contributors; just name them and say what they did.

An example

Illustrative. The head of digital services at a mid-sized university in Australia inherits a team that has built three prototypes in a year, none of which reached students. Rather than push for a fourth, she asks the team to write one page on the problem each prototype was meant to solve. Two of the pages are thin.

She spends a morning in the student services queue and notices that most questions are about one enrolment step, not the broad "student experience" the team had been designing for. She brings that back as a question. The team reframes, agrees a four-week test with clear stop criteria, and asks the registry team to run it during their busiest week.

The test works well enough to continue. At the next senior leadership meeting, she names the registry supervisor and two student volunteers before she names her own team. Within a term, two other faculties ask to run similar tests with her team.

Do's and don'ts

Do

• Send work back at the problem stage, when it's cheap.
• Ask your question, then wait. Count to ten if you have to.
• See the service or process yourself every month.
• Write down stop criteria before a test begins.
• Name contributors, including those outside the team, every time you report up.

Don't

• Open a review with your own opinion.
• Rely only on dashboards and summaries to understand a problem.
• Extend a pilot without deciding what it now needs to prove.
• Treat stopping as a failure of the people involved.
• Turn recognition into a ranking. Naming is enough.

Questions people ask

What skills does an innovation leader need? Fewer creative skills than people expect, and more judgement: framing problems well, asking good questions, deciding when to stop, and building the relationships that let experiments happen inside normal operations. Most of these can be learned through practice.

Is innovation leadership different from normal leadership? The fundamentals are the same, but the balance shifts. Operational leadership rewards certainty and consistency. Innovation leadership requires comfort with not knowing, and the discipline to turn uncertainty into small, testable questions rather than big, risky bets.

How do I lead innovation if I'm not senior? Most of these habits don't need authority. You can frame problems carefully, ask questions before giving views, visit the front line and name contributors. When you need backing from above, see how to get senior leadership to back an idea, and for how to spend your time, the innovation leader's week.

Where to go next

Three method guides support these habits directly: the problem tree for staying on the problem, the service safari for seeing for yourself, and the premortem for agreeing in advance what could go wrong. More in the method guides.