Transcript

X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hello and welcome to Using No to Pull the Weight of Future Stress. Today, we're going to talk about having a conversation with our process owners, our stakeholders, and improving that conversation so that we feel more comfortable expressing our boundaries about using best practices, not going against them, not making upgrades harder for ourselves, and those kinds of things so that we can deliver a better product for the customer that also means less work down the road for us. My name is Dave Atwood. I am a solution architect for Cummins, Inc. We make really big, giant diesel engines if you're not familiar with us, also some really small ones. I've been in the ServiceNow space about 5 and 1/2 years. And I have been onboarding processes quite literally since day one, since I transitioned from process owner to ServiceNow developer and then continued developing that process. So I've been working on this for a while. And this is a conversation that I've been thinking about quite some time. And I've asked people in the community have you spent training on this? Do you spend any time thinking about it? And a lot of folks answer no. And the ones that don't answer it as no don't tend to have formal training or any of that. It doesn't seem to be too popular a thing out there. But I'm sure there are ways to do it. And so I spend a lot of my time thinking about how to do this better because I see my coworkers, I see partners we work with all compromising in ways that are going to make my teammates lives and myself, our lives a bit harder on the platform, maintenance, upgrades, all of that. So we can do this better and make it better for everybody. What are we going to talk about? We're going to talk about why this is important. We're going to talk about why we don't want to say no, some things we certainly shouldn't do. And the real need is shaping the conversation and learning to redirect. So why is this important? It's important because we want to deliver the best thing both for us and the customer. And being somewhat of a selfish person, I think I'm more important than they are. But I realize the outcome for them is more important in the grand scheme. So I want less maintenance. I want to make upgrades easier. I want to do them more often. But I can't do that if a customer comes in and says, I want to do this only this way or I compromise and let them do something that's not up to best practices. So I think we can make everybody happier. And it requires us to do something we don't like to do, which is express boundaries and say no. I love this quote from Henry Ford and I think it highlights the entire problem. If he had asked the customers what they wanted, they would have told me they wanted a faster horse. People don't always know what they want because they don't always know what's possible. And so if we can change the conversation, maybe we can give them something better than they expected was even possible. So, again, why are we saying no? We're saying no because as a developer, I want less maintenance. I want to protect my instance. There are best practices to consider. ServiceNow is always changing the way they do things. And staying up to best practices means I have an easier transition to whatever new thing they come out with. Sure, it didn't work with Workflow and Flow Designer, but whatever. There are lots of other cases when it does. There's value here. If you do with what they want the way they want it, you lose that opportunity to do better because the way they want it puts them in a box. And that box is hard to get out of it. So by changing the conversation and getting them out of that box, you really expand their options. The customer cares because they don't want to wait as long for the work. They want it done yesterday. So keeping out of the box, keeping to better standards means we can deliver it faster. They can have more control or feel like they have just as much control or even more because part of that is giving them choices. They have choices. You build it the way they tell you, there's no choice there. They just did a thing and you-- they demanded a thing, and you did it. There's no choice there. Choices help them regain that feeling of control. And that makes them happy in the end. They feel like they had a say in what was done, which is really important when you're moving them out of that space. Better performance-- again, standards, doing it out of the box, all of that leads to better performance. Not to say that custom code is always super performance intensive. But there's a lot of bad stuff you could do in there that is. Again, more options for future expansion of work. Getting them out of that box makes it better to add on things, easier to add on. And going back to the first line item there, shorter time to ROI because I spent less time developing something. And to the company as a whole, that really matters. It may not matter to them that much. So we need to say this more often. We need to be more expressive about it. But when we do it, we can't actually use the word no. No is a giant brick wall dropped right in front of them that they're going to run into a full speed. And that's not comfortable. So we need to make sure that we're comfortable saying it and they're comfortable receiving it. So to do that, we shape the conversation. And I like to sit down-- or rather, email-- any time anybody says, hey, Dave. We want to move something new. And I say, great. Let's have a quick, half-hour conversation about some of the basics before we get into the real meat of it. Get to know you-- that kind of stuff. And in that conversation, I want their high-level goals, because their high level goals are what they really want to achieve. It's not about the doing it the way they've always done it. It's not about the way they think they want to do it on the platform, because they've seen somebody else's process, or whatever. Focusing on goals gets them out of that rut. It gets their mind thinking of it. We'll try to do a little bit of that more later on, but getting them out of that rut to start with is important. That initial pull that gets their vehicle out of that space-- that's super important. So then, we get into some of the priorities. And I make it clear to them up front, these are what I care about. And I feel like getting that out of the way early lets us reference that time and time again during the process, which makes it easier to say, because they'll understand why I'm saying it. So protecting the instance is my number-one priority. Because if the instance runs poorly, any of those things, then I have to spend a ton of time on it. I have to ton to spend a ton of time on maintenance. I don't want to spend a ton of time on maintenance. I certainly don't want to do super basic maintenance, like adding approvers or changing them every week. So next on there-- limiting the time my team spends on it. If I can build something that hands it off to them and lets them keep approvals changing every day or every week and they can do it and don't wait on me, we're both happier. They're happier, because they have control. They don't have to wait on me. I'm happy, because I'm not wasting my team's time with super basic stuff. Delivering the best product for the customer is obviously something that has to be on here. It is what we're here for. But it's third on my list, because if I don't do number one and number two, I don't have time to do more of number three. Most people understand these things. Most people aren't going to be a jerk and run roughshod over them. Some people still do. That's the way it is, sometimes. But at least this gives us a starting point to refer back to. When you say, well, maybe I could do it that way except for a few problems, they understand what those problems would be, and they understand why you're bringing it up. The last thing on the list is maybe the most dangerous. Encourage your customer to dream. This is a great way to get them out of the rut. You get them out of focusing on the way they've always done it, or the process they built up in their mind, or whatever, and they start focusing on the high-level things they might be able to do. You ask them to dream for that pie in the sky, and they start thinking. They start really exploring what could be done. And you have to be clear, you can't do all of it. I mean, ServiceNow is a great platform, but it does have some limitations for any number of different reasons. But most people, again, understand that. And most people will be surprised at how much you can do, because they're used to other tools that aren't as flexible. Or they had a custom app built that didn't have long-term development support. So something was built, and then it was done. There was no more changes. There was no more improvement. There was no more room for any of that. And so on ServiceNow, hopefully you're able to help them with continuous improvement, and you can work on a phased approach and really expand their thinking about what's possible. So we want to do these things to set the stage, because it sets us up to be able to express that there are limitations. But when we express that, we can't say, no, because that's a brick wall. So how do we do that without actually saying no? First off, we don't want to use the word but. If I say, that sounds really good, but that also goes against best practices. They don't hear any of the first part of that. They hear, but it goes against best practices. And so find other ways. Yes and is one of my personal favorites. Maybe, perhaps-- any word that goes on there. I used the but statement until fairly recently when somebody pointed it out to me. And I was like, yeah, that's exactly what I do. And so now, I try not to use it anymore. I also like to reference my three priorities. Unfortunately, that would take longer to develop than this other option. That references the ROI piece from earlier. May cause significantly more maintenance-- that's against my number two thing I care about. Would break an out of the box process-- that's against my most important priority, which is protecting the platform. So when you say these things, people reference back to what you said. You set the stage up for you to be successful as you redirect your customer. And that's the important part-- set yourself up to be successful as you express those boundaries and those limits, and hopefully, the customer understands you better. Choices are, again, really important. People like to have that control. You can point out the maintenance short for them. I mentioned approvals earlier. In our desktop process, we do worldwide approvals. I don't want my team doing that kind of basic work. They change too often for me to really want to be bothered by it. So we gave the desktop team lead the ability to do that. And now he goes in every day or every other day and adjusts approvals as people move around in roles in the company. Everybody's happy. He gets to do it on his own timetable. We don't have to deal with it on the regular basis. If you have to, you can redirect your product owner, but that's dangerous. Sometimes, if they don't come talk to you about it before they make a decision, they'll override you, in which case, you're really down a hole. So it's dangerous, but still, sometimes, an option. And the most important thing, again, going back to it-- focus on the goal. Don't focus on how you got there. Focus on that goal itself. Sometimes you do run into cases where there are a few milestones along the way to that goal. Those are probably also goals in themselves. So it should be a relatively easy goal-- goal to goal to goal process. Not always, but hopefully, most of the time. So this is kind of the beginnings of my thought process and my time I spent thinking about the onboarding conversation. It's a complicated one. It's a complex one. It's the very first time most of these teams really interact with us on a serious basis, so it also sets the stage for the entire relationship, which is why I think it's so important. Hopefully, using some of the things you've learned here today and maybe some further conversations we'll have, you can have a better conversation and have better outcomes for your team, for your instance, and for everybody that comes after you who has to take care of it. I really appreciate your time today. Thanks for listening to this and being here. If you want to reach out to me and talk about this more, I encourage it. You can reach out on sndevs. I am ReposadoDave. It's an amazing community of 10,000 people or more. Some of us are developers. Some of us are product owners or stakeholders or VAs or any number of different roles. We all interact with ServiceNow on a regular basis, usually beyond that of a user. And we're also all here to help out and talk, and you'll find so much good information here. And if you do make it to a Knowledge in-person, you can probably meet some of us, because we always hang out at Knowledge. Again, thanks for your time today, and I'll see you next time. [MUSIC PLAYING]