CJ & The Duke

We discuss some practical methods for bringing the chaos of ServiceNow implementations under control

ALSO MENTIONED:
- Robert's Rules of Order

Thanks to our sponsors,
-
Clear Skye the optimized identity governance & security solution built natively on ServiceNow.
- Magic Mind the world's first mental performance shot.  Get you up to 48% off your 1st subscription or 20% off one time purchases with code CJANDTHEDUKE20 at checkout.  Claim it at: https://www.magicmind.com/cjandtheduke

ABOUT US
Cory and Robert are vendor agnostic freelance ServiceNow architects.
Cory is the founder of TekVoyant.
Robert is the founder of The Duke Digital Media

Sponsor Us!

What is CJ & The Duke?

Authentic, Authoritative, Unapologetic ServiceNow commentary by Cory "CJ" Wesley and Robert "The Duke" Fedoruk

Duke: Alright, Corey, what
are we talking about today?

We're

CJ: All right, dude.

Today, we are going to navigate chaos.

Duke: gonna put all kinds of
Amber 40K jokes in here too.

CJ: My man, we're going to the Ida
storm and hopefully we're coming out.

Duke: the Emperor!

We will navigate chaos!

Oh man, there's like five people
who are laughing right now.

CJ: are us.

Duke: right!

An open mind is like a fortress with
its gates unbarred and unguarded.

Alright.

CJ: So do tell me, , why do we
even need to navigate chaos?

, why is this something that
we need to talk about?

, Duke: because the best of us
will be called on to take

care of those situations.

We all want to be dragon slayers, right?

We all want to move up in the
world, we want to , take on

bigger and bigger challenges.

And at some point, , the size
of the challenge is dictated

by how unknown it is.

CJ: Yeah.

Duke: Like there's small unknowns,
how do we do this one thing, ? That's

a small unknown, but this big
thing is, Hey, the catalog sucks.

Everybody hates it.

Fix it.

CJ: Yeah, yeah, so, , what did I hate

Duke: Well, I don't know.

That's what I mean, but
that's what we're here to do.

CJ: I know, I know,

Duke: to talk about, right?

CJ: right

, Duke: at some point you're going to get
assigned something that isn't defined.

CJ: Yeah, I mean,

Duke: That's also big and not defined.

Okay.

CJ: Either, , directly or indirectly,
and what I mean by that is that

you've probably had a problem
given to you that wasn't defined.

And you probably had a problem that
the, a signer thought was defined, but

really wasn't once you broke it down.

So, I think this is just a situation
that a lot of people find themselves in.

A lot more often than most people,
, would think because it's really hard to

contextualize to put a label on, right?

I think calling it chaos is as good of a
name as any, because it really is looking

into the heart of the storm and trying to
make sense out of it all without a map.

Duke: Yeah, it's gonna happen to
you, every service now instance

out there has some chaotic element,
something that is not under control,

something that is not well known.

Um,

CJ: Absolutely.

Duke: Like, I work with this one customer
and it was like, why is everything so

slow, not performance slow, but why?

Like we have this huge backlog of work,
we've got this team of people, but how

come everything takes so long to execute
still, and there could be any myriad of

reasons, but you've got to solve these
problems, but there's no playbook for it.

CJ: yeah.

And so the question is, where do
you start with that situation?

? Because I think there's no playbook
for it, but I think we all bring a

certain, , style to that situation,
? Whether you think so or not.

? And the question is, do you
intentionally bring that style or do

you just, find yourself in the deep
end and struggling to stay afloat?

Haha.

Duke: So anyways, that's what
we're here to talk about.

We did some thinking about
some, things that might help and

that's what we do here, right?

As we try and help people boss up,

CJ: I like it.

All right, dude.

Kick us off then.

So what's the first thing you would
say when, uh, what's the first.

Duke: pull out that rummy quote,

CJ: What's that?

Duke: Donnie rums.

CJ: all right.

Yeah, I'll go with that.

Yep.

So one of the things, that I often
think about when I'm entering

a chaotic situation, right.

Or even just the new situation really,
. Is, Donald Rumsfeld, defense, , secretary

for us, some years ago, probably.

A lot of time before us.

Some of you guys were
born who are listening.

But, he had this interesting quote, I
abstracted some of it . But I think the

whole quote is pretty interesting, right?

And this, reports to say that
something hasn't happened are

always interesting to me because,
as we know, there are no knowns.

There are things we know we know, right?

