What I Learned Writing a “Day in the Life” Series on ServiceNow Roles

[alexalejandro]

A few years ago, I responded to a community post with a quick breakdown of what a ServiceNow System Administrator does on a day to day basis.

That simple reply turned into a series.

This post continues that journey, but this time stepping back and looking across all of the roles together.

After going through Admin, Developer, Technical Consultant, Business Process Consultant, and Architect, a few things stood out more than I expected.

🎯 What I Thought Going In

At first, it felt like each role was completely different.

• Admin focuses on the platform
• Developer focuses on building
• Technical Consultant focuses on delivery
• BPC focuses on process
• Architect focuses on direction

Each one looked like its own lane.

☕ What I Started Noticing

After writing all of them, that changed pretty quickly.

The roles are different, but the problems are very similar.

• things are unclear
• teams are not aligned
• decisions get pushed too late
• assumptions are not validated

The work just shows up in different ways depending on the role.

🧭 Alignment is Everywhere

This was probably the biggest pattern across all of them.

No matter the role, a lot of the day is spent on alignment.

• Admins align stability with business needs
• Developers align implementation with requirements
• Technical Consultants align delivery with expectations
• BPCs align process with reality
• Architects align everything with long-term direction

Different focus, same theme.

⚙️ The Work is Less Technical Than It Looks

This was something I did not fully appreciate at first.

Across every role, the harder parts are rarely technical.

They are things like:

• unclear requirements
• miscommunication
• lack of direction
• decisions not being made early

The platform matters, but a lot of the real work happens around it.

🔧 Where Things Usually Go Wrong

Another pattern that showed up consistently.

Most issues do not start where they show up.

• unclear requirements turn into rework later
• rushed decisions turn into technical debt
• lack of alignment turns into delivery issues

By the time something breaks, it usually started much earlier.

📊 What Changes Over Time

This is probably the biggest shift across roles.

Early on, you focus on tasks.

• building something
• solving a ticket
• completing a requirement

Over time, that changes.

You start focusing more on:

• outcomes
• alignment
• long-term impact

That shift shows up in every role in different ways.

🔐 In Regulated Environments

This becomes even more visible.

• decisions need to be clear
• changes need to be traceable
• solutions need to hold up over time

It forces you to be more intentional across everything.

🔄 What All the Roles Have in Common

Stepping back, a few things keep coming up across all of them:

• Ask more questions early
• Keep things as simple as possible
• Make sure everyone is aligned before building
• Think about long-term impact, not just immediate delivery

It looks different depending on the role, but the ideas are the same.

💡 If I Had to Sum It Up

The platform is important, but it is only part of the picture.

Most of the work across all of these roles comes down to:

• people
• process
• decisions

And how well those come together.

💬 Discussion

For anyone working across ServiceNow roles:

👉 What is something that changed how you see your role over time?
👉 What is one thing you wish you understood earlier?

[alexalejandro]

Appreciate anyone who took the time to read any part of the series.

Writing these made me realize how connected all the roles really are. They just focus on different parts of the same problem.

Curious to hear from others. What is one lesson that changed how you approach your role over time?