Duke: Okay, Corey, what are we talking about today?
CJ: Today, Duke, we're talking about the invisibility problem and how to
solve it by turning things visible.
Duke: Okay.
Let's talk about the invisible problem.
And I want a big shout out to, , Michael Rogario, , out on LinkedIn.
Cause he was asking the other week, what's your impression of the
biggest problems that have to be solved in the service now space.
And, what would you pick?
And this was my pick is the invisibility problem.
And it goes something like this.
Everything that we build and we make a, we, we even have a term for people who
were in charge of all the build, right?
The architect, and everything we talk about using service now, building
blocks and building solutions.
But I think what differentiates us from all the human history of building
is that what we build is completely.
CJ: Yeah.
Duke: If you think about, a hundred years ago when the big complex things
we built were like battleships and skyscrapers and, , highway interchanges
and, , submarines, what you could build had took up material space.
It was tangible.
And so as you build, you could be like, wait, that thing isn't level.
CJ: Yeah.
Duke: So those bolts are not the same size.
This is not the right tool for the job.
And you could see it in reality.
And you could, anticipate the consequences because you could
see the things that were wrong.
You could see, or, and you can see the things that were right too.
You could see everything that was in place.
And so it'd be like, everybody's got this story about the mechanic.
Well, that's your problem right here.
And, you know, it pulls a gigantic stick that's, you know, in the way
of the belts or whatever, I'm not a mechanic, obviously, but everything
else that human beings build is visible in some way, this is a place where
people don't dump a ton of money.
CJ: Yeah.
, Duke: and a whole bunch of effort for something that they can't see.
CJ: Yeah.
Duke: That's to me, , is the , the invisibility problem, but what, are the
consequences of the invisibility problem?
CJ: Yeah.
So I just a little context to that, right?
Like people dump a metric F ton of money into , this thing that we do, right?
Like this little thing of ours.
And, comes down to, The difference between atoms and bits, right?
Like, you know, in the past, everything that was done you built with atoms.
Atoms are visible.
Atoms you can touch, right?
Like you can measure.
It's easy to see the fruit of your labor, right?
And it's easy to see where it went wrong.
Yeah.
With, bits, not so much, right?
, and historically, right?
, and until we get a few more generations into the future, like there's
still this fear , Of technology with a certain generation, right?
And so a lot of folks look at it as magic and they stay away from it, to
the question, what are the results of this, ? I think what I've seen is that
the biggest result that I've seen of the invisibility problem and service
now is service now implementations that go way wrong or bad or sometimes
even only slightly wrong or bad,
? But.
Often throw off the platform internally enough that it dramatically reduces
the, , usefulness and the value that you get out of it and often the adoption.
Duke: Yeah, and I see it as , you never quite know, , I have been to customers
that lacked the architectural oversight.
On paper, they did everything right the whole way through, but whatever reason,
or without an architect, and you go in for the interview and you're like, well,
what's the footprint of your system?
And we're like, we think we think we've got all these things deployed.
What do you license for?
It's like a whole other, you know what I mean?
Like, we can't, you can't just open the hood and see what's wrong or right.
CJ: yeah, yeah, no, absolutely it's all a leap of faith.
You, you hope that, the person who built the system documented it.
Well, you hope that there's , some communication
lying around somewhere, right?
Like you hope that, you know, you hope that the business actually
knows what they asked for.
Sometimes they don't even know that.
. And you hope that somewhere, some, somebody cared enough, right.
To say, okay, we bought this product, we're delivering the service using it.
. And this is how it should be done.
I don't see like
they're all all too often.
Right.
Do that, that I don't, that I don't see any of those things and then folks wonder
like, okay, so why aren't we successful?
It's like, did you even stop and define what success is to start?
even the definition of success is invisible.
Duke: And if the problem is abstract and really how much damage can be
done, I would encourage you to go back and listen to our doomsday episode.
Links will be in the description below.
Everybody take a shot.
CJ: always,
Duke: Yeah, because the doomsday scenario in the service now world
is a greenfield project, right?
We're at the point where we've built and built and built and
built on this ostensibly for good reasons to drive more value.
Hey, let's sacrifice all of that so that we can try and do it again.
CJ: Yeah.
Duke: the, and, and the invisibility problem is I would say.
Like one of the major prime movers in that whole equation.
Like I never get to the point where I need a greenfield if I
wasn't suffering the consequences.
Of the invisibility problem, like the thing that earned me my flight wings
in the ServiceNow world, you know, I had been an admin and a developer and
built cool stuff, but I didn't become a grown up in the ServiceNow space until
I had my first re architecture project.
And let me just give an example of the invisibility problem in action.
This company had high aspirations to do a lot more with ITSM,
CJ: Right.
Duke: right?
Yeah.
We got the ITSM stuff.
Yep.
And the catalog.
And for the most part, it's okay.
We've got some rough patches here and there.
We just need somebody to come in, polish it up.
We want a super awesome CMDB, right?
We want, , integration with third party, service desks and, you
know, come in and polish it up.
And when I came in and started poking around what's built in the system,
like the people who hired me didn't even know the scale of other stuff
that was built on the platform.
They knew that we had this other kind of like think business
operation, shared service center, not it just shared services
amongst other business disciplines.
, they knew that there was some, other operational stuff that had
built on service now, but what they didn't know was that that stuff.
Was three times the number of transactions than , all the it
stuff, incident, problem, change, all of that stuff combined.
So it was like the people who literally own the platform were completely
unaware that they were the smallest and frankly, the least important politically
stakeholder in their entire application.
CJ: right,
Duke: And you think that's pretty stupid, but how can it be stupid
when you, you literally can't see it.
CJ: Yeah.
I mean, you don't know, right.
You know, somebody asked you to do a thing, right.
And you created a framework so they can do the thing.
And now you don't necessarily know.
, because you're not consuming that service that's being offered to them, like how
extensively they're using it and to what degree and yeah, I mean, there's an
argument here that you should know, right?
Like, as the owner of the platform, right?
There's an argument here.
Definitely that you should know.
But I think the problem that we're pointing out here is that it is
invisible unless you go looking for it.
Duke: That's
CJ: Right?
And so the things we need to do is to make sure that we understand
the things that need to be visible, that we elevate them, right?
So that they're obvious, and then we can use those to avoid, like you
said, the doomsday scenario, which is basically a greenfield rebuild.
Right.
And nobody wants to do that.
Nobody wants to, because everyone says, well, this time is different.
It's never different.
Right.
You're going to , rebuild it and there's going to be something you missed or
something new is going to, right.
It's just, you just,
Duke: It's invisible.
CJ: you know, that you deliver the product, in a way, , that you
can build on it in the future.
Right.
And that everyone knows what you got and that they can communicate it.
I think so.
I think we just got to stop treating this thing like it's magic, right?
Like, let's stop treating it like it's magic.
I think that's a good, that's a good concise point from that,
that I, I'd probably, I'm probably going to take with me , from this,
from the podcast here, right?
Like let's stop treating service now.
Like it's magic.
It's magic.
And start treating it like it's actual enterprise value, right.
And communicate it as such.
Now, how do we do that?
Duke?
Duke: sorry.
CJ: that the idea of
Duke: invis?
CJ: bail?
Duke: No, you know, I got, I got the diabetes.
I got the diabetes and, , I'm on this new program and I'm just
like loaded up with sensors.
And, , this is my continuous glucose monitor,
CJ: Oh, nice.
Duke: which is connected by Bluetooth to my phone.
And every once in a while, my phone's like, I can't read
your blood glucose monitor.
And so it's.
Sending me alerts and I can't figure out ways to configure the alerts.
And that's the invisibility problem too, is how do I actually manage this stuff?
CJ: Yeah, right.
Like how do you manage this stuff?
Because yeah, it's a bunch of stuff, right?
Like, so , how do we begin to solve this problem?
. Because I refuse to believe that, this problem that we have,
that is likely one of the most, , impactful, I think, Especially
Duke: pernicious.
Yeah.
It's super funny.
Yeah.
CJ: How do we get started and fixing it?
Duke: Okay.
So I don't think we're hopeless in terms of tech, technical solutions.
I see hints of emerging tech that can help us with it.
Okay.
Like, Upgrade center is one of them.
Upgrade center gives you a hint of what could be right.
So upgrade center is like, well, here's visually a look at the conflicts
that are generated by this upgrade.
CJ: Right.
Duke: So there is some sense that some tools can see , wait,
this isn't out of box.
CJ: Wait, say that
Duke: so there's, well, upgrade center , can basically show you , that the system
can identify where the system is not.
, out of box.
CJ: Right.
Right.
No.
And
Duke: So , it does its own thing, its own way for its own context.
Right.
But , it's got a hint, a shade of what we would need for a technical solution,
or at least a technical tool crutch, I'm not sure what the right noun is to
help address the invisibility problem.
Like if I could have my druthers, it would be something that
identifies modules correctly.
CJ: right.
Duke: Just imagine a big square that is ITSM, right?
And the square is maybe shaded or colored depending on how much stuff is Either
added to or updated from out of box,
CJ: Yeah.
Yep.
Duke: Something that can visually show you like other scoped apps, And then
also code them in terms of some kind of usage like yeah, you have this big scoped
up You've got the banana app over here,
CJ: Yeah.
Yeah.
Duke: Maybe just say there's been 10 transactions over the
past six months on banana app.
CJ: Yeah.
Duke: so it's kind of like, here's all the stuff like a abstraction.
I mean, even, the visualizations for CMDB could be utilized to this end.
CJ: Right.
Duke: Like something that just shows the interconnected pieces,
like these two scoped apps share these, cross scope dependencies.
so we know that they interact together, so like, join them together.
CJ: Yep.
Yep.
I'm liking where you're going with this Duke.
I mean, it's going to one of our favorite words, I think, but keep going.
Duke: One of our favorite
CJ: Yeah.
Yeah.
No, this is elevating towards one of our favorite words.
Absolutely.
Duke: um, Yeah, so, um, I guess the document, the,
CJ: it's easy.
Duke: Ah, there we go!
I felt it, did you feel that?
I felt that.
CJ: The documentation, right?
Like, you know, is one is probably the first level of defense
against the invisibility problem.
Duke: yeah, because documentation is something that you can solve now.
CJ: Right.
Duke: we can daydream about what an adequate solution to the
invisibility technically would be right, but it's still not there
CJ: Right.
Duke: and anybody who decides to build it.
, just remember your guy, the Duke here that helped you decide on building
that, but yeah, you're right.
and go and see our documentation episode.
It'll be link will be in the description below.
Everybody take a shot.
CJ: Boom.
Duke: because we'll say it again, just people just sleep on documentation.
They sleep on it.
It's like, is it that important?
Well, consider how dangerous the invisibility.
I don't know how to shut that off either.
I'm even in do not disturb mode.
I can't.
CJ: like, disturb
Duke: If you just consider how bad the invisibility problem is
for you, how else would you do it?
Like, every time you're doing a significant deployment, at
least write something in some master guide to your instance.
It's not that hard.
if you're deciding to deploy something big, like SPM or service mapping or,
whatever, any big app , it could take you like 15 minutes to at least write
something in a document that contains all your other major initiatives that have
happened over the life of the thing.
At least then you have an idea of what you've got deployed.
Who's the owner, who are the prime stakeholders?
Why did they decide to do it?
Even if you had just that, you'd be so far ahead of a lot of other
customers, a lot of other partners, if you can provide this to the
CJ: Let me tell you another reason why you should do documentation Duke.
And it's a, it's a reason that didn't exist probably when
we made the episode, right?
Or if it did exist, ? It was probably still in this emphasis of being valuable,
but gen AI makes documentation scale.
To 100 X 1000 X is previous usefulness, right?
Because in the past, you actually had to read the documentation, you had to
search through all of the volumes and the sacred tomes of knowledge in order
to find the thing that you're looking for, which in AI, you just let that thing
consume like your internal knowledge.
I think you just ask it questions.
So you no longer have to read all the tomes, right?
Somebody else just did it for you, So all you got to do is
make sure you write them as
Duke: man, are we doing, are we turning this episode into a Gen AI episode again?
I don't mind.
CJ: But I just, but right, like, it's just the power of it, right?
Like, I think it's just going to keep coming up, as a theme and a
lot of episodes, you know, going forward, ? Because , when you combine
documentation with gen AI, like visibility, becomes the result.
And how do you counter invisibility?
What visibility?
So boom, if you needed any more encouragement on why you should
document like that right there should be the ultimate business case or
the ultimate like case in value and the ultimate thing that, that, that
spurs you towards, just doing more massive levels of documentation.
Massive levels of documentation.
Duke: Yeah, but let's, okay.
So the one thing I would caution about a Gen AI solution to this is that the
Gen AI solution can't read intent.
CJ: I don't know.
Sometimes.
I mean, have you ever, you, you've used strategy BT.
Sometimes I think that things read in my mind.
Duke: I did a chat, a chat GPT thing to modify some Excel's for resource
management imports last week.
It must've saved me now.
I use, I dedicated like five hours to this, to think about how I would have
pulled this off on my own and Excel.
Would it, it would have taken me hundreds of hours of just like,
oh, how do I do this in Excel?
And then experimenting.
And I just told chat GPT to do it.
And it did.
So like, believe me when I say I have firsthand experience about how
crazy, crazy powerful that thing could be, but it still couldn't tell
me, why do you think I'm doing this?
CJ: Yeah, but it could tell you what you wrote to tell it
why you think you're doing it.
Right, like there's a mission statement that can accompany
the documentation, right?
We just made this change during this upgrade.
Why do we make this upgrade?
? These are the 5 reasons we made the upgrade.
Now you got a statement of intent.
The chat GPT can tell you, you just got to know up front, that
intent is the thing that you value.
And so you include in the documentation when you're creating it.
Duke: Yeah.
CJ: Ultimately, I think what this will do is , once you democratize
the knowledge, , democratize , the output of the documentation, right?
Because what we've always done is required it.
Right.
Or, encouraged it.
. And then, so it gets created and then nobody ever reads it.
. But when you start to be able to, create value from it, . Through again, Jenny,
I being able to ask it these questions.
Now you can actually see what's missing, right?
Like you can see what you actually asked it to do that you didn't get.
, but that you didn't require, what you asked folks to deliver
that wasn't being included.
And then you can go back and adjust your standards so that
you're getting all the things.
That going into it that you want to see come out the other end.
. And now you've got this, virtuous cycle, this continuous
improvement around documentation.
And man, if that ain't ITIL and ITSM.
Duke: super,
CJ: problem to documentation, but that's what we do here with documents.
I, I, is there a documentation consortium?
I swear we should be sponsored.
Duke: like, super sponsored by that.
Like, Hey, listen, if you are a company that thinks they've got
the documentation problem licked on service now, get an episode.
CJ: Yeah, no
Duke: now is.
Yeah, like get an episode.
, it would help the community.
Look, sometimes what we do on CJ and the Duke is we just point at a
problem and articulate the problem.
We're not saying we got all the answers here.
CJ: Speak for yourself,
Duke: Just, just most of them.
We got most of it.
But even we, believe it or not, have weaknesses.
CJ: Yeah.
Yeah.
I mean, right.
Even Superman's got kryptonite.
Right.
I mean, I don't think I'm not quite sure Batman has any weaknesses, but that
is an entirely different conversation.
Duke: isn't that crazy?
Like, being rich is a better superpower than being a Kryptonian.
CJ: Right.
Gotta love it, man.
You gotta love it.
I love that line in the movie too.
He's like, what's your superpower?
I'm rich.
Duke: Oh man.
CJ: So,
Duke: can't tell me that if you hit the, like, the, the power ball in Illinois
is like over a billion right now,
CJ: yeah, I know.
I mean, you got to go play.
I
Duke: I would be like, I would be like not doing surface now stuff.
I'd be like, what does it really take to build a wingsuit?
CJ: would be doing ServiceNow stuff as Batman.
I would show up to knowledge as Batman.
I would absolutely do that.
Just because.
Like, why not?
So, what's the
Duke: That was a cool tangent.
CJ: But what's the next thing we could do Duke on, creating visibility
around the invisible problem, right?
Like I know documentation, right?
We just went, really went through that.
And what else can we do?
. , Duke: I'm not sure if it's the same problem, but it has the same name
CJ: Okay.
Okay.
Duke: of the invisibility problem.
And that is , do you know how to use service now?
and how it's all supposed to work.
I don't want to take anything away from our, rich, vibrant, diverse.
Service now technologist ecosystem.
Right.
But imagine you're a customer and you're just like, listen, we made all the
investments, like we've got this giant team internal, we have vendors for stuff.
But man, it's been a couple of years since we deployed SPM.
I'm hearing all these whispers that there is, new strategic planning stuff,
new ways of doing resource management.
And I go and research this.
I've gone through, , 10, 15 different docs pages.
Oh, there's a screenshot of a resource management.
Process.
And even though we, do resource management, we've never seen that
interface before, what the heck is that?
How do I get to that?
And it's just maybe invisibility problem is the wrong It's effectively invisible
in that I can't find decent enough information to grow my knowledge visually.
. CJ: Yeah.
No, that's a really good point.
When I first started on the platform over 10 years ago, the thing that I recall,
it's a lot of things I recall, right?
1 of 1 of those is right.
Click everything.
, but another thing that I recall was when talking about.
How do you use ServiceNow and how do you communicate, how do you use
ServiceNow to, , my, my user community?
. And the thing that I was told by , a lot of folks at ServiceNow and even
a lot of folks in the community is.
That you don't have to, it's so intuitive.
You just drop the, instance in front of them and people get it.
Now, I can't say whether, whether or not that was true, , 12 or 13 years ago, I
can tell you that now that it's not true.
there's and that's just , the ultimate outcome of the platform
evolving to do so much stuff.
Duke: Yep.
, CJ: and now there's so many different types of interfaces and so many
different types of screens that you get presented with and so many different
types of actions that you can take.
, there's just no way to convey This is how you do it, drop it in front of
somebody and just let them poke around.
So as you were saying, we need more communication around that.
And I think you're right.
, I don't know where to go.
I'll tell you why I do go occasionally.
Like I've been in the lurch before delivering a new pro a new process, right.
That, , unexpectedly had some attributes to it or some, wrinkles to it, . That
I didn't expect to encounter, , cause most stuff on service now platform
builds off the platform functionality and you can get the rest, right.
I ran into some, some parts of this thing where it's like, okay, , I'm stuck.
I go to YouTube, . And there are some folks out there who
have created some extensive.
Extensive, videos, of a process where it is literally today, we're going to
talk about virtual agent and you are literally watching four hours of somebody
start to finish, like spin this thing up, go through almost every screen,
almost every attribute, almost every system property, But is that efficient?
I don't think that's efficient.
Like I was in alerts, right?
It was a Sunday.
I got a, I had a demo on Monday.
I needed to make sure I knew how this thing works.
So I was watching every, all four hours of that thing.
But like that's not efficient.
Like you would, that's, that can't be how we get this level of knowledge.
Right.
Or can it,
Duke: I don't know,
CJ: right.
Right.
Duke: I feel that pain very deeply in just my efforts to stay on top
of as much of service now as I can, some of my favorite implementations
have been SPM implementations.
Some of the most difficult parts of those implementations has been resource
management and I, and I'm totally open to the idea that it's just me, right?
Like I'm the dummy here, right?
But I feel like it's so difficult to figure out how this thing is growing,
and how it's supposed to work now.
So you hear these whispers that, Hey, there's this new
strategic resource planning.
I don't even know if it's called that.
I did.
I did like a couple hours diving through docs about it.
, earlier in the
CJ: Okay.
Duke: I don't even know if it's called that, but I'm searching docs.
I'm finding stuff and it's like, oh, it's different.
Like, are they retiring the old resource management?
That's what it sounds like.
Maybe this new resource management is the only resource management you
need, but then you find other docs.
It's like, no, they go together.
they're two different resource management things, but they
solve two different problems.
And I'm like, where are the, , rigidly focused documents
about how this should work?
CJ: Yeah.
Duke: We have bits and pieces, we get videos on ServiceNow's main
CJ: No, hold on.
Hold on.
Hold on, dude.
You said how this should work.
I think that's key.
I think, I think that's something that needs to be highlighted, right?
Because I think docs tells us how it works, right?
Like, this is the thing.
These are the things.
Duke: even do that.
I mean, like, listen, no, no, no, I'm not taking anything away from the docs.
People have an incredibly difficult job, but you're right.
Docs is very like definitional
CJ: Definitional.
Thank
Duke: it is, not how it should work.
And that's that's an invisibility thing too.
And I think it's one that I mean, I don't think the professional services world
would be half as large as it is today.
If there was Really good assets about front to back.
This is how ITBM works.
Sorry, SPM now.
And it's not like that's an easy thing to do either.
Like one of my most successful SPM implementations was only successful
because I like the first two weeks of the deployment was essentially
like a two week long demo.
, here's how we do everything on SPM.
Everything from , taking it from the ideation process, the demand process.
All the way through, , resource planning and then, everything to do with project
and portfolio management, or like right down to the nitty gritty stuff
like baselines , and RIDAC management.
And that kind of stuff.
. But it was like, at the end of that, we had hours and hours and hours of video
recording talking like 80 hours where it was like, here's how we do it out of box.
And not only did that help us get them to understand, here's exactly
how it works because you don't go from buying to understanding how it works.
CJ: that's true.
That's true.
you get told that it does the thing that you're looking to do.
Duke: Yeah.
But it also flushed out, here's the stuff that we're super excited about.
We didn't know it did this and we can totally get rid of this
BS process that we've been doing to compensate for our old tools.
CJ: Yeah.
Fair.
Duke: Okay.
But it also flushes out the, okay, this is going to be problematic.
CJ: Right.
Duke: how am I supposed to reconcile the invoices for my external labor that
says, here's how many hours we've done when I'm doing the time cards in service
now, and I can't break the time card out per month, how could I do my monthly
billing reconciliations on my labor?
When I can't break a time card out into months now, that's an old problem
that got fixed, but that's exactly the type of stuff I'm talking about
is it sucks how this stuff should be deployed is every bit as invisible,
meaning I can't look at something.
I can't watch something to tell me how it's done.
Sorry.
I just totally went on a rant there.
CJ: I know.
It's all good.
So what I'm hearing Duke is that maybe process that I mentioned, right?
Maybe that those YouTube videos, maybe that's the process.
Of how this should be deployed , and maybe it's not just the YouTube videos,
maybe it's more visibility, more graphic centered, , UI in your face,
here's an image , of the process, and here's a little bit of, X, Y, and Z.
And, oh, here's another screen of , where you should be and how this looks.
And here's another screen.
, and honestly, even as someone who's been doing this for a long,
long, long, long time, right?
I do feel like the learning aspect of service now is a challenge.
Because you'd only have so much time to devote to it, right?
When you are trying to get into the ecosystem, if you're a career changer,
you only have so much time to devote because you typically are still
maintaining your previous job while trying to learn to break into this new job.
. As someone who is an independent consultant, I am typically trying
to make sure I can pay my mortgage.
And so I've got clients, right?
And so I'm , delivering services while also.
Trying to learn and keep abreast so that can keep getting
clients and delivering services.
? So the time and not to mention like everything else, family
time, et cetera, et cetera.
We're just gonna put that in the bucket and call that a known.
? And so how do you like, how do you find the time to consume this stuff
in the most efficient way possible and get the most value out of it?
possible as well without it taking me.
The equivalent of an additional full time job.
And Oh, by the way, Duke, we're also recording a podcast, yeah, I mean,
this is, this is definitely an issue.
Duke: and I think maybe since we're at 34 minutes of record, maybe we leave
that for the newcomers out there.
how can you get the best bang for your buck?
Learning the tool, learning a process, having assets that you can point
to saying, look at how good I am.
CJ: Yeah,
Duke: try and solve the invisibility problem like with a playbook,
CJ: yeah, yeah, yeah, yeah,
, Duke: here is how ITSM works.
, here's how you do every function in incident management and document it
as if you were handing that over to a person of this is how it should work.
And I guarantee you, like not even a whole lot of partners have that out there.
And then
CJ: Yeah.
Duke: have an asset that you could just take with you.
CJ: I love that.
I think that's a great, a great segment of the market that
new folks can, concentrate on.
Duke: All right, folks.
another one in the books.
Thanks for listening.
, if you want to come and talk about the invisibility problem, maybe you got a
solution or two of your own more than happy, just please reach out to us
and we will see you on the next one.
CJ: All right.
Bye.
Still no outro.