Follow the process (kinda)

One of my colleagues used the expression “in a previous life” when referring to jobs he held in the past. I love that, so I will borrow it for this post.

In a previous life, I worked for a giant, extremely process-centric company.

If you know me, you know I am a process guy. I believe processes and tools enable great people to do amazing things while also allowing mediocre people to achieve very acceptable results. Most of the time, that does not have any real downside.

Specifically in Information Technology, ITIL is one of the major frameworks that provides processes to guide companies, teams, and individuals along a proven path that is likely to yield good results.

But, as the saying goes, too much of a good thing can be bad.

Let me tell you a story that happened to me. More than 20 years later, it still leaves me with a bad taste in my mouth.

While working at this company, which shall remain unnamed, I was part of what was called the “transition” team.

See, back in the day, companies used to have their own data centres and large IT staffs. During the early 2000s, large companies started outsourcing both of those things. They would find a large, competent, and specialized IT company like my employer and outsource everything: the local network, servers, backups, security, and, in some cases, even desktop support.

We are talking about large companies here, with hundreds or thousands of servers, applications, users, end customers, and so on. Banks, utility companies, publicly listed enterprises, and others like that.

Moving those IT operations from their local teams to our management was a multi-month, and sometimes multi-year, project. It required coordination with tens of people, dozens of companies, and very often several “migration waves.”

And 20 years ago, migrating data centres actually meant parking a large truck at a physical location, unplugging hundreds of servers, moving them to a new location, and reassembling everything.

This always happened over long weekends. During the time I worked for that team, I do not think I enjoyed a single holiday. I was always working. Long hours, too.

My longest non-stop migration was a 32-hour marathon that brought a large insurer into our data centre, 200 km from their original location. At some point, I took a nap on the data centre floor, leaning against a server rack.

But I digress.

As you can imagine, we had many processes in place for these activities to ensure they were well coordinated and actually succeeded. Our CAB, or Change Advisory Board, was a tough crowd. Everything had to be written down, planned, and explained during meetings.

Rollback plans. Fix-forward plans. Contingency plans.

Everything had to be there.

The thing is, nothing is ever perfect.

During one of those major migration waves, at some point in the wee hours of the morning, we had an issue. A show-stopper level issue.

At the time, I was part of the network group, and I found that one crucial network segment could not be accessed by another layer. Because the company was structured the way it was, and because the firewalls were Linux machines, the Unix team was responsible for routing and filtering, not the network group.

So I picked up the phone and called the Unix on-call.

No response.

It was past 3 AM, and the maintenance window for the network team was almost over. I had to wrap up and hand the work to the next teams so they could do their part and keep the migration moving. The whole thing was expected to be completed around 7 AM, if I remember correctly.

So there I was.

I could not find help. We were too far into the maintenance to safely start a rollback. Fix-forward was the only option after you had already trucked the servers 200 km away. And without that network segment, everything was going to explode in a few hours.

So I called the project manager and explained the situation.

In a panic, he asked me what we should do.

Since I am a Linux guy, I told him I knew what needed to be done and how to do it. He just needed to say the word.

Of course, he gave me the go-ahead.

Five minutes later, everything was done, and the migration succeeded. Not a hiccup, as far as the customer could tell.

Fast-forward a few months, and we got to the annual performance review.

The previous year, I had received the highest rating. I knew I had worked even harder that year, so I had high expectations.

Then I had a terrible surprise.

My manager told me I had been very successful, that my contributions were extremely important, and that he had only positive feedback from all the project managers I worked with.

However, during that migration, I had gone around the process. I had done work that was not mine to do, and I had touched systems I was not supposed to touch.

That dropped like a hammer on my evaluation, and I would not be ranked nearly as well as the previous year.

Suffice to say, I did not stay with that company much longer.

I am telling this story here because I want people to learn the right lesson from it.

I see people on Reddit and other social media going through similar situations, and their takeaway is often to never go the extra mile. Never do more than what is in your job description. Never try to be of value. Stick to what you are told. Just follow the process.

Looking back after more than 20 years, I can tell you I would still do the same thing again.

And by the way, I did similar things many times after that, in many companies. And I am pretty happy with how my career turned out.

I love process. I like SOPs, runbooks, approvals, and clear ownership.

But doing the right thing is still more important.

Sometimes the best result requires doing something that is not written down, not clearly assigned to you, and not neatly covered by the process.

That does not mean process is useless. It also does not mean everyone should improvise whenever they feel like it.

That is where people often get this wrong.

The lesson is not “ignore the process.”

The lesson is that process should support judgment, not replace it.

When process protects the work, respect it. When process blocks the only sane path forward, good people need enough trust, context, and courage to make the right call.

Most companies and bosses will recognize that in a positive way, not as a black mark on your scorecard.

The other lasting effect of this experience is that, once I became a people manager myself, I encouraged my engineers to challenge processes.

Not casually. Not recklessly. But thoughtfully.

I wanted them to understand why a process existed, what risk it was trying to reduce, and when the real-world situation in front of them no longer aligned with the assumptions underlying it.

I also learned to judge people by the quality of their judgment and the outcome of their work, not only by whether they followed the documented path.

In some cases, when an engineer found a better way, the right answer was not to drag them back to the old process. The right answer was to update the process so everyone could benefit from what they had learned.

For the leaders out there, remember that processes exist to improve outcomes.

They are not the outcome.

They are tools. And like any tool, they can become outdated, misused, or applied in the wrong situation.

If someone goes outside the process and creates unnecessary risk, deal with that.

But if someone uses good judgment, protects the customer, saves the project, and exposes a weakness in the process, your job is not to punish them.

Your job is to learn from it and fix the system.

And if your company expects you to sacrifice your best people to protect a broken process, pay close attention. A system that treats good judgment as a liability will eventually punish you for using yours too.

That is the real lesson I took from that previous life.

Respect the process. Build good ones. Follow them when they make sense.

But never forget that the goal is not to satisfy the process.

The goal is to do the right thing.