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.
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.
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.
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.
Are you a ServiceNow Developer looking for your next great job?
Upload your resume and let our recruitment experts find your perfect role.
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.
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.
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.
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.
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.
Interested in a career working with ServiceNow?
Revolent’s ServiceNow course gives you the skills you need.
Travis Toulson is passionate about well-designed software that serves people. A ServiceNow Developer by trade, he spent his first seven years working in equipment maintenance and manufacturing. Frustrated by the software he was forced to use, he learned to code in order to become part of the solution. Now, he uses his spare time to help other developers navigate their journey and find creative business solutions.