Not creative? You rewrote the same Flink job five ways before lunch.
Engineers swear we are not creative, then rewrite the same Flink job five ways before lunch. The two modes of technical creativity nobody teaches new leads, and the four words I keep repeating to mine: don't chase the yelling.
The sixth incident gets the fifth incident's fix by reflex.
That is what technical creativity is for: interrupting the automatic answer.
Engineers love the line. "I'm not creative, I'm an engineer." Then we rewrite the same Flink job five different ways before lunch and file it under "just work."
That loop is the creative work. We do it all day and never call it that.
Creativity is a spice. Not the meal. Nobody pays us to be original. They pay us to be right. But cook without it and every dish comes out identical. Same design. Same fix. Same postmortem, different quarter.
It runs in two modes. Most new leads only know one.
Problem mode: break your own pattern
Pattern recognition is the gift, compressed experience doing its job.
Your boss calls an "emergency" meeting. You feel the déjà vu before he finishes the sentence. Good. You've seen this exact shape five times before.
Then you reach for the same fix you always reach for: the quick patch on prod, instead of fixing the pipeline that keeps generating the patch. The old move is cheap, rehearsed, defensible. It worked five times. Nobody gets blamed for the rehearsed move.
That's how a strength curdles. Better pattern matching means faster convergence. Faster convergence means you stop looking around first.
Break your own pattern on purpose. Take a move that works in one place. Try it somewhere it has no business being. Give the hard feedback at the incident, while it's bleeding. Not in the quarterly review.
The pause is not negligence
The cheapest pattern-break is also the hardest one: stopping.
de Bono gave it a name and a whole chapter in Serious Creativity (1992): the Creative Pause. His version is stricter than mine. You pause for no reason at all; a trigger would defeat the point. Twenty to thirty seconds alone. Two minutes in a group. Then move on.
I run the field version, and the extension is mine, not his: fighting on five fronts? Stop for half a minute. Then choose.
My youngest tech lead physically cannot do this. A voice goes up in the corridor and he's already sprinting. I keep telling him the same four words: don't chase the yelling. Take the pause. Then pick which fire is actually yours.
To a new lead who only feels useful while doing, the pause reads as negligence. It's the opposite.
Sio and Ormerod pooled 117 incubation studies in 2009, over 3,600 participants: setting a problem aside reliably improved the solutions. Modest effect, real effect. Honest framing: that's research on setting problems aside, not on a thirty-second pause. Adjacent evidence, same direction. Stepping away has a meta-analysis behind it.
Don't brainstorm it. Not by default
Before you drag the whole team into a room to "brainstorm": don't. Not as the opening move.
The research has been clear since 1958. Taylor, Berry and Block had people ideate alone, then pooled the ideas. The solo pool held nearly twice as many distinct ideas as the same people produced in one room.
Diehl and Stroebe tallied the field in 1987: of 22 experiments, eighteen found alone-then-pool beat the live group on idea count. The only four exceptions were two-person groups. And every study that measured total idea quality, all six, favored the individuals.
Their own experiment isolated the mechanism: waiting for your turn to talk. Production blocking, they called it. One person speaks. Everyone else sits on their idea until it dies.
The bigger the room, the bigger the loss. A 1991 meta-analysis (Mullen, Johnson and Salas, 20 studies) found the gap grows with group size.
Flip the order. Produce ideas alone first. The room is where ideas collide.
Build mode: structure is a creativity tool
The second mode gets treated as creativity's enemy. Wrong. A whiteboard and a spreadsheet are where a messy problem becomes a solvable one.
The scene I keep landing in: a rotting legacy component. Stability issues. A stack of support tickets. A six-month rewrite plan. A team that's understaffed and never owned the thing. Five facts, and everyone in the room is holding exactly one.
Put every factor on the board. Score each one for impact and effort. Out loud.
The out-loud part is the tool. A silent spreadsheet hides disagreement. A spoken score forces it into the open. Someone says "low effort," someone else laughs, and the real conversation finally starts. Keep scoring until the shape of the problem is visible.
Two things become possible once it is.
You can show the stakeholder who only ever sees his own slice the whole board, and watch his demands recalibrate against factors he never knew existed.
And you can block the well-meaning people charging in to "help", the ones making it worse with full confidence.
The wrong lesson
We got handed the title "engineer," and somewhere that became permission to walk in straight lines and follow old runbooks. That's the wrong lesson to take from the job title.
The ban list has one item: giving the sixth incident the fifth incident's fix.
The lesson is not to slow everything down. It is to notice when pattern recognition has become autopilot, pause, and choose the work that is actually yours.
Sometimes the sprint is the right move. Prod is down and customers are locked out? Sprint. But make that a decision taken after the half minute, not a reflex that skips it. The pause doesn't kill urgency. It kills autopilot.
I've been that guy. The charger. Certain the problem is simple. Short on context. Feeling enormously useful. The feeling of usefulness is the tell. That's how I know to watch for him: from the inside.