We also know that there
are known unknowns.

That is to say, we know there are
some things we do not know, but

there are also unknown unknowns.

The ones we don't know, we don't know.

And if one looks throughout history of
our country and other free countries,

it is the latter category that tends
to be the difficult ones, so when I'm

thinking about Service now and projects
and dealing with processes and being

parachuted in the situations, right?

This quote is always one of the first
things that goes through my mind, right?

It's like, okay, so what do I know?

. What am I known knowns, right?

Hopefully I was able to glean some of that
from the client before I accepted the gig.

, so I got a list there.

Okay.

These are the things that I
know are already jacked up

or need improvement or you.

Perfectly fine.

And then there's my known unknowns, right?

It's like, okay, so I know there's some
kind of question around foundational data.

You know, I've heard that there
might be some weirdness there.

They haven't updated ad in 20 years or
what have you, or they're switched over

to Azure and nobody knows how these things
work anymore, et cetera, et cetera, right?

So now you got your known unknowns, right?

But then it's the unknown unknowns, right?

Okay.

And those are the things that you don't
find out until you actually get into

the mix, I spent a whole lot of time
trying to qualify my clients right on

those no knowns and those known unknowns,
but it's not until I actually stepped

foot in the door metaphorically, right?

That I actually start to figure
out what are my unknown unknowns.

And often I found that most of the
significant unknown unknowns are people.

Duke: Yeah, it really does.

Just, it always rubbed me wrong
way that, thing that people say

that people process and tools.

CJ: Yeah.

People process product.

Yeah.

Duke: because it's people that
design the processes and are loyal

to them once they give birth to them.

Right.

And then it's people that configure
tools or it's people that want something

out of the tools that isn't there.

And so it's basically.

CJ: it totally is.

, when I was doing the service now,
, photo shoot earlier this year, I was

talking to one of the photographers.

That's what they do when they're
trying to get you to smile and stuff.

Right.

And he was asking me about what I do.

And as I was telling me, say, you know, I
think you're an organizational therapist.

And I was , like, Hmm, maybe I am.

Right.

Because often what I do is I come
in and I talk to the people who are

involved in this service now program.

. And I'm talking them
through their problems.

Right.

Trying to get them to a resolution,
. Trying to get them to, , understand

more about themselves and ultimately
where they want to go, and them

being both, themselves as people, the
organization and also the tool, right.

So yeah, organizational therapists.

Definitely.

I can kind of see that.

, and part of that is trying to dig into
a lot of these unknown unknowns, right?

I think that's really,
because that's really where.

Where I think a lot of the value
comes in, but also the, a lot of the

potential for chaos and destruction.

Right?

Duke: but let's talk about how
you get, cause you gotta, you

gotta start contending with,

CJ: Yeah, absolutely.

Duke: you gotta kind of flush them out.

It's such a simple thing to do, but.

Too few people do it, but take notes,
get really good at note taking.

CJ: Yeah.

Yeah.

Duke: And, and review the notes.

I like to pat myself on
the back a little bit.

I think I did really good notes, but
it didn't start getting super, super

good until I started reviewing them.

So I'll like take the notes and like
a day later, I'll reorganize them.

I'll edit them down.

I'll refine them.

I'll break the notes into categories.

And then I come to the next meeting and.

the whole unknown knowns or the known
unknowns start becoming more known.

Like, it just gives you more, image in
my head is when you're mountain climbing.

? And you just need purchase.

You just need something a little
bit extra to get the extra grip on.

So you can propel yourself up.

CJ: yeah, no, I,

Duke: the notes for me , just does it.

And then as you're working
the same project, don't open.

Gosh, I've learned this
the hard way so many times.

Right.

Don't open a new fresh page
each time you meet, right?

CJ: is that?

Duke: why is that?

Because then it's like when
you review them, now you're

scanning across multiple assets.

And it's just logistically,
mechanically harder to find

, previously discovered information.

You just keep it in the same, document.

And everything you want to write down as
a note is part of your knowledge base.

CJ: Oh,

Duke: I mean?

Your knowledge base for this
project that's going on.

Like, imagine you flush out a key
requirement, But that was on Monday and

you're meeting like three times a week.

So you got Wednesday's doc and
now you're on Friday's doc.

You find another key requirement,
which is written on Friday's doc.

And then next week on Wednesday, when you
finally meet again, , do you even remember

what day's doc that thing was in that
you're not talking about next Wednesday?

