Leadership — Idea Power

Idea power

Earlier we covered the three walls that block innovation, and using a journal to take down the first one — but once the wall is down, where do the ideas come from?

This chapter’s answer: idea power is a skill you can train, not a gift. And more counter-intuitively — a leader’s biggest contribution to the team’s ideas is usually not “having the idea”. Imagine innovation as “waiting for some genius to have a flash” and you’ll miss what a leader should actually be doing: keeping a live idea flow — ideas get in, get polished, and survive long enough to be understood.

Ideas don’t have to be original: steal

The most obvious contribution is offering your own idea — but that’s one fifth of it. The second is stealing: creative borrowing and adaptation. How did another team solve a similar problem? How does an open-source project design this piece? Is there a ready-made pattern in another field? Take it, adapt it until it fits your environment, and you have a good idea.

Engineers do this every day — searching, reading source, lifting design patterns — but the moment it becomes “a proposal”, many of us suddenly feel an idea only counts if it grew from nothing. That originality myth is, underneath, still the belief that a problem has one right answer: as if someone else’s answer closes the question. In practice ideas rarely grow out of thin air — being able to graft someone else’s solution onto your own soil and keep it alive is idea power.

Working on ideas: the contribution that happens more often than originating them

A newborn idea is almost always half-baked — even the person proposing it only sees half of it. So the third contribution is working on someone else’s idea: adding the edge case they missed, connecting it to a tool that already exists, pointing out the small piece to build first to test it.

What an idea looks like when it finally ships is usually a composite that several people worked on — at which point “who originated it” stopped mattering long ago. A team’s idea flow only stays alive when people are willing to spend effort on other people’s ideas instead of insisting their own name stays on the board.

Putting your own idea down

The hardest of the five — because it’s a fight with your own ego.

And the hard part is this: “better” is never absolute. Whether an idea is good enough is relative to “this team, right now, can it afford to keep it” — however good the performance is, if the team can’t maintain it, then in this team it isn’t the better solution. Which is exactly what organic thinking says: an idea’s value grows out of its environment, it isn’t attached to the idea.

So putting your idea down doesn’t have to mean “I lost”. More often it just means “the us of right now suits a different one”. I didn’t learn that sentence from the book — I paid for it with several years of self-doubt. The story’s in the reflection.

The phrases that kill ideas, and what to say instead

An idea is at its most fragile the moment it’s born — one sentence can kill it. The killers all look alike: using the past or the present to veto a future nobody has understood yet.

Idea killer	Replace with
”We tried that before"	"What was the situation last time? What’s different now?"
"That won’t work"	"What’s missing for it to work?"
"The whole project does it this way"	"The problem it’s trying to solve — do we have it right now?”

The left column ends in a full stop, the right in a question mark. One sentence apart — but the left kills the idea and the right forces everyone to understand it first. A leader’s fifth contribution is being the umbrella while the idea is still unsteady: block those phrases, and let it survive at least until it’s understood. Kill it after that, and that’s judgment; veto it without ever understanding it, and that’s just reflex.

Reflection

The two contributions in this chapter — “putting your own idea down” and “not letting ideas be killed” — each come with a story I still feel. In one I was the one being killed, in the other I was the one holding the knife. In the journal format from last time: facts, feelings, lessons.

Being the one killed: order statistics

Facts: years ago, at a food-delivery company, we ran an internal event where people from the app team got to try backend work: several of us each designed and implemented the same feature, and one implementation would ship. My assignment was order statistics. The database was MongoDB, and I did the entire aggregation on the database side with the ORM’s aggregation pipeline and returned the result directly; a colleague queried the data out in chunks and processed it in JS afterwards. We actually measured performance — mine was faster, and that isn’t just my opinion. What shipped was the other one: the reason being that, given the backend team’s style at the time, the chunked-query version was easier to maintain.

Feelings: deflated. And not only at the time — for a good while afterwards I kept circling the same doubt: was my approach wrong?

Lessons: years later, knowing more, I actually made peace with it. What suits a team changes with the time, the context and the people in it. Even a measured performance win isn’t enough to make an idea prevail — because picking an idea was never picking “the best one”, it’s picking “the one this team can afford right now”. My approach wasn’t wrong; it just didn’t suit that team at that time. And the me who doubted himself back then had fallen straight into the third obstacle: believing a question has one right answer, so not being picked means being wrong.

Being the one holding the knife: ORM models as domain entities

Facts: later I was the reviewer. A colleague had put real care into a clean architecture — clear layers, an independent domain entity. I blocked it in code review and made him go back to using the ORM’s model directly as the domain entity. My reason, in full: “the whole project does it this way.”

Feelings: nothing at the time — I even felt I was protecting the project’s consistency. It wasn’t until I genuinely understood what clean architecture is solving that it hit me: I was the clown in that exchange.

Lessons: when I killed that idea, I hadn’t understood it. That wasn’t judgment, it was pattern matching: “different from what we do now” equals “wrong”. This is the no-problem syndrome in its code-review form — rushing to apply the answer you already have, skipping the problem the other person was actually trying to solve.

The dividing line: had you understood it before you killed it?

Put the two stories side by side and there’s something awkward: the reason for killing the idea was nearly identical both times — “consistent with how the team works now”. So why was the order-statistics kill reasonable, and the clean-architecture one a wrongful one?

The line is: had anyone understood it first? With order statistics, both implementations were actually built and the performance actually measured — the team chose the one it could afford after understanding both. With clean architecture, I couldn’t even state what problem it was solving before I reached for consistency as a weapon.

So I now hold myself to a hard rule: until I can state an idea’s merits, I have no standing to reject it. Environment is a legitimate reason to reject something — but only after the idea is understood; reaching for consistency before that isn’t gatekeeping, it’s killing ideas.

One more thing, learned from being on the receiving end and only possible now that I’m the leader: when you reject someone’s proposal, say out loud that the reason is environmental, not that theirs is worse — “your approach isn’t wrong, it just doesn’t suit the us of right now”. Nobody said that sentence to me back then, and I doubted myself for years. One sentence in exchange for someone else’s years of self-doubt — the arithmetic isn’t close.