Twenty Years, One Lesson: Change Slowly, Think Fast

People often ask me how I've stayed in the same domain for so long.

The question usually contains an assumption: that staying in one technical space is the conservative choice. That the people who've pivoted, switched industries, become generalists, have accumulated more experience, broader perspective, more options. That twenty years in enterprise IT is a kind of professional settling.

I used to feel defensive about this. Now I think the assumption is just wrong.

What you can't get anywhere else

There is a type of knowledge that only time produces. Not skill — you can develop skills quickly, in different environments, with deliberate practice. Not expertise — expertise can be bought, consulted, hired.

What only time produces is context.

I've been in enterprise IT long enough to understand why integration architectures look the way they do — because I was present for the decisions that shaped them. At Accenture, I could see which ServiceNow configurations were made for strong technical reasons and which were made because a particular lead had strong opinions in 2014 and nobody pushed back. At Orange, I know which vendor relationships are genuinely strong and which survive on inertia alone.

This knowledge is not in any documentation. It lives in the heads of the people who were there. And it is extraordinarily useful — not because it tells you what to do, but because it tells you what will happen if you do a dozen specific things.

Context is the difference between making a change and making a change with understanding of what it's connected to.

The cost of institutional knowledge

But I should be honest about what it costs.

Institutional knowledge is genuinely useful. It's also genuinely constraining. The same context that tells you why things are the way they are can also make it harder to imagine them being different. You start to confuse "that's how it works in this ecosystem" with "that's how it should be done."

I've watched colleagues move between domains and come back with perspectives that were obviously valuable precisely because they hadn't spent years absorbing assumptions I didn't know I had. They'd ask questions that I would have stopped asking long ago because I thought I already knew the answers.

The freshness was useful. And I had to work to stay fresh — to keep asking the obvious questions, to keep treating my own institutional knowledge as hypothesis rather than ground truth.

This is the work of staying. Not just accumulating context, but periodically interrogating it.

Change slowly

The most important integration lesson I know is also the most important career lesson I know: change slowly.

In systems, this means: prefer small, reversible, well-monitored changes to large, irreversible, poorly-monitored ones. This is obvious when stated plainly, but the organizational pressure often runs the other direction. Projects have deadlines. Vendors have release windows. Executives want announcements.

The pressure to make large changes quickly is almost always external. The incentive to make small changes carefully is almost always internal — the quiet voice of the person who will be on-call when the change causes something unexpected at 3am.

In careers, the same principle applies. The decisions that look like small increments — taking on a new responsibility, learning a new technology, shifting a team's focus by 10 degrees — compound into large changes in direction. The decisions that look like large bold moves — changing companies, pivoting to a new domain, rejecting an entire technology stack — are often less transformative than they appear.

Twenty years in one place, if you approach it the right way, is not the absence of change. It's change with discipline.

Think fast

The counterpart to changing slowly is thinking fast.

The organizational risk of institutional knowledge isn't complacency — it's slowness. The person who understands all the context is also the person who can spend six weeks building the case for why a change is safe before taking any action. The organization gets the benefit of the context and the cost of the delay.

The discipline I've had to develop is: think fast about the decision, not about the implementation. Use the context to quickly assess whether a change is safe, and then implement it slowly.

Most of the time, the first five minutes of thinking about a change tells you whether it's reasonable or not. Additional time refines the estimate but rarely changes the direction. The rest of the time should be spent on the implementation — the planning, the dependencies, the rollback, the communication.

Fast thinking is not rash thinking. It's the application of accumulated context at speed. It's what you're actually building when you accumulate twenty years of institutional knowledge.

On loyalty as strategy

The honest version of why I've stayed in this domain: I've always felt like I was still learning.

When the learning slows, I expect that will change. When the context stops being useful and starts being limiting. When the domain's pace of change falls below what I need to stay sharp.

That moment hasn't come yet. Maybe that's luck. Maybe it's because enterprise IT — AIOps, observability, ITSM integration — keeps evolving in genuinely interesting ways.

Maybe it's because I've been deliberate about keeping my perspective fresh even while staying put. Reading outside the domain. Talking to people who work differently. Treating my own assumptions as provisional.

Twenty years is a long time. One lesson feels like too small a return. But if I had to distill it:

Change slowly. Think fast. Question your context constantly. Stay until the learning stops.

That's not bad for twenty years.