Okay.

And by the way, this is like a
project that you work on two hours

every second day for four weeks.

So you got like, 34 other hours
of the week you're doing stuff.

So if you get into the habit
of taking notes, just collapse

it into one note asset.

I don't care what you use.

Like I use, yeah,

like I use, I use word, but I've been
dying to learn things like notion.

. Just to take capitalize on like
hyperlinks and stuff like this.

And so,

CJ: Yeah, man.

You diving into like, you know, personal
knowledge graph and things like that.

That's a whole episode back and I can
definitely nerd out on some of that

notion and Rome and things like that.

Duke: I will literally pay somebody
to teach me Notion to a high level.

I will literally pay somebody.

If you know anybody, chat, please,
please get in touch, please.

Anyways, take notes and
interview the notes.

CJ: I think that's a good, , point.

I think that based on the type of
contract or the type of client or

the type of project this, that I'm,
, engaged in, notes are, it can be like.

The lifeblood, right?

They can be the thing that
separates, , failure from success.

When I'm doing a project where
didn't, , entails a lot of,

, executive, , stakeholder interviews
and things of that nature, right?

Then I got to put all of that together
and to some kind of cohesive report to

deliver to folks at the end of the day
to say, okay, So I've talked to all the

people in your broken process and they've
all told me like why they think is broken,

what they get out of it, what they want
to get out of it, or why they don't

think they should even be involved in it.

. And these are the things that
all jumped out based on everyone

who was on who I interviewed.

. And these are some of the things that I
thought were super important, even though

they were raised by only a few folks.

And then these are a lot of the benefits
that, you know, or these are the folks

who actually feel like they shouldn't
even be, I shouldn't be talking to them.

. We had a good conversation, but they're
like, why am I even doing this thing?

I don't do the thing because I
don't know why I'm doing the thing.

I don't see what the value is.

Right.

And being able to put all that stuff
together and deliver a report at the end

of the day to the client and say, okay,
now we know why your process is broken.

And we know what some of your
stakeholders want to get out of it.

Let's see if we can align that with
what you're looking to get out of

the process and rebuild it better.

Duke: man, this is such a good point to,
formalizing what you've learned so far.

Like, if you're going to take the notes
and it sounds like what you're saying

now is just , Make sure those notes
have stuff about the people involved,

their takes, and your consulting,
opinions on those takes, right?

But then frequently providing that
to your stakeholder, not just talking

about it, but providing them the asset,

CJ: Yeah.

Duke: is huge because I'll tell
you, if somebody's coming to you and

saying, Here's a completely undefined
thing, a very vaguely defined thing,

with a ton of unknown unknowns in it.

if they're giving it to you, then
they've got heat on them as well.

And if they could solve it, they'd
already be done, gone, doing that.

Right.

CJ: Yep,

Duke: And so you help them craft a
narrative for the people who are breathing

down their necks , by providing that to

CJ: well, that's exactly it Duke,
I've got a client right now where

I'm doing , this exact thing, right?

Where they've engaged me to help
them, talk to their people, right?

To figure out like how this thing
that they're doing can be better

because right now it's not working.

, and I'm arming them for
those conversations.

But I'm also at the same time acting
on their behalf with those folks

and being a neutral arbiter, right?

, I got one foot on each side of the line,
. Because I'm acting as their agent, but I'm

also acting as a neutral arbiter, right?

Like somebody who doesn't work
for the company, but also has

all of this extensive service now
and process experience, . To then

be able to coax out of, those
stakeholders, some of that data that.

Is really sometimes hard
to share internally.

And then I package all it up, give
it to my client, and now they're

armed for these conversations to
actually make the process better.

Duke: the subset of that, and also
something to put into the master note.

I have a feeling it's going to rapidly
turn into like a note taking thing.

So for me, like, be sure that you're
writing down the whole cast of characters

CJ: Oh, that's

Duke: on my notes.

It's literally what it says cast.

CJ: Nice.

Duke: and when there's 10 people in the
meeting, , literally get their names

and how they're involved in the thing.

CJ: Nice.

Duke: It just helps you build a better
solution is, I mean, it's a small

thing again, but it's a big thing.

Right.

You have to understand who's, at play
at this, who makes the decisions,

, who has to be made happy, which
might not be the decision maker.

CJ: Yes, no, no, absolutely.

Oh man, don't.

So we're going to talk
about hidden power, right?

Because, that's also a thing.

