Early in my career, nobody hired me to redesign processes or rethink how an IT department worked. Like most junior support engineers, I was there to resolve incidents, help users, and follow existing procedures.
Working on the frontline gives you a different perspective, though.
When you perform the same tasks every day, you quickly notice where time is wasted. Documentation becomes harder to navigate, repetitive work starts to feel unnecessary, and some processes seem to exist simply because nobody has challenged them in years.
During my time supporting one of the largest enterprise environments I've worked in, I ended up leading two internal improvement initiatives. Neither required a new platform, a large budget, or a transformation program. Both started from a simple observation: everyday work could be made easier.
Rebuilding the Knowledge Base
The first issue wasn't the documentation itself. It was the way knowledge had evolved over time.
Procedures had been written by different people, using different formats, for different audiences. Some documents contradicted each other, others were outdated, and finding the right procedure could easily take longer than resolving the incident.
The same applied to Microsoft Teams.
Over the years, channels had multiplied without much structure. Operational procedures, project discussions, announcements, and reference material were scattered across spaces that reflected the organization's history rather than the way people actually worked.
Instead of updating individual documents, I proposed rebuilding the knowledge base from scratch.
The goal wasn't to create more documentation. It was to make information easier to find, easier to understand, and easier to maintain.
Every procedure followed the same structure. Obsolete content disappeared. Naming conventions were standardized, and Teams was reorganized around clear operational areas instead of historical habits.
Looking back, the documentation and the Teams redesign were really the same project. Good documentation has little value if nobody can find it. Likewise, a well-organized workspace naturally encourages people to keep information up to date.
Documentation is often treated as administrative overhead. In reality, it's one of the best operational investments an IT team can make. Saving a few minutes during every incident quickly adds up across an entire support organization.
Improving Operational Visibility
Once information became easier to access, another problem became obvious: visibility.
The onsite support team used ServiceNow, but understanding the current situation still meant opening several views or manually gathering information before anyone could answer basic questions.
- How many tickets are waiting?
- Who's overloaded today?
- Where are bottlenecks starting to appear?
- What should we focus on first?
To solve that, I built a set of dashboards tailored to the team's daily work.
The objective wasn't executive reporting. It was to help the people doing the work make better decisions throughout the day.
The most useful dashboard isn't the one with the most KPIs. It's the one that answers the questions the team asks every morning.
Why Fresh Perspectives Matter
Looking back, what stands out is that I was still at the beginning of my career.
I wasn't responsible for governance, operational strategy, or process improvement. I simply spent enough time doing the work to notice where unnecessary friction existed.
That taught me something I've kept ever since.
Junior engineers often spot improvement opportunities because they haven't yet accepted inefficient processes as normal. They naturally ask questions that experienced teams sometimes stop asking.
- Why is this still manual?
- Why is the same information stored in three different places?
- Why are we doing it this way?
Those questions are often more valuable than they first appear.
Unfortunately, many organizations expect junior engineers to execute existing processes, not improve them. That's a missed opportunity. They're usually the people interacting with those processes hundreds of times every week.
Experience Gives Context. Fresh Eyes Reveal Friction.
This isn't about saying junior engineers know better than senior architects.
Experience brings context. It explains why certain decisions were made, what constraints exist, and where the real risks are.
Fresh eyes bring something different. They notice the small frustrations that slowly become invisible to everyone else.
The strongest teams combine both perspectives.Senior engineers provide direction and consistency. Junior engineers challenge assumptions and expose unnecessary complexity. That's often where the most practical improvements come from.
Continuous Improvement Doesn't Have to Be a Program
Most operational improvements aren't revolutionary. They're small changes that remove friction from tasks people perform every single day.
Giving junior engineers ownership of internal improvements, making time for documentation and automation, encouraging people to question existing processes, and judging ideas by their value rather than by the seniority of the person proposing them can have a much bigger impact than another transformation initiative.
Operational excellence rarely comes from a single breakthrough. More often, it's the result of dozens of small improvements introduced by people who simply wanted to make their work a little easier.
A Lesson I Still Apply Today
Neither of these projects changed the company's architecture.
They didn't introduce new technologies or transform the business.
One made knowledge easier to manage. The other made day-to-day operations easier to understand.
Both were built to remove friction for the people using them every day. At least I hope they still do—I left the company near the end of both projects.That experience still influences the way I approach consulting today. Whenever I join a new customer, I pay close attention to the engineers closest to the operational work. They're usually the first to notice unnecessary complexity, inefficient workflows, and improvement opportunities that are almost impossible to see from an architecture diagram.
0 Comments