Disciplined Processes for Resilient Growth

I hear it a lot: "Paul, I'm not a robot." In this episode of Resilience Talk, I explain why methodical, disciplined processes don't make a business rigid or slow, I share a story from my software days when a simple process meant three-hour days while my teammates worked ten, and I walk through a quick way to start making your own processes visible. It's how a business stays resilient through plateaus, recessions, labor crunches and, eventually, succession.

Connect with Paul
Website: https://www.secondnature.solutions/
Subscribe to the newsletter: https://www.secondnature.solutions/join
LinkedIn: https://www.linkedin.com/in/paul-spencer-7252118/

Chapters
(00:00) It's all about the process
(01:37) Methodical and disciplined, not robotic
(04:04) Three-hour days on an airline project
(11:27) What this looks like in your business
(15:45) Discipline equals freedom
(16:42) Make your processes visible
(22:50) How processes build resilience

Creators and Guests

Host

Paul Spencer

Family Business Advisor

What is Resilience Talk?

From Paul Spencer of Second Nature Solutions, a conversation about the complexities and nuances of building resilient family enterprises, especially in the face of economic and political uncertainties that loom on the horizon. See more at secondnature.solutions.

Welcome to Resilience Talk hosted by
Paul Spencer of Second Nature Solutions.

Let's dive in.

Sometimes I know I sound
like a broken record.

It's the process.

Why don't you put the process?

You know, it's all about the process.

If you had a process…

And that's my broken record, and I
understand that I say that a lot,

and, uh, even when we talk about
training and leadership and, uh, how

we communicate with each other or
with our staff, I end up inevitably

saying, "Well, that's the process."

You create a process
about how you communicate.

You create a process about
how, uh, you update or gather

feedback, uh, from each other.

How you send emails is a process.

How you answer the phone is a process.

So I get it.

It's annoying.

But one thing that I wanna be able to
share with you is when we were talking

about, um, um, previously we were talking
about the evolution of the business and

how we go through the various S-curves
and how we build, um, extra capacity,

more capability while we're going through
the growth pattern so that we have

momentum to keep going through the next
S-curve so we don't stall out, right?

To me, that is also process, um, but
from a point of view that it's methodical

and disciplined, but not robotic.

Think sometimes, uh, what I gather
from, from just interactions with

you and feedback that I get is
that, "Paul, I'm not a robot.

Paul, I can't just follow four steps
and assume that that's going to s-

make a decision or solve my problem."

Um, uh, so I think it's import--
This is what I wanna talk about.

Having processes is
methodical, disciplined.

It's not rigid, right?

It's not robotic.

It's not stuffy.

It's not limiting.

And it's not, certainly not slow But
I feel that, uh, when we do have these

conversations, unless you actually observe
and see within your business the opposite

of that, the growth that you have, the
creative, uh, outside-the-box thinking

that you get, the divergent thinking,
the speed to decisions because of your

processes, you tend to have a little bit
of doubt about, "Geez, what am I gonna do?

I'm gonna write a process for everything?"

No.

Um, but it's important to be
thinking about, how do I repeat this?

How do I create some consistency around
some of the, what I would call the soft

parts of our decision, um, processes,
which is what I was just describing about

how we make decisions, how we communicate.

Those are soft processes.

Some of the hard processes are
more what you're thinking about,

which would be if I'm baking a
cake, there's a recipe, right?

If I'm at P&G and I'm making
Tide, I follow a recipe.

And is that stringent?

Is that robotic?

Uh, you can use your judgment on that.

But there is a recipe to follow Um, so
there's two different types of processes,

and we need those two processes in order
to have predictability and consistency and

high quality coming out of our business.

This is also how we have
resiliency in our business.

So, um, one thing that I think is, uh,
well, at least, at least fits for me.

So, uh, during my time as a
software developer, I was…

This was probably 2007 or '06.

I was working at, uh, as a, as a
subcontractor, um, at a place, uh,

that was at the airport and was a
regional commercial airline, right?

And, uh, what we were doing was building
a new architecture for their scheduling

system, scheduling of flights, uh,
which actually is kinda cool because

you get to learn, I do, um, in all the
different industries that I've worked