That's one of those
unknown unknowns, right?

That's why I said earlier.

That, , sometimes these things are
about, , the unknown unknowns for

me, almost always people, right?

Because you don't know who, exercise
is quite influence until you get

involved in an integrated into
the dynamic of the organization.

Right?

And then you actually figure
out, whose power is moving

not only the platform, right?

And the teams.

But also the company, right?

And then, but and once you figure
that out, then you can figure

out how you can build service now
to align with the goals, right?

That are may not always be obvious to
even the people who are working there.

But when you find that sweet spot
and when you hit that alignment.

Boom, that's value, right?

And so, again, one of those
unknown unknowns, right?

That quiet power that's being
exerted by folks that isn't going

to always be obvious, but you've
got to be on the lookout for it.

Duke: got an example of this.

CJ: Yeah,

Duke: I had this customer certain
employees have to track time.

And certain employees have to, , approve
time and it's weird, like employees can

shift between different departments.

So sometimes you have to change
the scope of your approval context.

Right?

And there was a couple teams that
are moving to their own kind of

cordoned off area of service now.

, but those teams basically receive
a lot of the requests to change

the context of time approval.

CJ: right.

Duke: And they're like, well,
we're going to our own area.

So this stuff won't be
landing in this area.

where it used to land.

So , you have to get with that
team and build them a catalog.

CJ: Okay.

Duke: I have the teams that usually
receive this stuff and they would

just literally, crumple up the
piece of paper and toss it over

the wall at the other folks.

Oh, I got problems on top of problems.

Okay.

CJ: just no longer my problem.

Here you go.

Your problem.

Now you deal with that,

Duke: okay, so we got these two teams.

So we have to cover them off, right?

Because they have to have a way of telling
the people that would come to them.

No, this is the right input path.

Okay, so I've got training and
knowledge documentation that I'm

for sure got to write to them.

Now it's like, okay, get to this
team that actually does the work,

Two meetings in come to find out.

Yeah, they do some of the work, but only
after some other team has done the work.

We're two weeks into this and
now I got a whole other team.

CJ: right?

Duke: So, slap my hand because in
this case I was very Narrowly focused,

You tell me what your process is.

And of course, they told
me what their process is.

CJ: right.

Duke: But by accident, we
sussed out that there's another

team involved in this as well.

CJ: and they failed to mention that.

Duke: Yeah, but it's kind of like,
yes, you could say that, but you

could also, but you could also say,
Robert, is there a better question

you could have asked, right?

extreme accountability here.

CJ: Yeah.

No, no, it's absolutely fair.

I always say that communication
is the responsibility of the

communicator, not the audience.

, and so in this situation, I, I
would totally agree with you, right?

, is there a better question
you could have asked?

Is there a different person
you could have talked to?

Duke: Oh, and here's the thing.

Cause they're not like, they're
not ServiceNow people, right?

They process tickets in ServiceNow.

And here's another unknown, unknown,
how good has your previous service

now system been set up because.

These gentlemen were so focused
on the idea that, , you give me

a ticket, and I take that ticket,
do something with it, and then

give that ticket to somebody else.

it never dawned in their mind, because
they're not ServiceNow experts,

that flows can send whatever tasks
to whomever they want, in whatever

sequence they want, and it can still
be part of some overarching process.

Rhythm or whatever, like all
kinds of people can get tasks

CJ: I mean,

Duke: chunk of work.

CJ: yeah, yeah.

Duke: just like, well, when the
task gets to us, the one task that's

like pinballing around it, when
we get it, this is our process.

I guess you have to understand
the pieces on the chessboard.

The sooner you can find that
out, like who all is involved.

Like I should have just said, when
somebody is asking for a change

in this Time tracking application.

Who all must be involved in that?

Not, what is the flow for your team?

CJ: Yes, yes, yes, yes.

, help me discover the
unknown unknowns, right?

Because just because they're
unknown to me doesn't mean that

they're unknown to everyone.

And so you start with, , and I
look at this as , there's some,

uh, heart materials, right?

That if you, if you hit it with a
hammer, right, you get cracks that

kind of spider out from the center.

Right?

I look at this as sort of the same
thing, , you have your client or

your person that you're engaged
with directly on this process.

? And they're talking to you about
all the stuff that they think that

you should know, but not the stuff
that you think that you should know.

?
And so what you want to do is
use that person as the center.

of this nexus and help and have them
spiral out from the center to all

