Subscribe
Share
Share
Embed
Authentic, Authoritative, Unapologetic ServiceNow commentary by Cory "CJ" Wesley and Robert "The Duke" Fedoruk
CJ: Duke today.
We're talking to a very special guest.
The one and only Chris Nanda.
Hey, Chris.
Chris: guys.
How's it going today?
Duke: 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.
Chris: Yeah, it's been about 15 years now.
Duke: 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.
Chris: Very true.
A couple of apps, actually.
Duke: One was the, , Flexera integration.
Was it?
Chris: 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.
CJ: Nice.
all of those are, are,
huge Microsoft word.
So would it be safe to say that you
got a huge, , it background too?
Chris: 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.
CJ: 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,
Chris: That's exactly what we did.
CJ: boom, free market feedback,
take that first client,
Chris: Exactly.
Duke: what was your first
contact with ServiceNow?
Chris: 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.
CJ: 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.
Chris: 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,
CJ: I
Chris: 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.
Duke: Oh, those were the days.
Chris: Yeah.
Yeah.
Duke: a
CJ: absolutely.
Oh man.
That's, way back.
Chris: Oh yeah.
CJ: 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.
Duke: 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.
Chris: Um,
CJ: 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
Chris: Exactly.
CJ: Microsoft's entire management
system is all based on PowerShell.
Chris: Absolutely.
CJ: 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.
Duke: Uh,
Chris: 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.
Duke: We've got to put a
deep water sign up here.
Just 1 second.
Chris: 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.
Duke: Isn't it crazy?
Chris: 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.
Duke: I wouldn't be careful
where we placed kind of the
blame for that because I
Chris: No, no, no.
Duke: 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.
CJ: Heh heh heh.
Duke: 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.
Chris: 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.
Duke: Oh, I just straight
up murdered somebody for a
decision table back in the day.
Like,
, CJ: 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.
Chris: 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.
CJ: Mm
Chris: the business is like, Mmm, no, no,
that's nowhere near what we are saying.
Duke: 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,
Chris: 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?
CJ: Yep.
Chris: 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.
CJ: 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,
Chris: Silence.
Silence.
CJ: difference between where you
want to, we're, , rewarding folks
versus like where they sit in
the, , organizational hierarchy.
Chris: Silence.
Duke: 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.
CJ: Yeah.
Duke: 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.
CJ: 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
Chris: Hey,
CJ: right.
Get everybody on the same page.
Your Amish metaphor Duke, like,
Duke: Oh,
CJ: or no, no, this is the band.
This is the band metaphor.
Duke: the marching band.
Well,
CJ: you gotta be, go ahead, go ahead.
Duke: no, no, you go ahead.
You're, you're, you're on fire.
They're about to go pretty
CJ: 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,
Duke: 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
CJ: that,
Duke: 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?
CJ: Chris, you're the guest.
I'll let you take the crack
first unless you want me to go.
Chris: Go right ahead first.
Okay.
CJ: 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.
Chris: 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,
CJ: little
Chris: there?
And what's our plan?
And how are we going
to plan this out in a,
CJ: on
Chris: 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?
Duke: 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,
Chris: Uh, you know, I.
Duke: versus the architect is you can
establish something that is architected
? And built exquisitely, but still not,
CJ: was
Duke: 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.
Chris: 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.
CJ: Yep.
Chris: And
Duke: people that have to do that, right?
We're pragmatists here.
Chris: 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.
Duke: Hmm.
Chris: The problem comes in then,
is when you scale that up, that
EM is going to start to fail.
CJ: Okay.
Chris: 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.
CJ: Yeah, I, you know, I liked it.
Yeah, I like distinguishing between,
a good EM and a successful EM.
Right.
Okay.
Because.
Duke: saying that there can be
successful EMS that are not good EMS?
Chris: Absolutely.
CJ: Yeah.
think you could be successful without
being good at your job in a lot, a lot
of different places in this ecosystem.
Chris: Absolutely.
Duke: You guys are
CJ: I mean,
Duke: to walk that back for me and
explain it to me like I'm five.
CJ: 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.
Chris: 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
Duke: 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.
Chris: 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.
Duke: Oh yeah, for sure.
Getting what you asked for is
not, that's a huge gray area.
Chris: 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.
Duke: Yeah.
I don't really care what
the implementer feels.
Chris: Well,
Duke: Like, I don't.
Chris: 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.
CJ: Yeah,
Chris: sense.
Silence.
CJ: 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.
Chris: Absolutely.
that was an interesting roundabout.
Duke: that was good and it got
us to 34 minutes of record, so
CJ: 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.
Duke: that's just how we do it here, man.
That's our shtick.
CJ: That is our stick
Chris: Well, and
CJ: way away from how you started.
It's so awesome.
Chris: 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
CJ: Silence.
Chris: 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,
CJ: Okay.
Chris: otherwise, honestly, if you have
a team, that's very different, are they
really going to work that well together?
CJ: It's
Duke: 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
Chris: do they work day to
Duke: they don't do the same job.
Chris: but do they work
day to day together?
That's not a team I would say.
Duke: 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.
Chris: 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.
CJ: 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,
Duke: 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.
Chris: glad to talk to you guys and
Hope you guys have a great weekend.
Duke: Alright folks, thanks for watching.
We'll see you on the next one.