in, building software, building products,
um, coaching and advising you guys.

I get to learn all these different
industries, which for me is tons of fun.

So in this case, um, inside
the scheduling system, uh, you

have to think about the crew.

So from the airline staff, meaning
the, um, uh, the stewardesses that are

in, on the flight, right, to the crew,
which would be a co-pilot and a pilot,

all of those get different schedules.

All those people get different schedules.

So it's not unusual that the pilot and the
co-pilot, when they go from Cincinnati to

Chicago, they go on a different flight,
and the, and the, um, stewardess cloo-

crew goes on a different flight, right?

And then you have the equipment,
which is the airplane, and

that's going different places.

So you have to schedule all of that
together over, uh, various flight

patterns, flight schedules from Cincinnati
to Chicago to LA and then back, right?

Which may have different crew, which
may actually switch a plane for whatever

reason, or you even have mechanical
issues, and so now the plane is left

in LA and they swap out a plane, right?

Anyway, my point of that is
there's lots of complexity.

So from- And this is my
point about having a process.

So from my perspective, I've always been
taught, um, to have a process when I,

when, whenever we wrote software, right?

And so we can get into that.

I'm not gonna explain all of that for you.

But my process was, uh,
something that I followed.

I was able to test what I did.

I was able to prove different scenarios.

I was able to have a simple design
because of my process, right?

And so when we got through, this
was probably a year-long project,

we probably got maybe five months
in, and Paul's portion, we did it

in different segments, modules.

My, uh, my personal, I was my own
team, um, my portion was done, right?

And so we went through testing, and
so I had maybe three or four issues

that I had to resolve, and because
of my process, I was able to resolve

those in each one in probably an
hour, maybe two hours at the most.

I could resolve them, they go through
testing, and we're all good, right?

So because of my process, I was able to,
uh, develop high-quality outcomes, right?

Um, as compared to some of the
other members of my team who

didn't really have a process.

They were doing what I would call
the normal development cycle, which

is, uh, just kinda going through it
and not having a discipline, right?

A methodical discipline
about what you're doing.

And so we get to that testing phase,
and, uh, they had many errors, many

things that weren't working, and, uh,
when you were to sit down with them

to try to help r- run through it,
because of the lack of methodology,

the lack of discipline in their code,
it was very complex and very difficult

to understand how to solve the issue.

And so for me, if we, if we do a
comparison, into the testing phase, I

had, quote-unquote, three-hour days.

Whereas other members on my team,
and this is no joke, they're working

10-hour days because they're constantly
trying to figure out what's wrong.

My process created certainty,
created predictability

about what my code would do.

Their process led to no idea High
variation of outcomes, uncertainty

about what's affecting what, what
dependencies are driving whatever, right?

Thinking about from a
coding perspective, right?

What does that look like
emotionally during that phase?

I'm relaxed.

Even when the testing, the quality
assurance team finds something, um,

unusual or wrong in my module, I'm
relaxed because I have a process

to follow, and I can go in with
certainty and determine what was

wrong, fix the error, and sometimes
that takes a little bit more than just

tweaking this there and, and maybe…

But it gives me certainty on what I'm
fixing and how I'm fixing it, right?

As opposed to the emotional state of
the other members on my team, high,

high stress, high anxiety, because
this is what happens is in that moment,

they are realizing, "I may not be able
to deliver the outcome necessary no

matter how much time you give me, how
much more time you give me," right?

And now they're under the gun, and now
they've got such a, I'll say, a mess

in how they architected their code
that they can't even get out of it.

They don't even know what it does, right?

So anyway, that's an example of
being methodical, being disciplined.

Now, in that process, was I a robot?

No, because inside that process is
built, uh, space for high creativity.

I am being uber creative inside my
process to build a simple system

that produces certain outcomes.

And I should say it in a different way.

High predictable outcomes.

I can predict what the
system will, will create.

Now, you may say you may not understand
exactly what I'm saying, but I want

you to, because it's code, right,
and software, you don't understand.

But I want you to take everything I just
said and turn it into your business.

So what is it that we deliver that, uh,
we cannot be certain on the outcomes?

We can't predict the outcome