of the people who are involved in
this process that they know, right?

And then you're going to do the same
thing with every other person in the

network that they light up for you.

. And, ultimately, as you talk to
more and more folks, more and more

nodes in the network, I know I
started talking about cracks, but

now we're on networks and nodes.

But as you light up more
nodes in the network, right?

And you interrogate those eventually
you get a complete picture.

Right of everyone who's involved in
this process based on talking to every

note, listening to every note, taking
notes about all of those conversations

and building upon all of that
knowledge again and again and again.

And

Duke: Dude, can you, can you imagine how
much more successful CMDB implementations

we'd heard about if they looked at it
from a people perspective like that?

Not, but not just turn on
discovery and see what happens,

CJ: right.

Duke: but more like, okay,
let's just start with servers.

who cares about servers?

CJ: Right.

Duke: Well, I mean, the server team
cares about servers, but why do they care

about But who else cares about server?

Are servers like assets?

Does asset management care about servers?

Does it, does Are the
servers ever audited?

Does an auditing team care
about servers in a different

way that the server team does?

CJ: and who do they know
who cares about service?

Right.

Because they,

Duke: you start with the who,

CJ: yep.

, Duke: and figure out who
all is involved in this.

CJ: Yes, absolutely.

Duke: So the pieces on the
chessboard, the cast of characters,

CJ: Yeah.

Yeah.

Duke: to bring order to chaos
is understanding the players.

This

CJ: Yeah.

, that's probably the first
place that I'd look.

, the longer I do this Duke, , and
by this, I mean, it in

general, but also service now.

The more I realized that there is a huge
black hole around people, and it is the

single most important part of our jobs.

And, I can't speak for generations
that have come after me, but I know,

as I was coming up in IT, a lot of
the attraction was being able to

tinker and automate and do things
with technology that didn't involve,

Me talking to other people, right?

That was kind of, the thing that,
attracted me to the industry.

But again, the longer I'm here, the
more I realized that really it's all

about the people and it's really all
about, talking to folks and getting to

understand it so that you can do the
tinkering thing that we all got here for.

Duke: is kind of like why I was
blessed by not being super hyper

technical in my start in IT.

Because like, I had to ask
questions just to understand enough.

CJ: Oh yeah.

That's a good

Duke: know what I mean?

To add, to add enough value.

Cause I was dumb.

I didn't know it.

CJ: Yeah,

Duke: And so just be like,
explain that to me one more time.

Explain that to me.

I just got good at asking for the
explanations and then writing it down.

so I can research stuff later.

Or so that.

Or I could, bring it to
somebody who did know

CJ: yeah, you know, I had a boss
duke, , non technical, right?

, and he would always say,
explain like I'm five, right?

And this is pre Reddit, right?

Or at least pre that sub, we
get to the point where we started

like getting to the point where
we're talking tech over his head.

And he just, he stopped us.

He slowed us down.

He's like, all right, look, talk to me.

Like I'm three, say that again.

Like I'm

Duke: hmm.

CJ: So, cause I got to take what
y'all telling me and I got to go

advocate in the boardroom for this,
And I got to be able to talk to these

people and they don't know either.

. And they expect me to know.

So you got to explain to me
how I can explain to them.

and I think during those conversations,
it allowed us to understand what we

were trying to accomplish more too.

So I do think there's a lot of a nugget
of truth to your point there, Duke, about,

you starting off and not being technical
and having to ask all of those questions

probably led you to where you are now in
terms of being able to hop in into the in

and out of these kind of projects, right?

And work with a client and get that
value that you get for them, right?

Because you pop in and you know
the questions to ask because you've

been asking them all your life.

Duke: Okay.

I got a different one.

You always know generally where you are.

they'll say, oh, catalog
sucks or SPM sucks or.

You know, something sucks, but
you like, you can gauge where

you are by that one big thing.

So it pays to know and understand
and be able to explain what

an ideal state looks like.

And

CJ: Ooh, yeah, yeah,
yeah, yeah, yeah, yeah.

Duke: beyond just, Hey,
I'm this process sort of,

CJ: hmm.

Duke: comes from experience in contention.

Like, but how do I convince you that this
is the best idea, but also how do I,

keep relearning this with catalog, right?

So, in my latest, Hey,
Robert, catalog sucks.

, help us out.

Hear the chaos.

So, I built this,
catalog item owner guide.

CJ: Okay.

Duke: And I don't just come to
these, I don't come to the table

