The Eighteen-Month Engineer
A decade of short stints reads as instability until you see the clock underneath it: a brain wired for novelty does its best work at the start of things and runs out of road on solved problems — and the hiring filter double-taxes exactly that profile.
Look at my resume long enough and a pattern jumps out. Ten months. Nine months. Five months. Then a stretch around eighteen. A company I founded that ran about twenty. Freelance for a year before that. A decade of work where most roles cap out around the same mark, give or take, and then I’m gone.
The industry has a word for this and the word is “unstable.” Recruiters see it and flinch. Hiring managers ask the polite version of “so why do you keep leaving.” And for years I half-believed the read, that something was wrong with my ability to commit, that steadier people had a virtue I was missing.
I don’t believe that anymore. What’s actually there isn’t instability. It’s a clock. And once you understand the clock, the whole thing reads differently, including the parts the industry gets wrong about engineers wired like me.
The clock
Here’s the actual cycle, honestly.
I join something. There’s a real problem, usually a hard one, ideally something that doesn’t exist yet. I go into builder mode and it is the best version of me. I’ll out-work anyone in the room because the problem is novel and my brain has finally found the one thing it will happily hyperfocus on for weeks. Architecture, zero to one, a team that needs building from nothing, a migration nobody wants to touch. This is where I do my best work by a wide margin and it isn’t close.
Then the hard part gets solved. The system exists, the team is built, the interesting decisions are all made. What’s left is maintenance, iteration, keeping the lights on, and the same organizational politics that show up in every company once the building is done and people start defending territory instead of making things.
And that’s when the novelty drains out, and with it, the fuel. It isn’t a decision. It’s the same wiring I wrote about last time, finish holds exactly as long as the thing is still novel and then falls off a cliff. My openness score sits at the 99th percentile. That’s not a fun fact, it’s a spec sheet. A brain built that far toward novelty is going to run out of road on a solved problem, every time, on roughly the same schedule.
Some of those short stints ended for boring external reasons, an acquisition, a project wrapping, a company folding. But the internal clock was the constant underneath all of it. Even in the good roles, the ones I’d defend, I could feel the engagement curve bending down at the same point.
Where this wiring is a gift and where it’s a liability
I’m not going to pretend this is all upside, because that’s the cope-y version and you’d see through it.
The gift is real. Point me at a zero-to-one problem and I’m one of the best bets you can make. Scaling a team from fifteen to sixty-six from scratch, migrating thirteen microservices off a legacy stack, founding a company, building a memory layer that ships when nothing else does. The novelty wiring plus the hyperfocus plus openness is a genuine edge on hard, undefined, greenfield work. The stuff most engineers find intimidating is exactly the stuff that switches my brain fully on.
The liability is just as real. Hand me a mature codebase and ask me to babysit it for three years and you will get a worse engineer than the median. Not because I can’t, on paper, but because the thing that makes me good at the hard start is the same thing that makes me bad at the long middle. Same wiring, both directions. Pretending otherwise would be lying to you and to myself. A brain optimized for novelty is, by construction, not optimized for repetition. You don’t get one without the other.
That’s the honest version. It isn’t a superpower and it isn’t a defect, it’s a shape, and the shape has an edge and a blind side.
The filter that misreads it
Here’s where the industry actively gets it wrong, and it’s worth naming because it’s fixable.
The default engineering hiring filter is built for a different animal. It screens tenure as a proxy for reliability, so the novelty-wired engineer gets penalized for the exact rhythm that makes them good at the beginning of things. And then the interview itself, the live-coding round specifically, penalizes the wiring a second time.
I know my failure mode in a timed live-coding interview precisely, because I’ve watched myself do it. Handed a clock, I over-invest in setup and edge cases, I want the thing correct and complete before I’ll call it done, and I run out of time on the core logic. That isn’t a capability gap. Hand me the same problem as a take-home or a system-design discussion and I’ll turn in strong work, because the format lets me operate the way my brain actually operates. The live-coding round doesn’t measure whether I can build the system. It measures whether I can suppress my own wiring for thirty minutes under a stopwatch, which is a different skill, and not one the job actually needs.
So the filter double-taxes exactly the profile that would be most valuable on the hardest problems. It reads the tenure clock as a red flag, then it runs a format that rewards the opposite temperament to mine, and the engineer who’d be a monster on your zero-to-one initiative never makes it past the screen. That’s not the engineer failing the industry. That’s the industry’s instrument being calibrated for one body type and quietly rejecting the rest.
What actually works, both sides
For managers, if you’ve got someone like this, the move isn’t to fix them, it’s to aim them. Point them at the greenfield, the migration, the thing that doesn’t exist yet, and let someone wired for the long middle own the maintenance. Rotate them onto new hard problems before the eighteen-month mark instead of watching them disengage and calling it an attitude problem. Judge them on the hard things they ship, not on process compliance or how long they warm a seat. You will get the best eighteen months of that person’s career on repeat, which is a genuinely good trade if you stop demanding it look like everyone else’s thirty-six.
For the engineer, and I’m mostly talking to myself here, stop apologizing for the clock. Stop taking the maintenance role and then hating yourself at month twenty when the wiring does exactly what the wiring does. Select for it. Chase the roles that are all beginning, consulting, platform zero-to-one, founding engineer, the migration everyone’s scared of. Build the tools that carry you through the parts your brain won’t do on its own, which is the entire subject of my last post. And when a live-coding round is about to misread you, push for the take-home, because you’re not asking for an accommodation, you’re asking to be measured on the actual job.
I spent years reading my own resume as a list of failures to commit. It isn’t. It’s a decade of beginnings, and beginnings happen to be the thing I’m best at. The clock was never the bug. The bug was trying to run novelty hardware on a maintenance schedule and blaming the hardware when it stalled.
Eighteen months, and gone, isn’t a warning label. For the right problem, it’s a spec.