What a journey from Eureka to Yokohama. From junior developer to Certified Technical Architect. From working as a consultant to co-founding my own app-focused company.
I’ve collected some lessons along the way (usually after making some mistakes myself).
In no particular order:
- Don’t over-engineer too early. Start simple, create prototypes and proofs of concepts to understand the problem better. Learn, iterate, and explore different paths. Discover some unknown unknowns before you commit to a solution.
- Master best practices. Follow them blindly until you know them by heart. Then break them.
- Focus on what won’t change. It’s impossible to predict what’s going to be the new trend in 5 years, but look back and see which features were used 10 years ago, were there 5 years ago and are still widely used in the platform. Old things are hard to kill (hi, Jelly!).
- You don’t work for ServiceNow unless you work for ServiceNow. Don’t get overexcited about new features. It’s good to be aligned, but what ServiceNow is currently promoting might not be the ideal solution for you or your client right now. Besides, the gap between the announcement and when you can “play with the new toys” in a customer instance might be more than a year.
- Work smarter, not harder. Not using SN Utils, Xplore, or Raycast is unnecessarily painful.
- Don’t expect a red carpet on day one. When you start a new project, you are excited, but the people on the client side have already been through several transformation projects. Switching tools, changing processes. Broken ServiceNow instances with lots of technical debt sometimes. There’s a lot of scar tissue there. Things might be complicated until you demonstrate that you are not going to make things even worse.
- Understand the basics of licensing even if you are an admin or developer. They might impact your designs. And do NOT put things in the CMDB that don’t belong there just because those tables are free!
- ServiceNow certifications are a great motivation to learn, but “Number of certifications” must not be the only KPI to chase. If your company pays for them, great! Do as many as you can! Will you become an expert? Definitely not. But you’ll get a high-level overview and be exposed to how different ServiceNow modules are built (I only learnt about state flows when preparing for the Field Services Management certification). You might even realise you are not interested at all in certain areas (You won’t find me working in a Discovery implementation unless that’s the only solution to save humanity during an alien invasion).
- Job titles are weird. Everybody has a common idea of what “Certified” means. “Technical” can mean different things depending on who you ask. And “Architect”? There are probably more definitions than actual architects in the ServiceNow ecosystem.
- Do NOT burn bridges! ServiceNow is huge now, but it has a tight community. Have you heard about the 6 degrees of separation? In ServiceNow, it’s probably not more than 3 steps.
- Underpromise → Overdeliver. You are not doing anybody a favour by telling them you can do something in an hour and have nothing to show after one week.
I promised you 11 lessons, but I’m going to apply the last one and give you an extra one:
“Sharing is caring” has burned in my brain since my early days in Aspediens. Write often (it doesn’t have to be perfect), share your knowledge (even if it’s just with the person sitting next to you), and don’t assume what you know is obvious or useless. If you’re starting your ServiceNow journey, your current struggles will resonate more with other beginners than what I’ve written in this post.