and just say, where does it hurt?

because frankly, they don't care.

If they could snap their fingers and
make the whole conversation go away

and a catalog item, they do that,
they're not interested in service now,

CJ: Right.

Yes!

Yes!

Yes!

Duke: I make this, owner's
manual for catalog items.

And the first thing it does is they're
like, why do these things matter?

did you know that?

This can orchestrate the
efforts of multiple teams.

Did you know that it can
control approvals for auditing?

Did you know that with some extra time,
we can actually get systems to talk to

each other in a flow so that you don't
actually have to do the manual work?

And so it's kind of what's in it
for you, And what's in it for the

organization so that they have a
context of why we're sitting there.

Like, why am I taking your time?

CJ: but it also gives them a
context on how to talk to you.

You think about that, right?

Like you've,

Duke: me more about that.

CJ: yeah.

All right.

So by you giving them , this manual,
all right, on how to catalog works,

it allows them to think about, , it
allows them to internalize, right?

How the catalog works alongside,
you their work processes.

And now, they can have a conversation
with you about things that they need in

the context of a shared vocabulary, right?

Around catalog, right?

Duke: Yeah.

CJ: you know what I mean?

Duke: especially, right.

Isn't it awful when somebody sends you
an email and you've got to extract, like.

Maybe it's a three step process,
but it's all just like information

in the text of an email.

CJ: Yeah.

Duke: Well, that's what you're
getting in a generic service request,

CJ: Yes.

Duke: So wouldn't it be nice if
for everything that we knew how to

do, here's the precise questions
we need to know and nothing else.

we asked them to answer
just the stuff we need.

And then the flow automatically starts.

Anyways, like

CJ: no, dude.

Duke: catalog is the, is, is like the
most like recent thing for me on this, but

like this exists for freaking everything.

CJ: Dude.

It is.

Duke: Asset, SPM, take your pick.

But I think what I'm trying
to get out here, sorry, I

know you're trying to get in

CJ: No, you're good, man.

Duke: what I'm trying to articulate here
is it takes more than getting certified

and air quotes, knowing it, it takes
a mindset of understanding what those

prime value drivers are for any 1 thing.

And being able to talk in a
convincing manner about it.

I would say this even includes
maybe having some slide where

that you can quickly like pop up.

Like now I've got this, this
catalog user guide thing.

I'm like, I'll never be without that.

I wish I had built it 15 years ago
when I did my first catalog, like,

CJ: Yeah, yeah, it definitely,
it definitely helps.

, being able to go in and, have an
anchor point where you can start a

conversation and you know, I think
that the anchor point can't really be.

Because not everyone knows tech , and
a lot of people are intimidated by it.

And a lot of people who are
intimidated by it, want to ignore it.

, and often those people are
decision makers, right?

So you got to figure out how to talk to
them in a language that they understand

in order to get things done that they
are, they're actually hiring you to do.

And that difficult sometimes.

Right.

,
Duke: Oh, especially in service now too.

Cause I don't think we fully appreciate.

How not cool

like having to use ServiceNow
is when you're not a ServiceNow

admin developer or whatever,

CJ: yeah.

Duke: and you just kind of like think
about every single time you didn't.

put a story in, or a project, or
an incident, or a catalog item

for the thing you're about to do.

You just went ahead and did it, put it
up, they said, and just like, because

you'd rather be doing the thing you
need to do than doing the bureaucracy

around the thing you need to do.

CJ: Yeah.

Duke: And we don't fully appreciate
how especially in implementations that

have just been seen in their pants.

You know what I mean?

Maybe low training, low quality, it's
a burden for people to put these, you

might be walking into a team that's
, maybe the only thing they get is the

results of generic service requests and
they get hundreds of them in a week.

You know what I mean?

And then asking those people about,
let's break down the process and stuff.

And they're just like, whatever,
dude, get me like two category

fields and I'll be great.

Transcribed

CJ: yeah, just give me something
I can group things on and triage a

little better than what I got now.

Duke: that's right.

So you gotta, give them a carrot.

You know what I mean?

You gotta lure them with bigger value.

Got like five minutes left.

I got one more if that's okay.

CJ: go for it man.

Duke: We actually have a whole bunch more.

It's probably like a second episode.

CJ: Yeah, I know.

I know this.

This kind of became a lot
more about like, it's weird.

Like it.

No, keep going.

I love it.

I love it.

Keep going.

