All right. We're recording. We
weeks in a row,
and
but what are we talking about today?
do today. We're talking about how to win at service now without service. Now,
and what do we mean by without service now?
What we mean by that is there's so much stuff that happens off platform. That determines whether or not that's going to be successful, right? And not nearly enough time is paid to it and not time, effort, attention, right? Yeah,
to like my time as a ServiceNow customer, as the owner of the product, and what are the skills that allowed me to be successful versus. some of the other instances that are not as successful. And there's a laundry list of stuff that we can talk about here. So anyways, that's the episode for today.
no, no, it's not the end.
No, no, no. I mean,
start it.
what we decided to talk about.
Duke, you're right. Ultimately I was prepared, and creating service now success. Through a lot of the experience that I had in my career previous, right? And I took a lot of that experience and I applied it to the service ecosystem, but I took the experience. That wasn't so much technical, which is weird, right? Because I've always been a very technically oriented person. Right. Like I love the tech. I've always loved the tech since I was like six. I still refuse to buy a desktop off the shelf.
I build all of them myself. I got home automation kicking off, but I can't overlook that most of my ServiceNow success comes from the things that are not technical and that only slightly relate to the platform
I would agree. I didn't come up as a developer. I didn't even come up in infrastructure. I kind of Stumbled into it by accident. I used to joke around people. I'm like the least it person in it, but some might argue that I've had a modicum of success in my 15 years of, of doing service. Now consulting, I've had a couple of successes in there. and so it is beyond just your technical ability to pick it up. I guess the first step on the journey, is to demonstrate a high amount of agency.
And by agency, I mean, this problem is my problem. Also it's up to me to find the best thing to do versus it's up to me to be told what the best thing is to do.
Ooh, yeah, yeah, yeah, yeah,
low agency is like, somebody's got to tell me what to do and I'll do it. Low agency is, wait until I'm asked to provide my opinion on the best path. And if I'm not, then nobody will ever know. High agency is go out, find one or two or three solutions, and then bring it to the table with your stakeholders. Shout out to one of my former bosses, Roz Agee. I remember
so
HP OBSD admin. And.
check
You can't give me that answer. Go to your desk, think about it for 30 minutes and give me a better answer when you come back. Or, or I'd say is, you know, it could be done this way, but it's going to be like three months of work and she'd just be like, do better, Robert. Not in a mean way. Right. But she just like, she just knew that I was. Not putting my best effort into it. So she would say, go to your desk and do better.
And in an hour, come back and tell me, and inevitably I'd always think of two or three pathways. And often, the second or third one that I picked was the better option, but she taught me agency. Adopt this problem. like you have to go to my bosses and tell them what's going to go on.
It's so funny. So I'm going to go back, to magic total service. That's two for a minute. And when I took that tool over, I'd done like some windows scripting, like back in the DOS days to make my games run. That's where I was with like programming, but I took, magic over because the team that ran it wasn't given at the time that we wanted them to do as the ops team, right? Because we own the service desk. And so it was important to us that tickets work well.
And we were rolling change management and we needed that to work well too. but I never run like an app like this before done any programming or whatever. my boss's boss really said, Hey, You want to take this thing over? It looks like you got time. I was like, sure I'll do that. Right. And at the time, I'm a really techie guy. Right. And you know how techs think about tickets, right. and they're giving me the ticketing system to now go in and run. And so I, it really took.
A different mindset, right? I had to really change my mindset and start thinking about this, from a perspective of, okay, well, now you own the ticketing system. how do you make that good?
Yeah.
And so like you said, that's the first step in agency, right? I own this platform now. Now I got to figure out how do I make it work? and I know the things that I hate about it as a sysadmin or as an engineer or whatever, like, okay, so let me see if I can polish those edges, you know, and on and on. But I think to your point, Duke, I was given the thing and told to make it work. And because I love a challenge and I'm never going to fail, right. I went off and figured out how to make it work.
And, but I wasn't given instructions on that. And I wasn't given directions that there wasn't even a guide book. I don't even think we had an instruction manual, right? I don't think I had was a Yahoo group and we paid like for a week of week of time from a consultant. And it was all, you know, big out. And so I did, but what I learned from that is what we're going to talk about today, right, is that a lot of the success came from things that didn't actually take place in the system.
And it all starts with agency. That idea that nobody's going to come to save you. Nobody's going to tell you how to get it done. It's your baby. You have to take a personal almost,
Mac, can I tell you about that phrase? Nobody's coming to save you, right? Like, yeah, like, I live by it, right? And so many people who grew up where I grew up and found success also live by it, right? Because it's true, and you experience it for the truth that it is. And so, you don't have a choice. You can wait and what's gonna nothing happens, right? When it does come to nobody's come to save you. I really have internalized that and it's all about. What I need to do next then, right?
If I'm the only person that's here, then I'm the only person that can do it.
All right, beyond attitude, let's give them some solids to take with
Yeah, no doubt.
Okay, start now. Start writing down everything that you would consider a standard.
Yes.
Even if it's simple, like everybody thinks that we should have documentation for now. That can be your standard. We're going to have documentation, fill it out as you go, as you get more, but for all of you youngins in the space, if you ever get to the point where you're the owner of the instance or the customer relies more on you to give them the advice, like just start cataloging your opinions.
On things like how many times have you heard somebody say best practices, but like, well, where'd you get that from your head? Right. Or, or, or somewhere else in your anatomy that we won't talk about, Actually, like how to, how to set up architectural standards, but you got to start somewhere and it's got to be on paper. Like you can't just pull this stuff out of your elbow at a moment's notice. So you got to start writing it down.
And so just imagine again, you're the highest agency person for this instance. It success comes down to you. So you have to decide to what standard are we going to code,
Right, how are you going to run it?
And are we going to enforce that via instant scan? How are we using ATF? How are we using upgrade center? How are we moving update sets from A to B to C, and also if we have guests come in to develop for us, what are the expectations with them? Lord knows, like how many stories are there out there where we pulled in such and such a company to do something and they deployed some, updates sell that they built before and they just deployed it on our site. And it's all kinds of stuff we don't want.
Like you got to have house rules. You know what I mean?
and you got to know that you got to have house rules, Because you may not know what the house rules should be, but if you know that you need them, you can go and find them out. Right? Right. Right. Bye. You know, like our podcast is a good place to figure out house rules, but not just us. Right? LinkedIn. It's a great spot to like the service community on. LinkedIn is amazing. The service now community service now community also amazing. There's a ton of info. But unless you don't you need it.
You don't go looking for it. So this is us telling you that you need to know that you need this info before you get to the point that you need the info.
There's some really prodigiously large teams out there, but even small teams with one platform owner and three devs, there's still so much like, well, I do it this way. You do it that way. And bad stuff happens with that because there's just no governance to it. Right. Nobody said this is the way we do things consistently. Bob still likes to do legacy workflow, not flow designer. and Jane is hip with flow designer. She's doing flow designer stuff like that.
Somebody should have decided on a standard for that and integrated it with the team. It's not enough that you have the standards too. You got to communicate it out to the people that you're leading. Yeah.
And then you also got to make sure that they that are used. I got a client, we got a nice, so peace right out there around something but the things that are getting built, we got to make sure that they get built according to the S. O. P. S. that are published. Otherwise, you just got documents on the shelf, and I think that part of it is also very important, right? It's like you know, that you needed the, architectural governance, right?
The documentation S. O. P. S. You know that you need these things, Now you have to also ensure. they're being put into practice, right? And you also need to keep communicating up and down why they're important so that that buy in continues to be maintained.
The last thing you really want to happen is for folks to say, well, I don't know why we spend an extra two hours doing things this way when I can shortcut it and save 90 minutes and management nodding their heads like, yeah, why are we spending an extra two hours? Right? Like, you need to proactively get in front of them to communicate what that two hours saves you. It saves you 200 hours down the road.
Like when your instance is jacked, it is those things where you have to be a good steward of the instance too. And it's real life flesh avatar.
man, I tell you what, I got a brand new metaphor For the whole idea where the customer says, don't have time for your stuff. Like, you have to get this app out for us, or, or you have to fix this app. But meanwhile, the house is burning down around you. Right? I've been on jobs where you come in and we want to deploy SPM. We want to do this. We want to do that. But you get there. It's just like, no, no, we got to put out all the fires first.
You can't even begin to think about something else to deploy right now because, okay, so here's the metaphor and aircraft carrier aircraft carrier. Right. No
any Amish on aircraft
Amish on the aircraft carrier.
All right.
Shout out to my Amish metaphor, which I do every five episodes at least, but this metaphor is about aircraft carriers and aircraft carriers carry what super whiz bang. Like awesome jet fighter technology, right? We can force project anywhere we want in the world. We can just impose our political influence wherever we want. Cause we got the jets. And those jets are phenomenal pieces of technology.
And they do their job extremely well, but if there's something wrong with the aircraft carrier, everybody's day is ruined. It's not this fighter jet here. Isn't going to be able to do his job. All fighter jets on that aircraft carrier can't do their job. And our political influence is gone out the window. And so if I was ever back in the saddle, heading up an instance that's the first thing I would do at a council is.
talk about the aircraft carrier metaphor, we have to keep the aircraft carrier in absolutely peak performance so that the fighter jets can do their job.
Absolutely. And to take that and extend it into real life. if your instance is not working, then your users can't use it, And if your users aren't using it, then, you got a whole lot of other problems, right? including shadow it and things that are being captured in Excel that you never know about and never get the access, right? So, maintain the instance, make sure that it works well, so that your jets, your users, right? Can utilize it to get their job done.
I think linking it to something physical like that will show your stakeholders, how there is energy that must be put into that thing.
Absolutely.
carriers need fuel, which needs to be replenished. They need repairs. They need standard maintenance. A lot of it, so it's priming them to justify that there is time and energy that must be spent making sure this ship goes good. Shout out to all my Navy friends out there.
Absolutely. All right.
well, I mean, but that kind of leads in that takes us right down the path into the stakeholder council, right? Who am I going to convince? The stakeholders.
You have to convince the stakeholders, right? Or they need to convince you, right? Like the whole idea of it, Is that we, you've got people who know how the business works and they get to give you feedback on how the instance should work in the best way for the, the business.
Like, do you think a customer does that though? Like a, like a stakeholder, do
Do I think that they represent the business or do
they tell you anything about the platform?
yes, if you listen closely enough, do they tell me technical things about the platform? No. Do they tell me important things about the platform? Yes., my team doesn't use ServiceNow. Why doesn't your team use ServiceNow? Well, because we find that it's too slow. Okay, what's slow about it? Well, they just, it's just slow. Right. And so you get that treatment and sometimes that's not necessarily helpful, but if you listen really closely, you'll say, well, it just doesn't work for our process.
What's your process? we do ABC and then you go into ServiceNow and you realize it's built for ABQ. And you try to figure out, so how do we build for ABQ when you do ABC? And then the stakeholder says, well, nobody ever asked me.. and so how many people, do you know, in tech who actually understand the roles of all the folks business, right? Not a whole lot, but often they build things for those roles, for those people in the business without consulting them.
So sometimes you hear this is slow and then sometimes you hear this doesn't work for me and you don't necessarily know why and they don't know why until you really listen carefully and then you figure out, well, nobody actually asked them how they work. And so what we deliver to them is what we thought they need it and turns out they don't They need something different. And then we insist it. That we built it correctly, right? Because now we're defensive.
We spent three months building this thing out for this team, and they don't want to use it. And we're like, well, this is how you all work, right? Like this is what, and nobody ever asked them. We all just spent time telling them, well, you need to conform to the tool. Well, they won't. Right. Let's be real. And look, I don't know. I feel like this thing is something that folks need to hear. They will not conform to your mal implemented processes. And that's what I mean.
The things that are off platform. That help your service down implementation, right? They won't, they just won't use it.
Are you talking about platform stuff? Are you talking about Oh, we deployed XYZ process badly.
I'm yes, both though Duke, right? Like if it's SPM process, and we deployed that and the PMO, it's looking at this thing. Like, we don't work this way. And we said, well, this is the way the system is set up. You got to use it this way. And they're like, well, we don't work this way. It doesn't work for us. I want to say, well, we can't do anything about it. Do you think that they're still using it? They're not using it right.
Like they're going to spin up a company card and go buy whatever third party shadow it software and their team is now using that but you've won the argument and you've told them, this is the way that it works. But you didn't actually win the users, right? Because they're not on the platform. That's what I mean about it. you've got to make sure that you're listening to the feedback and that you are convincing and getting buy in instead of dictating and telling.
I would loop that around. There is a necessity for listening. And I think that's where a lot of people find that they. start naturally like, Oh, we're going to tell you how, what we need out of this thing. And your job is to listen, but you also need to like circle back and take leadership of it and guide your stakeholders to the goals, right? And we did a whole episode on this as well. This will be in the description below. Leading a stakeholder council.
Yes. Right. Leading.
and if there's one thing this will do for you, which saved my hide so many times, boil it all down to this. It shows them that it's not. You versus them. When it comes to when is this thing going to get done? how come this hasn't got a lot of, it's not you versus them. It's them versus everybody else in the business that wants something.
that's important,
Yeah. Yeah.
Because it allow them to weaponize their political capital to get priority. If that is the will of the business,
We've all been there, right? The business is saying we need encryption on this table that could possibly contain PII, right? You got the business telling you that, but then you got somebody else who's like, the 15th customization to this report this week.
right?
It's not until like your stakeholders see each other and realize what's going on, that they get the idea that like, okay, there's a prioritization that must happen amongst peers.
Yeah, there's a road map and look, the road map can change. But we all got to agree that the road map needs to change. Often. What happens is, you know, comes a black box, right? And everyone thinks that is dictated in the road map. And sometimes is dictating the road map absent business input. And that's what this Dakota Council does. It gives you the business input to the road map, and it gives you the transparency to so that everybody's on the same page about the road map. Right?
So decisions need to be made. They can be made. With the full buy in and support of everyone in the room, instead of being dictated by it, who typically has the least amount of political power in any of these conversations.
Yeah. All right. You got anything else?
Cross pollination Duke, right? There's always something somewhere else that can help you be successful, creative, or innovative. In the vertical that you're in all the service now, right? Service doesn't exist in a vacuum, your business doesn't exist in the back room in a vacuum. So you should constantly be learning, not just about the technical aspects of the platform, not just about how it does things, but how everybody else is doing things and then find those things that can translate.
And bring them in when you start crossing ideas together, then that's when you start to get some magic. Right? And a lot of the things that I've been able to give my clients value from are things that wouldn't necessarily be out of the box technical.
Like we start talking about processes and then I start, going down the rabbit hole with them on things around like organizational change management and organizational, psychology and how, the processes that they've built aren't necessarily aligning with how people tend to think. And what is the culture of your organization? Is this a meeting culture? Is this a culture where people come into the office? Is everyone remote? Did you design your processes in the system to account for those things?
So when you start getting into just the other skills and talents and knowledge that you have in different subject areas and bringing them into the service now discussion, right? Allows you to accelerate and elevate what you can do for your clients. That makes sense. Duke and my own face on this.
Yeah. I think a specific one, which is going to be the category I was going to go to next anyway. Is learn how to manage work, manage it, not, not do it. You got to do the work too. A lot of cases, but learning how to manage it is what's really going to take it to the next level. And there's teams that are under managed. And I would say that shows up in nobody seems to be working on the most important thing.
Nobody knows what's going when, and then there's overmanaged where you're micromanaged to the point where we still don't know any of that stuff because we're too busy answering every other of the hundred questions today. Yeah.
and we need to dive in on that. nobody knows what's the most important thing and nobody knows what's going when right? you and I have had some really good conversations about that. Offline about some of the stuff that you've built around performance analytics and S. L. A. S. And how it's just a lot more, prescriptive, right? Because you know how to manage work. And so you're helping them manage to work through the things that you built.
My point is, is that, yeah, I think that's a good episode for, for the
Well, let's get real specific on a couple of things I would say you have to understand where your work comes from and you can't plan a hundred percent. You can't even plan 75%. A lot of your stuff is going to come in as incidents and let's just assume that most of them are legit incidents. These are failures. We didn't anticipate. It's just work. We didn't know about that is now present. And that is always going to follow you. And it's going to be a large portion of your work.
So some of your work is going to be just getting incidents done, but some of your work is going to be requests. And you can't just go into like strictly request delivery mode, like someone asked therefore do otherwise you're going to jeopardize what you've built with your stakeholders, right? With this roadmap, whatever you want to call it, this plan.
Right.
Whether you use the SPM module or not, you really got to think about demand management. How do we. Even contend with the stuff that has been asked for, let alone the stuff we're going to do, right?
Well, yeah, right? Like, and that doesn't that like loop back around to stakeholder council?
it does, but the stakeholder council is what I think is like the strategic layer versus this is the very tactical layer, we are in the trenches every day. What do we get done? Versus with the stakeholder council. those are gonna be VPs and AVPs and we don't want to bug them about, Hey, which of these two requests should we be doing? No, this is the tactical level, like day to day. What are we doing? and it goes back to the standards.
But you really have to have a governance about how the work gets through a demand process. Simple as it is. Again, it doesn't have to be ServiceNow SBM. It just has to be some mechanism and an ever improving mechanism about we have this new stuff. What do we do with it?
Absolutely.
You could take your Waterfall stuff, your Agilus. I don't care what work paradigm that you use. You just have to have an intake process, and there's a governance process that decides yay, nay, how big and when, and then going back to your stakeholder council and you're communicating with your stakeholders and stuff, you've got to socialize that,? It's not my fault. The thing I asked for just happens to be the smallest thing on the dinner plate. Right. But it helps me a lot.
If you say, listen, we're robbing Peter to pay Paul this week and, and, and you're Peter.
sorry.
get to be Paul.
I 100 percent agree. I can't see the Trello card, dude. I don't know if you ever saved that.
I never did.
Oh, okay.
There's something else you got to do. Save the Trello cards. Or at least document your stuff, right? That's another thing. Have a mindset of you're building this for somebody else. Eventually, right? Be high agency. This is my thing. I'm accountable for it But you're only accountable for it for a little bit and then somebody else will take it over someday and don't
that's a good point.
Don't, you know, don't make them miserable because you weren't a good steward of the stuff. Maybe you had good build, but you hit Lotto, you GTFO and somebody else is going to have to come in and learn it. How long is it going to take for them to learn it? If you've been a good steward, which includes documentation, memorialization, maybe it could take them days,
Yeah,
a couple of weeks. I've been to places for months where surprise, there's this other thing that inhibits you from delivering that thing we told you to build. And that's months after I got there!
It's not only just for future people, though. I think that's a very, big part. It's also a future you, I mean, I can't describe the number of times that. I've built something, gone off to do something else, right. Got an enhancement request for the theme that I built come back and look at this thing. Like I've never seen it before in my life. Right. And the whole documentation thing, you want to do that. You want to do it for your client. You want to do it for the instance, right?
You want to do it for, the people who will succeed you at some point in the future, but you also want to do it for yourself too. Right. So that when you're doing that task switching, like you can incur less penalty for it. And, nowadays, like documentation is so much easier than it's ever been. Right. Right? So there's literally no excuse not to do it.
Yeah, man, like, cross train with our AI episodes. I'm still waiting for a team that just, run my update sets through the AI and just have it document. Not just the objects that it built, but see what it does about the intent, why did we add these priorities and these categories or whatever, these business rules, these flows?
I'd love to have an AI that just interprets that, and then it gives me at least a starting point of a documentation that I can, you know, it takes a little bit of the sting out of the work.
Absolutely, and I've gotten a little bit of that, out of chat GPT, not the intent part of it, not as much, but definitely the overarching, this is where you're doing kind of thing. And these are the specifics of what you did doesn't necessarily get all the way to the intent. You know, it gives you a good framework where you're not having to type 3 pages. Now you only type in maybe three paragraphs. So that's always helpful for me. Um, The last thing I say is just, yeah, just 1 more. Right?
And that's just user feedback. Take it seriously you've deployed the thing. The thing is out there. You should be talking to the people using it. And understanding how they use it and understanding the places where they're not use it. They don't think that they're using it well, or they think it could be better or the places where they think you did great, right? Because you can learn from both.
Yeah. And really go live. isn't the end.
No, no, it's just the beginning,
And is there, yeah, is there exactly, is there, is there really an end, you know, like everything you build people use and processes change, circumstances change, needs change, so you definitely can't look at an app and say, that's. Done.
right?
you just took one more step up the stairwell. And for that matter, I'll just squeeze this one in too. Take a victory lap, you know, if you deploy something that's good, like, bring that back to your stakeholder council. Advertise it within the organization that like, oh, this team is getting all kinds of wins because Blah, blah, blah, blah. Just kind of infects your stakeholders with confidence that you can deliver.
I'm glad you mentioned that Duke because I think that's incredibly important, right? Like market the heck out of the things that you're doing well, you got to control the narrative of the platform internally, right? Otherwise, somebody else will control it. Right? Like, there's a, this is a vacuum, right? There's a marketing vacuum here, right? And if, if you're not the one that's filling it up, somebody else will fill it up and they won't fill it up in a way that you will.
I've never thought about it that way, but it's so true. You know,
Yeah, right.
a vacuum, especially in marketing..
Somebody else will decide to put perception on the platform and you want to be the person doing it, right?
make them contend against you. If there is contention, right.
Yeah, but at least the, if you are being proactive about it, there's someone who wants to change the perception of the platform has to counter your already established perception.
Mm.
And that's just harder to do.
So wherever you're seeing this, go ahead and hit the reply button and tell us what you've done, as a product owner or a senior consultant that has made success a lot better. It has got nothing to do with the platform itself. We'd love to hear from you. Maybe we can get an episode out of it.
Absolutely. And, like and share and rate and all of that kind of good
All of that
say, smash
Yeah.
that like button later.
All right, folks. We'll see you on the next one.