What is it that, uh, when we ingest
a, a, a new deal and it goes through

our system and we have, uh, no idea
when it will be done, or we have

low certainty on when it will be
done or the quality of the outcome?

How many times have you experienced
high, high stress of trying to get

something out the door or over to your
customer, either as a product or a service

Because of a time crunch, because
of something that you've done wrong,

and now you have to adjust, or just
because you don't have a disciplined,

methodical process to follow, and now
you're just confused about what I need

to do next, how this fits with this,
and you've got a messy desk, right?

Just create an analogy of a messy
desk, and I don't know where to

start or how to finish this thing.

I guarantee you, you've all
experienced that, and some of

you are still experiencing that.

Now, that is not a bad thing, right?

That's not a, "Boy, you're,
you're not smart enough to

know how to run your business."

No.

The point is, in order to be
resilient and in order to be able

to evolve your business through the
S-curves, you must have methodical,

disciplined processes in place.

Otherwise, you get confused,
and it gets too complex.

So a process should simplify.

A process is discipline

Uh, if I'm a painter and I like to paint
on a canvas, landscapes or whatever,

contemporary art, I guarantee you
a artist, an artist has a process.

Now, it may not make sense to you, it
may seem total inspirational, chaotic,

but they are working within a process.

They're disciplined, and
their process gives them space

for the creativity, right?

All right.

So again, it's not stuffy, it's
not robotic, it's not slow, right?

As demonstrated by my example
with the airline, right?

I'm working three-hour days.

I'm actually done sooner, and
tested and done way sooner than

the person who had no process.

So it's not slow, it's faster.

And you compound that over the life
of your business and over all the

people working in your business, all
the departments in your business,

all the disciplines in your
business, and that adds up quick,

and that is competitive advantage.

That's why you will be more resilient
than the other competitor who just

goes by the seat of their pants
when you have tough situations.

Let's say you have a recession or, uh,
you have a downturn in your industry.

You have disciplined,
methodical processes.

You have lots of over…

Uh, not overhead.

You have lots of leeway
within your, your work, right?

'Cause it doesn't take you
10 hours to solve issues, it

takes you three hours, right?

The, as a comparison, right, it
took that person 10 hours a day to

try to resolve their issues, where
it was taking me three hours a day.

And really, it was probably a week's
worth of my time, and the next four

months, I'm just kinda hanging out
and trying to help those guys the

best they can, best I can, right?

I'm done.

So this is how we wanna be thinking
about it, is discipline equals freedom.

Actually, uh, Jocko, if you're familiar
with Jocko Willink, right, he says that.

Discipline equals freedom.

And when you're disciplined in your
processes, uh, it gives you way

more flexibility, how to move, how
to invent, how to innovate, how

to, how to bring quality, right?

Uh, my example, you know, Deming
says quality goes up, costs go down.

M- my airline example is
a perfect example of that.

My quality was way up and
costs were down, right?

Meaning I didn't have to bill extra time.

I didn't have to be-
bill five more months.

I was done Right?

Quality goes up, costs go down.

So now in the moment-- So let's
think about it, uh, from a point of

view where you, uh, lack processes.

So everybody has some processes.

The question is, is are you
consistent with running them?

And so if you don't have your processes
made visible, and you can't share

them with others, then it's a high
probability you have lots of variation

within the outcomes of your processes.

Right?

So, uh, when you're in that moment, you
don't-- you're not, you're not really

thinking about, "How do I document
every single process in the business?"

Right?

You're in the moment.

So if you and I are working through a
solution, and I'm the manager and you're

the staff member, you're the worker,
uh, we may be talking about something,

and in that moment, we get to ask
ourselves, "Is this useful to remember?"

Right?

"Will it help me communicate and make--
Will it help me communicate with others

this process so that we don't have
to have this discussion every time?"

Right?

"And will it help me to make
this visible right now?"

The process, make it visible.

Now, making it visible could be a
couple of boxes, a workflow that you

draw on a, on a, on a whiteboard,
take a picture of it, throw it into

a, uh, a shared drive or throw it
out on Slack or Teams or wherever.

Right?

Making it visible could just be a one-page
document that says, "Here's the aim,