Duke: The next one is be the
best PM you possibly can.

CJ: Yes.

Duke: You know, I mean, not your job.

I get it.

I get it.

But, if we want to be dragon slayers
and part of being a dragon slayer is

slaying big dragons and the biggest
dragons are all like of unknown size,

then you got to learn how to be a PM to
the best of your ability, because the

sooner you can start talking to your
stakeholders about how long it's going to

take and who you need to slay the dragon.

the better it is for you,
They're just like, I need a plan.

I need a plan.

Now, ideally they want to have a perfect
project breakdown structure, all that

stuff, ideally, but you can give them the
next best thing, which is like, listen,

I know we have these amounts of work to
do, So as soon as you know, you have a

task, you need to get done, write down
the task on your document in service.

Now don't care.

Right.

And as you discover dependencies.

Write those dependencies down and as
you're able to put rough orders of

magnitudes around each of those tasks
and it gradually creates a bigger

picture and the more iterations you
get of it, the better the picture gets.

CJ: Yeah, that's entirely true.

And I think there is a, push, , due
to immediacy in our culture, right?

That you have to have , the answer right
now based on whatever limited amount of,

information and scope you've been given,

Duke: And.

And there's this idea too of the
requests are in, you should just

figure out that there's five.

Okay.

I'll take a real world example here.

We've got like 15 requests
to ulcer notifications.

And they're like, just, figure
out how long each of them is going

to take and do them in order.

But what they're missing is Just
because some rando said, I think

notification should work this
way doesn't mean you do that.

Is that person the process owner?

Are they even a high frequency
participant in the process?

Or are they just voicing their
opinions into the task module?

You understand what I mean?

So it's

CJ: Shouting into the
void, causing the chaos.

Yeah.

Yeah.

Duke: at least they got it into
the task, but, we know we have to

adjust these notifications, but
you know what else we have to do?

We have to form like this place.

I'm saying it just because
this place doesn't have it.

We have to form like a council
of people, like the process owner

and a few of the key, key, key,
users, power users of that process.

So that we say, we're thinking of
modifying the notifications in this way.

So that's a task too.

And it's got to be the 1st task.

Establish the council.

Okay, then the next thing
in that project for me was.

write down an SOP for notifications,
these are our rules of engagement for

doing notifications that had to come 2nd.

Okay, now let's take that pile of 15, some
of which we can be dismissed immediately.

And others just get wrapped up into the
project, but have to act like a PM and

collect to dues and write them down.

CJ: those things become action
items , that need to be taken care of.

And look, you know, I, I, I have figured
out based on my, public service, , that

corporations do meetings way wrong, right?

And that's the best way to do a meeting
is, , by using Robert's rules, right?

And, and Duke, I didn't, I
didn't know you had rules, but

you know, I'm glad I found them.

Duke: you're welcome.

CJ: And, and so let me tell
you , the items here that I think

are the most important, right?

So one is the agenda, in government
in Illinois, an agenda has to

be published, I believe it's 48
hours before a public meeting.

. And that agenda contains all the items
that you are allowed to talk about.

notice, I didn't say all the items
that we might talk about, you

know, or all the items, right?

Yes.

This list of items are the
things that we must talk about.

And only this list.

and it must be provided
48 hours in advance.

So everybody's got a chance to
look at it before you get here.

Right.

So that's, I'm telling you do.

And then, after every
meeting, there are minutes.

Published those minutes, record
the actions that were taken and any

pending actions that need to be taken.

They record who needs to take those
pending actions, or they record who

took the actions in the meeting.

So now you not only have this constrained
list of items that you can only talk about

in the meeting, you also have this list of
to do's and to done's or to do's and have

done's, That came out of that meeting.

So now you are one step ahead of
how do you schedule the next one?

And what do you talk
about in the next one?

Now, there's a whole lot of other stuff
that happens, , during the meeting that

Robert's rules governs to, but for me,
in terms of applying, public meeting

methodology to corporate meetings,
those two things , are ultimately, I

think, would improve, , meetings like
a whole lot at a corporate level.

Duke: Okay.

That was a lot of different points.

, I hope you guys found
some wisdom in there.

let us know if you want us to
dive deeper on this kind of stuff.

Maybe have a second episode, just let
us know in wherever you see this posted.

CJ: Absolutely.

And, uh, yeah, it's always,
it's been a pleasure.

I'll let you later.

Duke: one.

CJ: They don't know outro.