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?