Duke today. We're talking to a very special guest. The one and only Chris Nanda. Hey, Chris.
guys. How's it going today?
Pretty good, man. Pretty good. I'm so glad to have you here. For those who don't know, Chris is an OG amongst ServiceNow OGs.
Yeah, it's been about 15 years now.
And, just to give you an idea of what that means. Chris built an app for ServiceNow and sold it before there was a ServiceNow store.
Very true. A couple of apps, actually.
One was the, Flexera integration. Was it?
Well, I did the Flexera integration on behalf of Flexera, but I actually had two of my own apps before ServiceNow did, and now ServiceNow has them again. one of them was automated software deployment through SCCM, now aka CSD, our client software distribution. And then, they came out with event management right after I built it, which using, system center operations manager.
Nice. all of those are, are, huge Microsoft word. So would it be safe to say that you got a huge, it background too?
Ah, you know, it's necessarily less IT and more. I just did a lot of C sharp and NET development before I got into ServiceNow. And so, I kind of graduated into that area. Ultimately, what took me down that road was actually just customers. talking to different customers, doing implementations for about a year and a half at that point. So, I kept getting asked for the same integrations over and over again.
And I'm like, well, why am I going to go build this and charge them all of the hours and whatnot when I could just maintain something and sell it and everybody kind of wins there because I can resell the same thing, sell it for cheaper. Honestly, the first time I sold it, we signed the contract and they told me, ha ha, thanks, Chris. We would have paid double for this.
Oh man. Well, that's, you know what though? that is absolutely great feedback, right? Like I'm telling you, they would have paid you double for it, right? It's like them paying you double because now, you know, when going to the next person, you can increase the price,
That's exactly what we did.
boom, free market feedback, take that first client,
Exactly.
what was your first contact with ServiceNow?
so I was graduating from AIT in the National, or the Army. I was in the National Guard, so part time. And I started putting my resume out there, and one of them was this company called Fruition Partners. some people may have heard of them. they were only about seven people at the time, so they were not large at all. So And I get an interview, this guy on the phone, Mark Toluto, says, Hey, Chris, would you like to be a JavaScript developer?
This is 2009. I'd been doing web development for a number of years. I laughed at it. Not like, condescendingly laugh, but just, I laughed because JavaScript was a second rate language when it comes down to it. I've done C sharp, Java, C some PHP, unfortunately. and so I just kind of laughed at that, but then I heard him out and heard about the platform, did my research, read about what ServiceNow was using under the hood a little bit, and I just started to like it more and more.
And so I, I took the opportunity and that was it. I was employee, well, technically I was a contractor, but employee number eight at fruition partners, I think eight or nine. and now I think technically it's DXC.
Yeah, there was like two different transitions there. I went from a fruition partners to CSC and then CSC was acquired by DXC. I think.
Yeah, it sounds about right. Yeah, so, um, I started off just doing implementations for about a year. had no IT background, actually, just development. Before that, I was building, like I said, PHP websites and things like that. And here's the thing. When it comes down to process, I am not a process focused person, but I can do process, because when it comes down to it, what is a process? It's a logical structure. It's a logical progression of steps.
And so that's what computer scientists and software engineers do. And so I was able to pick that up fairly well. And so doing implementations and whatnot like that, I just kind of fell into integrations because of the fact that I loved working with different systems. And so, Corey, you know, mentioning how I got into the,
I
of these different things. And at that time, SCCM didn't have a PowerShell SDK service. Now couldn't run PowerShell very easily. Even back then it was called run book automation.
Oh, those were the days.
Yeah. Yeah.
a
absolutely. Oh man. That's, way back.
Oh yeah.
Yeah. I remember like fighting with my management to get run book automation. finally got it and then automated our onboarding and that was pretty kick ass.
Oh, man. I was like, I couldn't, I had so many fights with that because we literally had a team of people that they pulled in. To do all of our AD management for a global company. And they just sat, they stacked these people five deep in a room and all they were doing were copying and pasting accounts out of emails and I'm like, they got this thing called run book automation and service now. And they're like, nah,. We got it all worked out. I'm like, yes, but it's crazy what you're doing.
Never won that one. I blame myself, but.
Um,
yeah. You know, it's funny though, right? Like I think,, the greed switch automation was discounted, 15 years ago versus now, like, is immense. And, and then not just from the business too, I, remember. when folks are like, oh, we're going to script this script, it like you can't rely on the script, right? Like, and this is from like folks in it, like, no, you got to do this manually, And now everything's done via code essentially, right? Like, you
Exactly.
Microsoft's entire management system is all based on PowerShell.
Absolutely.
you create a mailbox from exchange admin out, whatever the equivalent is now, I don't know, but you right click, and hit, create mailbox or whatever, but there's underlying PowerShell that it runs to do that action. And then it prints it out in the console, so you can see it, it's basically advertising to you that this is no longer like right click operations. It's like, you're just, using the GUI to craft the script.
Uh,
ever did. And even to this day, ServiceNow does the exact same thing with all of the different flow actions and workflow. You know, if you go back to orchestration or run book automation. It's the same type of thing where they're just passing a script to a power, the PowerShell executable. In this case, if you're running PowerShell and off to the races and you might get an error. You might not, you might get something back. They've made some really cool wrappers around the scripts that they run.
I have to admit. The team at ServiceNow that worked on that PowerShell implementation did a fairly good job of building out how they're going to execute PowerShell from a Java library. Because, you can't just go and execute PowerShell from a Java application, right? So they actually have executable, the PowerShell. exe, and pass the script in the command line.
We've got to put a deep water sign up here. Just 1 second.
Yeah, that's fair. That's fair. Back up. Back up top. Um, but automation, automation has been the low hanging fruit though. 10, 15 years ago, everybody wanted to talk about onboarding and offboarding. Right. And it's funny because I still see the same discussions, but not a lot of movement.
Isn't it crazy?
right. A lot of the customers that are using service now that have been on service now for even eight or nine years, They may even have licensing for some of these things, and they haven't implemented them for one reason or another. Maybe we'll get into that.
I wouldn't be careful where we placed kind of the blame for that because I
No, no, no.
to go around everywhere. Like, My first mega project, once we deployed ITIL in like three weeks, um, back in the day was, I mean, we're literally too scared because we planned months for this, but we're done in weeks and what are we going to do to save our jobs? And we had this person who, is the kind of guy that, The company just locks him in a room to solve a problem. And so they basically sent this dude away, like figure out our global onboarding and offboarding.
He came back a month later with piles of Excel sheets.
Heh heh heh.
a lot, a lot, a lot of work that needs to be done way beforehand, if you want to tackle it as a big thing, meaning like one big overarching onboarding request. Yeah.
problem with it, though, is you're 100 percent right there, except the technology is there. We have it in front of us in order to streamline the technology side of it. and realistically, and what you're kind of, it seems you're alluding to is the process side of it is really the hard part. And it really still amazes me that more companies aren't focusing on, all right, let's focus on that process side, or resolving the technology side.
Even ServiceNow, they give us flows and flow actions and all of these things, but they're all partial solutions.
Oh, I just straight up murdered somebody for a decision table back in the day. Like,
so the thing about process though, right? Is their process is inherently, people centric. Right. And, what do you do when you get like a bunch of, of it folks together in a room, right? It's not always people centric. And especially, right. Especially when the difference in it knowledge, when there's a notable, difference and it knowledge, right.
you're going to have like the it folks talking in one language, you're gonna have the business folks talking in another language, there's going to be a big old wall of communication barrier in the middle. Right. And so processes don't get built because processes don't get communicated.
that is 100 percent right, and that actually kind of takes us into something we were thinking about talking about. you need a good architect when it comes down to these implementations, because an architect in that room be able to walk in and listen to the folks, the folks who are very technology centric.
And listen to the business folks and bridge that gap with communications, understanding, all right, business, you would like to be able to ensure that you start off here and you end up here, technology. That means, ultimately, they need to do this, this, this and this, go do it. And this is what needs to be done. and being able to communicate that to both teams, being able to then continue to communicate that and ensure that everyone is on the same page. That way.
All of that process goes and gets completed properly. Otherwise, and I've sat in rooms and seen this. The business side is sitting there telling the IT side, Well, we want this. Oh, well, you want XYZ, is how the IT team responds.
Mm
the business is like, Mmm, no, no, that's nowhere near what we are saying.
or the it gives them exactly what they asked for, even though it was not the best idea. It was just the only way. They knew how to do it and just everybody take a shot. Cause I'll break out the Amish metaphor again, if I have to, but, but sometimes they just don't know how to ask it because they don't have the visibility into the, like all the things that are available, you know what I mean? They're not, their job isn't service. Now builders. So, um,
right. And, and I'm about to give you guys something that, that I was about to put in, in a video of my own. So I'll, forego that and, just say it here. One of the key things that I've noticed about our ecosystem here is that with architects, the ServiceNow ecosystem has redefined the term architect in a number of different ways. And I'm not going to get into the good and bad and all that. The main point I want to get into is understanding.
And so making sure that our public, that people who are getting into our ecosystem know that What to expect when they hear the term architect and that it's going to be different Depending on the scenario that you're in Because there's two key things here and a lot of the military folks out there that I talked to because I worked with some of the next gen candidates that Are coming from the military side.
They seem to understand really well Is that you have a project role or your responsibilities that you do? And then you also have your pay grade and You In today's world, in ServiceNow, we've gotten this idea that I graduate or I level up from, senior technical consultant to be an architect. And now I'm an architect and I do something completely different. Well, that's your pay grade, realistically. It's something to make sure that you can get paid more, right?
Yep.
And, but, that doesn't mean that you can do, the role of an architect, necessarily, to be perfectly frank. you might just be a really good developer, or a really good senior TC, and that's okay. Because it's just a different path and that's the key thing that, one of the worst parts that I've seen is that TCs or senior technical consultants, consultant or senior developer seems to feel they need to graduate to this architectural now. And that's not the truth.
It's, it's almost like back in the day where they assumed that an engineer needed to graduate to become a manager and not do their development stuff anymore and do something completely different. That's not the case. And so, may be your pay grade as an architect. But your role is going to be defined by what you actually present on a particular project. And that's the key thing.
And there's some programs out there that we're, you know, we're not going to really get into here, that focus on this difference. And ultimately, an architect is there as we were kind of starting out here talking about to communicate and ensure that everyone is on the same page and look at everything that's going on in the project and in the infrastructure.
And. In a holistic way, so that way they can see, all right, how is this all going to work together and we ensure that your piece over here is being built to a scalable way, and it's going to work properly with this piece over here and bring them together them as the project comes and comes back together as you're about to go live or, or move on from there. And. It's just a key thing that they're two different things. And the problem is we merge them all in the, in today's world.
So, Hey recruiter, I'm looking for an architect. Okay. Well, I'm an architect. I've been in the ecosystem for 10 years. Uh, what have you worked on? ITSM.
Yeah, so Chris, this is one of my hobbies, right? So a lot of organizational culture, that you're touching on here. There's a lot of, management theory that you touched on, right? Is that the whole Peter principle has been popularized and, social media circles or whatever. But, the fact that people often get promoted to their level of incompetence, right? That separation of, pay.
From title is key to ensure that you're rewarding people for what they're good at and not merely promoting them to a level at which they're no longer good, but you felt like you had no choice, right? Because they were really good at the place where, you know, where you noticed them. Right. And so I, right. And I just think there's this, you know, as a culture, we haven't set this difference, right? Like between, where you want to,
Silence. Silence.
difference between where you want to, we're, rewarding folks versus like where they sit in the, organizational hierarchy.
Silence.
think there's, it's hard, right? The market's super, super efficient, but also dumb in the sense that it doesn't, handle complex things at scale.
Yeah.
So if you want an idea to take off, it can't be like under these circumstances. No, no, there's no butts. There's no different pathways. It's like only the simple ideas scale, Only the simple ideas scale. So there must be only one path to her advancement. Otherwise. The mark's not gonna understand.
maybe, software architecture isn't supposed to scale. Right. and maybe that's the problem is that we're trying to scale a principle that doesn't. Right. It's complicated. Being a ServiceNow architect, if you do it well, it's complicated. You need to be able to walk into a room. With a room that's not a service now. With any type of stakeholder
Hey,
right. Get everybody on the same page. Your Amish metaphor Duke, like,
Oh,
or no, no, this is the band. This is the band metaphor.
the marching band. Well,
you gotta be, go ahead, go ahead.
no, no, you go ahead. You're, you're, you're on fire. They're about to go pretty
No, but you got to be able to go into the room, right? And you got to get all these folks who got different instruments, you know, get them all playing together. So that instead of having chaos, you've got a symphony. And, that is a rare, uh, thing to do. Right. It requires a lot of different attributes in a person.
And it isn't a skillset that scales, I'll tell you like, as an independent contractor, as somebody who's been doing service now for a long time, if you put me on a development contract, right. Like I could scale that, like nobody's business. But if you put me on things where I'm using like my actual consulting, My actual architect, traits and things of that nature. I, yeah, I can't. Because those things take time. they take a lot more, engagement, right.
A lot more mental capacity and it, it wears you out. And it's just not something that you can do say for projects of software of service. Now architecture consulting at once, right. You just won't be able to turn that around,
Okay, I got let me play devil advocate for a second devil's advocate for a second. so, based off of what you guys have said so far, what would you say differentiate different? Um, what would you
that,
say differentiates an architect from an engagement man. When it comes to like, synchronizing people's voices and objectives and all that kind of stuff, what would, what differentiates the architect from the engagement man?
Chris, you're the guest. I'll let you take the crack first unless you want me to go.
Go right ahead first. Okay.
All right. for me, an engagement manager as a person can come into that room and facilitate conversations, right? And take notes. it's going to be like, I'm going to make you feel good. As my customer, I'm going to talk to you about the things that I know as organizationally we can deliver. I'm going to take very good notes about stuff that I may or may not understand. And then I'm going to bring that back to the team and find the person on the team with the skill set.
You know, that can help, facilitate this and that may, and some of those notes may be technical. Some of those notes may be organizational. And so you may be talking to 2 or 3, 1 or 2, 3, 4 people on the team, right? To actually accomplished, you know, the things that you've, heard from your client, but I think, engagement is really the key word in the title, right? Like you're engaging with the client to understand their problems, right?
You're going to take those, uh, you're going to come, uh, you're going to document those takeaways, right? And then you're going to go back to your organization to figure out how we can fix them.
I would completely agree with that. Really what it comes down to the best engagement managers, the best architects, the best consultants that I've ever seen oftentimes have a fairly common set of, proficiencies. And so an engagement manager, as a person, some of the best, would have a lot of the same skill set that, not all, but a lot, as the architect. Except the goals are different. That's the key thing.
And so when an engagement manager walks in the room, as Corey was saying, they're going to sit down and be like, alright,
little
there? And what's our plan? And how are we going to plan this out in a,
on
almost of, all right, we're going to do this at this time. How are we going to do this then this after that planning out events, planning out each of the phases, the milestones they're that balance between, an architect and a project manager, like they're not a PM, they're an EM. So they're kind of an architect's engagement manager, right?
I would say you could have people that don't share the skill sets at all be successful. Like, for me, the engagement manager is the person whose head is going to roll. If the thing fails. they're ultimately responsible for the success of the thing from the delivery side,
Uh, you know, I.
versus the architect is you can establish something that is architected And built exquisitely, but still not,
was
succeed well enough, because it's more than just, the design of the solution? It's did we train people? Did we document it well enough? Did we do it in time? Did we bother reporting on the outcomes? Which can all stand outside of the architecture of the solution.
This is actually an interesting conversation because it also talks a little bit about scalability of a team. I outlined this for a previous organization that I was at because sometimes you'll have a project that is so small that you're not going to have an EM or a TC and you're just going to be everything.
Yep.
And
people that have to do that, right? We're pragmatists here.
well, it's interesting because I would say just from my experience and what I've seen. really good architect ultimately can act as architect, EM, TC, and developer, whatever roles basically you need on a project. They can, they usually don't like to, but they can. And what then happens is. Is things start to break out from there.
So you'll usually after that end up getting an engagement manager and an architect, and then that EM breaks off and starts taking over some of those project related roles. Like you were mentioning, Rob, and the key thing there is though that I've found, you know, you can have a successful EM without being a good EM in this particular scenario. And that's, an interesting, setup because you're not at scale at that point. you're, it's just an architect and an EM.
And so, since the architect is used to doing all of these roles oftentimes, they'll pick up whatever the EM's not doing. Thank you. So the EM could just be a focus on, hey, where are we going, what are we doing, reporting where we're at, etc, etc. And the project could go swimmingly.
Hmm.
The problem comes in then, is when you scale that up, that EM is going to start to fail.
Okay.
for certain things to just be done, like the documentation you were mentioning. Often, I see that that's actually expected from the architect. Now, not the actual documentation, but the planning of that, the rollout of how are we going to document, where is that going to be? A lot of the engagement managers that I've met with and that I've worked with just kind of assume that the architect is going to take on all of that role. And so, It's interesting.
And that's why I was kind of starting out with a good EM versus a successful EM, because I think those are two different things, technically.
Yeah, I, you know, I liked it. Yeah, I like distinguishing between, a good EM and a successful EM. Right. Okay. Because.
saying that there can be successful EMS that are not good EMS?
Absolutely.
Yeah. think you could be successful without being good at your job in a lot, a lot of different places in this ecosystem.
Absolutely.
You guys are
I mean,
to walk that back for me and explain it to me like I'm five.
so when I show up on a project, And I'm not the first line, right? So somebody's already implemented service now. And I come in and they started telling me about this, you know, person who helped them, build out their system and blah, blah, blah, blah. And they're super happy with them. And they wish, they just really wish that person was available now to come back and do this thing, but they had too many projects and so they weren't available. And so that's why I'm here.
And then, you know, I'm like, okay, so that person was very successful and, phase one, then I get into the instance. Right. And there are no best practices followed, from a development perspective, right? there's custom apps built that, duplicate, internal functionality, all things like that person was not a good, you know, resource, right. But they were successful in that their customer was happy, right. And their customer would love to have them back.
But you know, when it comes to me, having to work on top of what they did, no, they weren't good. That's how I look at it.
How many projects are we seeing now that have this back to what are they calling it now back to baseline back to, out of the box? Implementations because of how the implementations were originally done. But looking back on those, do you feel that a lot of those felt they were successful at the time? And so I think that's, exactly, and, and that's kind of
like I'm not sure like I've been on both sides that fight. I've come in the middle where things are being deployed and I was like sounding the alarm. Um, And I've been the person that cleans it up. but I, get the sense that customers don't come up that thinking like, yes, that was awesome. And then get to a point a few years later where it's, oh, no, that was not awesome. It's such a big problem. We have to greenfield. I think the best that they end up with.
At the start is, Oh, we went with the devil that we knew, or we picked the lesser of two evils, or our back was against the wall. We had to do it this way. then it's just kind of like, well, we're suffering with the consequences in the short term. And then that pain just grows and grows and grows in the long term.
I, I, I've seen those, absolutely. No, I've seen those. Absolutely. But I just I don't think that's that's all of them. Or maybe even most of them necessarily. I've seen a number of them that that they walked out with. So they got what they asked for. And I think. Maybe we need to go back to what is success.
Oh yeah, for sure. Getting what you asked for is not, that's a huge gray area.
so feeling like you're successful, it may be different than being successful and I think that's the other thing in the ecosystem like, so if the client feels like they're successful at the outset, or if the implementer feels like they're successful.
Yeah. I don't really care what the implementer feels.
Well,
Like, I don't.
off by the engagement manager, right? So the EM, the EM is going to be the implementer. So it's how they feel if they are successful or not. Right? that's really where I'm going, trying to circle back to here is ultimately success, I think is probably too variable or too subjective for us to say, is someone successful or not? Because someone's gauge of success. Is going to be variable in this case.
but ultimately we have best practices now, especially so we can gauge what is good and not necessarily what is bad, but just what is not good.
Yeah,
sense. Silence.
no, it does to me and I think also what we have to are the stories that we tell ourselves. When you make a decision as a business, right? You make several, decision points that come into this, right? Like, yeah, costs, right? You thinking about availability, you think about, whatever else, right? And those things, require like some trade offs. And I think sometimes, businesses land on some optimal decisions, For a number of different reasons.
And then the outcomes that they get, they tell themselves a story about it, right? To make them feel better, make themselves feel better. Right? And so if I went in here knowing that I wanted a kick, but service now implementation, but I only had budget for. a guy fresh out of high school, I'm going to write this narrative that what I got was amazing no matter what. Right. Because, I, I got what I could afford essentially. Right. And so some, right.
And so some organizations will, tell this or someone will be, just like, yeah, no, this was a bad idea. I shouldn't have actually done this. we should have just kept Excel, right. Because it wasn't worth getting this platform and then, mangling it. And now it's. Like unusable, but we got to use it because we bought it sort of thing. I guess the point I, it was that I was just basically co signing what you just said, Chris, about it all being like success, sometimes being subjective.
Absolutely. that was an interesting roundabout.
that was good and it got us to 34 minutes of record, so
You know, it's so funny, right? Sitting out here had no idea what we're really going to talk about. We were like, yeah, Chris, we're going to ask you like how you got started and we're going to go from there. Right.
that's just how we do it here, man. That's our shtick.
That is our stick
Well, and
way away from how you started. It's so awesome.
well, you know, and feel free to cut this next part out, but just so you're aware and you got some information of where some of what I was saying was coming from. So when it comes down to it, I was working with an organization recently that focused on state implementations. And they had a particular set of project managers who had. done project management for other implementations, never on service now. And the general idea was a good project manager can implement anything.
I don't necessarily disagree if all you're going to be is a note taker and whatnot. But my problem is, I don't think that that's what a good project manager is. A good project manager is a facilitator and they go a little bit farther. And I think that's, one of the key problems when, We're walking into these engagements, a project manager or an engagement manager is going to say, all right, who is going to be our scrum master? Is it me? Is it the architect?
Is it someone else, who is going to fill these roles? So that way we ensure that the project as a whole moves forward versus just assuming, all right, well, architect, what, what are we doing? I can't tell you how many projects I've walked into where we meet and the EM just starts it off with saying, all right, what are we doing? And they have no, no plan at that point as it's starting. And so
Silence.
come in and the best engagement managers that I've ever found have a lot of the same skillset, even some of the technical skills, honestly, the absolute best engagement managers I've ever had, I've been able to give work to. They've actually come in and, facilitated the project, but I've also been able to say, Hey, can you go build out this SLA workflow now, this was years ago, right? and they, they did it.
and that person is still in our ecosystem right now and he's a buddy of mine and it was one of the worst projects I've ever been to be perfectly honest. but. as that went, he was one of the best engagement managers I ever worked with. And that's why I started off saying that I really believe that the best have a common skillset versus,
Okay.
otherwise, honestly, if you have a team, that's very different, are they really going to work that well together?
It's
How different is the assembly line worker at a Tesla factory from the marketing team? they can't inter swap because their necessary core skills are so different and they don't
do they work day to
they don't do the same job.
but do they work day to day together? That's not a team I would say.
possibly there could be somebody from manufacturing, from design, you know what I mean? Like, well, let's say, let's take two other roles where they have very close proximity, like a developer and a PM. the project doesn't get any better because the PM is a merely adequate service.
Now, admin, like, every minute the PM spends outside of managing cost, schedule, scope and risk is a minute wasted versus the developer taking time out to manage cost, schedule, scope, risk instead of write code, assess code. Like, those 2 domains don't overlap.
my point is not necessarily that they have to do the job, but understanding the job. Actually, your first example is actually a pretty good example, I think, because in my case, because. Look at the assembly line worker, the person who's putting something together on the assembly line versus marketing. In truth, those two people are probably going to have very little in common, very little contact.
I would not say that they were really a team, but as you go up in the level, as you go up in the role there, now you've got the assembly line manager who may have to manage a little bit about how successful his assembly line is. Or how is that actually marketed and talk to about to other people? They may actually have that interaction with marketing. And so because they're their skill set or in theory their skill set, but because they're their goals at that point, their focus.
Aligns with that of what marketing is also doing. They slowly move together and they have more in common. And so that's really what I'm talking about here as a team. If, you have a PM who has no experience with service now with the platform itself, no understanding of what's going to happen or how things are supposed to be done versus someone who has some of that baseline administration or implementation skills.
and being able to talk to a customer and to their development team in that particular way. just, from my experience, you're going to have a far better project and far more cohesiveness in that team with the team that understands everything together.
Well, Chris, I just wanna say this has been an amazing conversation. uh, you know, I totally did not know what to expect. You know, always good talking to you and, uh, man, this one's, this one's been great, so definitely I appreciate you joining us on the show,
It has been great, it's a lot of what we can fill 40 minutes and not even think about it beforehand. It's just like turn on the record button and stop at 40. So thanks for that Chris.
glad to talk to you guys and Hope you guys have a great weekend.
Alright folks, thanks for watching. We'll see you on the next one.