- The final principle, principle #9,
decentralize decision-making, is also a leadership principle
It's easy to say and hard to do,
and I think it's often misinterpreted,
kind of like the agile manifesto.
Easy to say, and easy to misinterpret.
The reality is, it's not quite such a simple thing.
Not every decision is decentralized.
If I'm a new software developer hired at major healthcare
manufacturers to build an MRI machine, I'm not going to be
asked should I be building an MRI machine.
The fact that we're building MRI machines is a key element
of strategy the company. That's a centralized decision.
We don't poll a thousand of our workers and say
what should we be building. Those who have the specific
responsibility for strategy make that.
So, there are certain types of decisions that are
centralized, but many, many more, orders of magnitude more,
that are decentralized. Well, how do we parse them.
I think the easy way to parse them is kind of in these
categories. Some things should be centralized.
A decision that's infrequent.
We're not going to change platforms very often, right.
We're hosting you folks, our users, on a platform,
and we move from an old platform to a new platform.
And we're not going to make that decision more than once
a year. It's a really big deal,
and it's really hard to migrate.
Not going to be very often.
Is it long lasting?
If we make the right decision we should be able to stay on
that platform for years. Should be able to thrive on that
platform for years to come. Okay.
Does that significant economist go.
Absolutely, it does.
We got a hundred thousand people.
We need to support em on a single platform.
The old platform isn't scaling.
We certainly don't want to replicate platforms and then
database sharing absolutely does.
That decision, that we're moving to a new platform,
and to a certain extent what platform we move to,
needs to be centralized because it meets all of those.
Now, let's talk a little bit about what kind of platform.
Now we start to get a little bit softer.
So, let's... well, let me go to the extreme case.
What kind of decisions are frequent and common everyday?
Do you even program backlog?
Right? Product-owner decision making.
How to test the thing.
What are time critical?
If the decision isn't made right away,
we're really going to hurt.
We're going to blow the sprint,
we're going to blow this PI.
What if they require local information?
We can't design it this way.
We want to code it and the schemer doesn't support it.
We have to extend the schemer and we don't have the ability
to do that here. Okay. So, we have specific and local
technology, or customer contacts to help make the decision.
It's a local decision.
So, centralizing and decentralizing depends,
and it depends on scale.
So, let's just take something like single sign on.
A centralized decision might be to we should have single
sign on across our sweet of products.
That would make sense.
It might not be to the particular benefit of any one
point product solution provider to say they can get to my
stuff easier from another application.
Now, that might not be their big concern.
We think about how to implement single sign on in our
contextual area. Well, let's empower everybody.
I've had exactly this case.
Ten teams with a mandate to do single sign on pick largely
ten different technologies, things that were convenient
for them, things that they're familiar with, whatever.
Now, that exaggerates a bit, but it was definitely more
than one. Well, you don't want four single sign on
technologies. You want one, right? Because that makes the
efficiency much higher, implementation much higher, and,
probably, most importantly minimizes the security holes that
you're going to get in your authentication protocols.
So, where does that decision ride?
Well, to a system architect it's probably a central decision
We're going to pick this particular protocol for single
sign on. To a development team might be well they made that
a central decision now I need to implement it.
Well, the system architect doesn't have a domain or concern
about how you implement single sign on the protocols been
chosen. That's a local decision. So, what you see is the
toys my kids used to have. Those little spider-like things
where you throw them on the wall and they flip down, one
after another. Single sign on, that's a corporate-level
decision, but there's no how in that.
The how of single sign on, that's a system market level
decision, but there's no how... that selection is a protocol
but not how to implement. The how becomes the team's
responsibility. So now it's such a simple thing.
Now, if you're struggling with that notion,
or starting to think about, well, I bet that doesn't work
here because we run a nuclear submarine. We can't have
people making decisions that might effect the safety of
the crew. I offer you a different alternative. Stop now.
Take ten minutes and watch this short video.
Decentralize decision-making and nuclear submarine command
by David Marquet. He's written a book on it, and he's done
a number of talks on it. He talks here.
In ten minutes you'll understand how the commander of a
nuclear submarine learned to decentralize decision-making
and improve safety and performance of one of the most
mission critical systems in the world today.
So, go ahead. Take a minute. Actually, take ten.
Wasn't that a cool video?
I particularly like the Russell Crowe joke in there.
What did we learn from that video?
We learned that it's simply impossible for any executive
to know the details of a system as complex as a nuclear
submarine, or a brand new interactive website we're building
They can't know that.
So, what they can do is say here's the commander's intent,
and when you look and say if you see this box up there in
the large, solution level called solution intent...
Here's the intent. The intent is to submerge the submarine.
The intent is to do single sign on.
That's it. Okay. I can't tell you how to do that.
The systems we are building now are so complex that it's
simply impossible for anybody in a command and control
center to make those decisions. If it works on a nuclear
submarine it sure ought to be able to work a natural
development. That's a really cool video.
Here's a brief exercise that you can do in the next five
or ten minutes. Consider three significant decisions you
are currently facing, or maybe you already looked at them.
Okay. Write it down. There's three on the left there.
Rate each item using the table below.
This is going to do a little quantification for you.
So, the way you rate the decisions...
Frequent. If it's high frequency you go to the yes scale
with a two. If it's time critical you go to the yes
with a two. Does it have a significant economies of scale?
The clarity has to be reversed for that.
If it has significant economies of scale, then no, we give
it a two. Okay. So, let's just take that example.
That would add up to a six.
Wow, decentralize that.
What you'll find is that there are things that are clear.
Things like tooling, single sign on protocols, mission,
commander's intent that get centralized,
and things that are in the middle like how we do single
sign on, the protocol we choose where you're an architect
looking at the system level, or are you an individual at
the team level, and things that are clearly local
like the decisions the product owner makes.
This will help you navigate your migration as you become
a lean-thinking manager teacher to better decentralize
decision-making in your organization without aggregating
the responsibility that leaders have to set the mission
and strategic direction.
We spent quite a time in this module.
I don't apologize for that because I told you up front that,
of all the modules in this course, the one that lasts the
longest and you'll return to the most often is this one.
I'm doing a little talk at an upcoming summit on my own
personal leadership journey, and I'm going right back to
these principles and say this is where I went whenever I
had a question about that.
However, I also have to admit that we talked about the
abstract. We talked about things to think about.
We talked about pennies. Not your usual stories.
And Dan Pink notes that clarity on how to think,
without clarity on how to act, leaves people unmoved.
So, it's time to end this lesson and get on to put
this thinking to work.
Let's move on to doing in the next lesson.