The Roles of a ServiceNow Developer in an ITSM Implementation

Writing my own job description is one of the most oddly complicated things I’ve done in my career. In fact, when most people ask me what I do for a living, “it’s complicated” usually appears somewhere in my response. The role of a ServiceNow developer is a fairly complex one and not just because of the wide variety of applications on the platform.

Even when presented with a simple ITSM implementation, I have a laundry list of questions to go through before I understand my role in the project. How many other team members are on the project? Do we have a dedicated project manager, business analyst, architect, SCRUM Master? Is the customer using an existing system or is this a greenfield implementation?

Depending on the size and scope of an implementation, the role of a ServiceNow Developer can vary wildly. Let’s take a look at some of the most common roles a ServiceNow Developer might encounter in an ITSM implementation.

Technical Roles

Application Implementer

Counter-intuitively, the first role on the list is not that of a developer. In fact, most of the roles on this list have nothing to do with code. It’s quite common for a ServiceNow Developer to struggle to find time to write code in between all the other non-code tasks, particularly in consulting or smaller teams. One of the first and foremost roles of a ServiceNow Developer is that of an Application Implementer. As an implementer, a developer must know the ITSM application capabilities, configuration options, and ideally even the available plugins.

How do you create a Knowledge Article from an Incident? How do you post a Problem Workaround to associated Incidents? What is the Standard Change catalog, and how does it work? What if I want to be able to version Knowledge Articles? These are the sorts of questions you might receive. A few targeted responses of “I do not know, but I will find out” won’t hurt your credibility as a developer but you definitely want to be able to field basic questions about the ITSM applications.

Developer

ServiceNow supports an ever-growing array of no-code and low-code options for developing processes, and the offering that they have cultivated is really impressive. But, when you get right down to it, much of ServiceNow still requires code at some point. Workflows have script activities. Business rules have advanced scripts. Email notifications have mail scripts. You can even write custom scripts to extend the latest and greatest process tool on ServiceNow, Flows.

Slinging code is just part of life on the platform. ServiceNow Developers live in an odd world though. Where most JavaScript Developers are leveraging ES6, functional programming patterns, and asynchronous code, ServiceNow Developers are writing in mostly Object Oriented patterns on ES5 with synchronous code. Some even jokingly refer to the language we use as SNJS because it bears so little resemblance to JS everywhere else.

Much of being a ServiceNow Developer is about learning to code on ServiceNow specifically. The difference between the server-side scripts and the client-side scripts takes some getting used to, then there’s understanding which APIs are available in which scripts, and learning when it’s best just to put down the script and walk away.

Application Architect

Speaking of putting down the code, another role I frequently find myself in is that of an architect. You may think “oh that’s only senior developers, folks that have been doing this a while,” but the reality is that I ended up in this role from day one. Whether working in-house or as a consultant, it’s quite common to wind up as a solo developer or as a developer on a very small team. When that happens, be prepared to draw up your own implementation plans.

Architects on ServiceNow spend much of their time wrestling with the great configuration vs. customization debate. As an Architect, you will focus on designing an implementation so that it minimizes upgrade risk while maximizing development velocity.

Is there a simple configuration you can use instead of a custom script? Should you implement the behaviors on the baseline table or create a new set of tables in a scoped application? How will you communicate your design decisions if you have to hand off the project to someone else? These are the sorts of questions that will challenge you when donning the architect hat.

Administrative Roles

Technical Writer

Oh documenting… everyone’s favorite subject! Some projects require extensive documenting, while others require almost none. Documentation comes in many forms and can include release notes, architectural designs, functional designs, testing documentation, training documentation, and still many others. Personally, I’ve had the privilege of working with some folks who are the technical writing equivalent of Tolstoy. I, for one, can’t stand writing documentation. Yes, the same guy that writes technical guides “for fun” hates writing documentation, go figure. But that’s my point, really; like it or not there’s just no substitute for strong technical writing skills.

Whether you’re injecting documentation in your code comments or writing formal documentation, a major part of being a Developer is communicating your work in some written form or another. So don’t slouch on these skills—for clients who love documentation, well-written documents are practically your RSVP to the next project.

Presenter

Speaking of communicating, you’ll also want to hone your presentation skills. For many consulting companies, there are few, if any, positions for the backroom coder. Even in my experience on an in-house team, I found myself in situations where I was presenting solutions to an audience.
As a consultant, presentation skills become far more important to career progression. Whether delivering portions of a project kickoff, participating in sales demos, or running workshops, I’ve spent almost as much time talking about my code as I’ve spent writing it. Good public speaking skills are just the foundation. You’ll also need to develop your ability to think on your feet. On at least two occasions, I walked in with a workshop game plan, only to have to completely change directions within the first few minutes. You don’t need to start dropping into your local improv comedy club for practice, though. Just work on being a comfortable, confident presenter, know your material, and take a genuine interest in your customer’s needs. The rest will fall naturally.

Troubleshooter

When it gets right down to it, the goal of every developer is to solve problems. Everything else that we do from code, to communication, to documentation, all of it serves the ultimate goal of solving problems. Whether we’re solving business process issues or technical issues, troubleshooting is at the heart of it. This is one area where I love my Lean Six Sigma experience, which I highly recommend looking into.

If I had to pick one role, one skill that sets apart the good developers from the great ones, this would be it. Sadly, it’s all too often seen as a bit of a mystical quality that only certain people possess, but I can tell you that it most certainly isn’t. Like any skill, troubleshooting and problem-solving skills can be learned and honed. If you want to learn more, I recommend starting with 5 Whys, Fishbone Diagrams, and more generally Root Cause Analysis. The important thing is to focus on asking the right questions.

Conclusion

The above roles are really just a sample of the complex nature of the ServiceNow Developer’s job. I can easily make the case for a handful of other roles and skills from QA Tester to Project Manager. I’d need a much larger blog post to be a hat rack for all the roles I’ve had as a ServiceNow Developer, and I’m sure others could even add to that list. The needs of your team dictate quite a bit about the nature of your role as a developer, even to which specialization you pursue. The important part is to be ready to dive in and serve their needs to the best of your ability.