Twenty Years, One Lesson: Change Slowly, Think Fast

People ask me fairly often how I've stayed in the same domain for twenty years.

There's usually an assumption buried in the question: that switching industries and becoming a generalist is the ambitious path, and staying put is the safe one. For a while that assumption got under my skin. I don't think it's true anymore.

What you only get from staying

Skills you can build quickly almost anywhere, with enough deliberate practice. Expertise you can hire. What you can't shortcut is context.

I've been in enterprise IT long enough to know why things look the way they do, because I was there for the decisions. At Accenture, I knew which ServiceNow configurations existed for a solid technical reason and which existed because one lead had strong opinions in 2014 and nobody pushed back. At Orange, I know which vendor relationships are genuinely strong and which just haven't been tested in a while.

None of that is written down anywhere. It lives in the heads of whoever was in the room, and it's useful less because it tells you what to do and more because it tells you what's likely to break if you do a specific thing.

What that context costs you

It's also, honestly, a bit of a trap. The same knowledge that explains why things are the way they are can quietly turn into "that's just how it's done here" — which is a different claim entirely, and a worse one.

I've watched colleagues leave for a while and come back with sharper questions than mine, simply because they hadn't spent years absorbing assumptions the way I had. They'd ask the obvious question I'd stopped asking, because I thought I already knew the answer.

So staying has its own job attached: keep asking the obvious questions anyway. Treat your own history with the place as a theory, not a fact.

Change slowly

The biggest lesson from integration work doubles as a career lesson: change slowly.

With systems, that means favoring small, reversible, well-monitored changes over big ones nobody's watching closely. Easy to say. Hard to do, because the pressure almost always runs the other way — deadlines, vendor release windows, someone wanting an announcement. The pull toward big fast changes is usually external. The pull toward small careful ones is usually just the quiet voice of whoever's on call if it breaks at 3am.

Careers work the same way. The things that look like small steps — a new responsibility, a new tool you picked up, nudging a team's focus slightly — add up to real direction over time. The things that look like big bold moves — switching companies, switching domains entirely — often change less than they seem to.

Twenty years in one place isn't the absence of change. It's change done carefully.

Think fast

The flip side of changing slowly is thinking fast.

The real risk with institutional knowledge isn't that you get complacent. It's that you get slow — you're the person who can spend six weeks building the case for why something's safe, and the organization pays for that delay even though the answer was clear in the first five minutes.

So the discipline I've had to build is thinking fast about the decision and slow about the execution. Use the context to size up whether something's safe quickly, then take your time doing it right. Extra thinking time past that first instinct rarely changes the answer — it just delays the planning and rollback work that actually needed the time.

Why I've stayed

The honest answer is simpler than a strategy: I've still been learning.

When that stops, I expect I'll know, and I expect that will change things. It hasn't stopped yet, partly because AIOps and observability keep moving in genuinely interesting directions, and partly because I've made an effort to stay curious on purpose — reading outside the field, talking to people who think differently, not trusting my own assumptions too much.

Change slowly. Think fast. Stay until the learning stops.

Not a bad twenty years.