here's the, here's the five steps, and
this is how you have a conversation."

Right?

Um, and That's what you're after.

That's simple, right?

So in the moment you're asking your-
yourself those questions, you're thinking

about, "What can I do so I don't have
to repeat this conversation, and what

can I do to make this more consistent?"

Um, that's the moment where
you, quote-unquote, "create your

process," making it visible.

Um, by doing that, just by doing
that alone, will ma- naturally

make that process better.

What do I mean by that?

Not because I'm sharing it and
I'm handing it out and I'm, uh,

making everybody do that process.

Just the part of me saying,
"Is it useful to remember?

Will it help me communicate with others?

How do I make it visible?"

And I go through that process,
say a half hour, hour at the most.

I wouldn't spend more
time than that, right?

Just by going through that process
of documenting it, making it

visible, will improve that process.

Because now I intentionally, right,
methodically, discipline, in a disciplined

way, have to write down my thoughts.

What is the aim?

What are the steps?

What is it that makes this successful?

What's the waste in this, right?

I don't want you spending
two hours on this.

This process is a
30-minute process, right?

Just by doing that, you will learn so much
by having to put it on paper b- to be able

to communicate it and make it visible.

All right, so that's the first step.

That's, that's what we call in,
in programming, step zero, right?

That's zero.

All right, as we do that over time,
either I do it or I'm encouraging

my staff to think this way or my
management team or my executive team,

right, um, to think in this way.

In the moment, is it useful to remember?

Will it help me communicate
and make things visible?

Document it.

And then again, like I said at the
beginning, what I just said is a process.

So what's the process of documenting it?

What's the format?

Where do we keep it?

Are we cool with just pictures?

Do we want Word documents?

Is it going out on Drive?

Right?

That's all a process.

All right, so we do that, and
then now, uh, step one through,

right, is over time we start to
stack up a visible, viable system.

So it doesn't take long.

Maybe, I'd say in a month you
will have a core set of processes

documented in this way that start
to create some methodical discipline

in how your business is running.

Now, uh, you may find, um, the
law of diminishing returns, right?

We're not looking to document everything.

Some things are not worth documenting.

However, if you're in this moment
where you have nothing documented,

by going through that rubric of is
it useful to remember, will it help

me communicate, you'll probably
over-document, and that's okay, right?

Just do it.

Um, and as you start to do it, you'll
become more disciplined about what it

is that you document, how you document,
and you'll have a better learning about

what is useful to remember, right?

And these things start to stack up, and
now we're starting to get more visibility

into actually how our business runs.

And some of those processes over
time will be more useful than others.

What you'll find is the Pareto
principle, right, the 80/20, and

you'll be finding that 20% of your
processes drives 80% of your business.

And so those 20%, the ones that you've
documented, and you've probably maybe,

let's say you documented half, right?

So those other 30%, you probably
never use them that much or at all.

But who cares, right?

The, the point is to start creating
a discipline about how we communicate

and record our processes, right?

All right, uh, just one last thing
with all of this is this is how

you create a resilient business.

This is how I become a, uh,
worthy competitor in the market.

This is how I become, uh, a competitor
that is hard to keep up with

This is how we build resilience
through our S-curves.

When we have recessions, when
we take a huge revenue hit, when

we have, like we've had over the
last several years, labor crunch.

This is how we deal with
inflation, which we've had over

the last several years as well.

This is how, if we've ever had, ever have
a deflationary period, this is how we are

resilient through a deflationary period.

This is how we manage growth.

It's a good distinction because
sometimes when we're growing,

it's easy to just go do stuff.

It's when we start to hit our growth
plateau, or we get some of these unknown

black swan events, right, where we
get a recession or we lose a customer,

major customer, we get labor crunch,
where our business starts to get shaky,

and we don't know why or we very much
struggle with that because we don't

have methodical, disciplined processes

So growth is easy

to survive without your processes, right?

This is how we get innovation.

Because if we have these things
running, we have processes on how to

innovate, we have capacity to innovate.

And finally, maybe even the most
important for a lot of you, right,

this is how you deal with succession

So methodical, disciplined
processes are resiliency