We settled on three positive characteristics that
characterize an organization that was operating maximal
effectiveness, high flow and that was value, a clear sense of
the value that you're delivering.
Clarity, meaning a sense of orientation, awareness of how
you fit into the bigger picture and flow is the result of having
a clear sense of value and a lot of clarity.
Then you can get flow in the sense of smoothness of action.
Hey everyone. My name is Henry Surya Virawan
and you're listening to the Technically Journal Podcast, the
show where I'll be bringing you the greatest technical leaders,
practitioners and thought leaders in the industry to
discuss about their journey, ideas and practices that we all
can learn and apply to build a highly performing technical team
and to make an impact in your personal work.
So let's dive into our journal. Hello, Steve.
Hello, Andrew. Welcome to the Technical Journal
Podcast. Today we'll be talking about
your new book, Flow Engineering from IT Revolutions.
I'm really excited actually when I read the book as part of the
preparation of this talk. So Flow is something that is
quite a trending topic these days.
So many people are talking about it, how to improve your value
stream and things like that. So really excited.
Welcome to the show. Thank you so much, Henry.
Yeah. Thanks for having me here.
All right. So Andrew and Steve, so I always
love to ask my guest to first share a little bit more about
themselves. So if you can maybe mention
about highlights or turning points that you think we all can
learn from you, that will be great.
I've been in tech for a couple of decades now.
I started in kind of IT and tech support and work through a bunch
of different individual contributor roles.
And Speaking of turning points, I would say that DevOps was
definitely a turning point for me.
I was always kind of one of those people who was interested
in the gaps in the handoffs and flow before I really knew that
that's what I'd refer to IT as nowadays.
But another big inflection point was taking on a role as CTO and
and being very responsible for end to end delivery and scaling
an organization, especially working with enterprise clients.
So kind of put everything to the test and learned a lot and
failed a lot and and brought a lot of that into consulting.
So that's kind of my path. And working backwards, I guess
Steve and I met each other three years ago, Steve at DevOps
Enterprise Summit conference where he was running a session
on Value stream mapping. And I asked him for any book
recommendations on value stream mapping for tech organizations
in particular. And he we ended up having to
write it ourselves because many of the books on value stream
mapping cover center of gravity more focused on the traditional
manufacturing space. So my background.
I had studied engineering, but pretty early on decided not very
interested in a conventional career.
And so I spent about 15 years as a Buddhist monk.
And so it was during that time running meditation Centers for
about 10 years. But also with my technical
background was the head of IT for that organization, a global
organization for a few years. Then over the last 10 years,
while I was a monk, I discovered Salesforce.com as offering free
licenses for nonprofits. And we had a big federation of
lots of nonprofits to me that looked like lots of free
licenses. And so I sort of had this vision
of I can get free licenses here, free licensees here, free
license here, and integrate the whole thing, syndicate some of
the code. And then all of a sudden we
would have some technical management infrastructure to
manage all of these meditation centers, which we were sorely
lacking. I never actually ended up
bringing that to fruition, but that led me to choose to focus
on Salesforce when I stopped being a monk.
And so pretty early on, I was a Salesforce developer.
Pretty early on, I realized there were a lot of struggles
for the development process in Salesforce.
They were just a few years into even being able to write code on
the Salesforce platform. But nobody was using version
control, so there's no history of changes.
So I would write something, come back a month later to, you know,
make an edit, and I'm like, what is this?
Did I write this? Did somebody else write this?
Has this changed that I just forget?
There's just so much confusion. So I started going deep, digging
deep, and I had a manager at the time who encouraged me that we
needed CI for the masses. We needed all of the Salesforce
projects to be able to do things like this.
And I took that Commission very seriously and I've ended up
being focused on DevOps for Salesforce, Kind of breaking
ground with that as a new area for the last 10 years.
Wrote a book, Mastering Salesforce DevOps, my first
book, and was the first book to really speak comprehensively to
the Salesforce development life cycle.
That was about five years ago when I transition from the
tactical bits, you know, version control and setting up Jenkins
and running static analysis and so forth, to when I went to the
DevOps Enterprise Summit, now the Enterprise Technology
Leadership Summit run by IT Revolution.
That was what really blew my mind for the first time, because
all of a sudden it was a room full of technical people, a big
auditorium full of technical people.
But we had doctor Christina Mazlak, the world's leading
researcher on burnout there and the psychology of this, and then
the CEOs and the guy who overhauled Walmart's IT
infrastructure to create an event driven system.
So it's just all of these big thinkers in technology and how
teams work Better Together, the bridge from technology to
business. And I just realized this world
was much bigger than I had appreciated.
And so it really, I've been delighted to be part of the
DevOps community and then increasingly also in the last
couple of years trying to go deep on Lean and become part of
the Lean community as well. And then six months ago I took
on a role as Chief Product Officer for a company that
builds tooling for Salesforce teams and highly regulated
industries, Auto Rabbit. Thanks for sharing your
background story. So when you mentioned about not
many books covering value stream mapping for tech world, I think
now that you said it, yeah, I kind of like agree with that.
A lot of probably VSM comes from the old TPS, right?
Toyota Production system or manufacturing.
A little bit of highlights maybe in some lean books.
But yeah, specifically dedicated to talk about balustre mapping
is probably a bit rare. Hey, thank you for being part of
the technogenal community. This show wouldn't be the same
without your ears, and you are the reason this show exists.
If you're loving TLJ and want to see it keep on growing.
Consider becoming a patron at techlegional dot Dev Patron or
buying me a coffee at Techlegional dot Dev Coffee.
Every little bit helps field the research, editing, and sleepless
nights that go into making this show the best it can be.
Thanks for being the best listeners any podcast could ask
for. And now let's get back to our
episode. And Speaking of which, both of
you have come up with the book Flow Engineering.
So first of all, right, when I read the initial few chapters of
the book, you actually basically first came up with the
background that a lot of problems in the organization
comes from scale. So when we talk about flow,
probably the smaller you are, maybe it's not so much of A
worry and you actually speak about problem of scale in an
organization, maybe let's go there first about the
background. So why do you think that flow
engineering probably is more applicable to kind of like a big
scale organization? Well, one thing that I want to
mention, I'll throw to Andrew for some of this.
But one of the things I I want to mention is you know we had
the great privilege of as a result of working on this book
and diving really deep in this space, building a relationship
with Karen Martin who has written kind of the Seminole
book on Valley Stream mapping back in 2013.
And we learned a lot from that book And what we're really
trying to do with flow engineering is kind of make that
as accessible as possible to an audience that we consistently
here doesn't have time for Valley Stream mapping, can't get
the buy in for it, can't make the space in there doing to step
away from the work and do the mapping and and kind of
understand the workflow and might struggle to describe it to
people or get them excited about something that is largely
associated with manufacturing. So our effort was really to kind
of build upon that foundation and make this very, very hard to
say no, to make it very easy for people to dive in and
acknowledging those aspects of scale that kind of hold people
back from all the things that they want to do, whether it's
value stream mapping or otherwise.
But we do touch on three specific costs of scale.
And one of the things that kind of resonated with me in looking
at why we incur these costs and what sort of happens in
organizations is as we scale up, the distance between everything
in the organization kind of increases.
So the distance between what you're doing and what happens
down the road, the distance between you and the ultimate
mission of the company, you are kind of long term forecast.
You know you have bigger plans, bigger impact.
In a lot of cases, you're physically much further away
from people that you have to work with, whether that's your
colleagues or partners or customers.
And so this distance creates these conditions.
But I'll throw to Andrew to run over the specific costs that we
highlighted because I don't want to run the mic the entire time.
Well, so the three specific costs are the cost of
disengagement, disorientation and distraction.
And very early on in Steve and my discussions, we settled on
three positive characteristics that characterize an
organization that was operating, maximal effectiveness, high flow
and that was value. A clear sense of the value that
you're delivering, including the value that your own efforts make
towards the organization, the value of how your product is
bringing benefit to end customers and so forth.
Clarity, meaning a sense of orientation, awareness of how
you fit into the bigger picture, what the handoffs look like,
what good looks like and so forth.
And flow is the result of having a clear sense of value and a lot
of clarity. Then you can get flow in the
sense of smoothness, of action. And when we're coming back to
the idea of scale, Steve and I also quite early on seized on
flow having two meanings, like there's this sense of individual
flow, psychological flow state. Like Mihai Chick sent Mihai's
book on flow, that when the challenge is well matched to
your capability and you keep increasing your capability and
the challenge keeps getting higher and you, you see people
investing thousands of hours of their lives playing video games,
say, why? Because they get a sense of
flow. You know, the challenge keeps
going up and they keep getting better.
And there's this natural it, it resonates deeply with us.
We feel like we're doing something useful.
So that's individual flow, the psychological flow.
Then there's collective flow. And collective flow is the
handoff from one to another to another to another.
And if you look at these old school manufacturing facilities
where you've got assembly lines, there's just literally a flow of
parts. And especially if you speed it
up, you just see this liquid like river like stream of
material and people and so forth.
And one of the tricky things in the tech world is that
everything we do is invisible. And it was a lean conference a
couple of years ago where once from the stage and twice in just
interpersonal interactions. I heard people say, people from
traditional manufacturing background say, if it's in the
computer, it's hidden. If it's in the computer, it's
hidden because they want everything on big boards and
displays and signs and so forth. And I thought, oh man, we're in
trouble because if it's in the computer, it's hidden.
Like how do we keep oriented? How do we get and maintain that
clarity? Right now, it is computers that
enable us to be having this conversation across the
Internet. Computers enable scale at a
level that was just inconceivable previously.
That even though you've got physical distance and mental
distance and so forth, the computers can help patch in and
create the handoffs and so forth.
But at the same time, when you know, if you and I were sitting
next to each other on laptops, most likely I'm going to be
working on something totally different from what you're
working on. We're in totally different
worlds. And so the default when
everybody's on their own computer is that we're in
different worlds. Whereas if you're in the same
physical manufacturing facility, that the physical world itself
integrates your minds. And so you're integrated around
the physical reality of, oh, there's a mess here and there's
something that needs to be done here.
And here's a guy coming with a request in an order.
And because you're integrating around the physical reality and
then in the IT world, you can't integrate around the physical
reality. So you've got to construct a
reality that people can integrate around.
And if you don't do that, if you don't do that well, if you don't
create an environment where people can really see what's
happening and how they fit into the bigger picture, they become
gradually disengaged. And that's where you got the
Gallup organization saying, you know, 75% of people in
organizations are disengaged or actively disengaged.
And then also if there's just a stuff, you know, emails and
teams messages and Slack messages and documents
everywhere, and so you get disoriented.
It's just more than the human mind can handle.
And I I think even for me, you know in the IT world the pace of
notifications and documents, sprawl and so forth in my level
of patience for figuring out where everything is has gone
down, right. So you get this disorientation
where people just don't know what's going on and then
distraction, bigger organization, more Co workers,
more projects, more people pinging you harder to actually
be in a flow state. And so these we describe these
as the three costs of scale and targeting flow engineering to
address those. Very elaborate answer.
So I would say that I have the opportunity working in a big
scaling up kind of a company. I could actually see all these
kind of cause or problems that you just mentioned, right this
orientation, this engagement and also distractions.
I think in tech world these days, destruction is kind of
like given you know having all these chats and meetings and you
know a lot of things that we have to take care about.
And I think in many organizations the first approach
when they want to increase their business value or be it revenue
or be it more profit or even building more products is
actually to add more people, right.
And over the time they figure out, oh, we have so many people,
things seems to be moving slower interestingly, right.
So it's not as fast as they thought.
And because of that, what they do is actually increase
coordination, the thing that you mentioned in the book, right.
So tell us, why is the danger of this increasing coordination
when people perceive things actually don't work as fast as
they thought it would? Yeah, I think coordination is
really a fascinating thing. And and I think actually
building on top of coordination, collaboration is something
that's very interesting as well. The coordination, the the fact
that we have all of these people and inside of each individual,
they have a representation of the system, right?
They have a representation of the most important thing to
focus on, the essential practices, the most important
people to talk to, who to go to for what, how to prioritize,
what to do in certain scenarios that is so distributed and
different between all individuals.
And it's not often reconciled, right.
We don't often sort of step away from the work to say like how
are you doing, what's your biggest challenge right now?
And we do some of this in stand ups or we're supposed to and we
end up reporting on status and blockers rather than kind of
converging and coming together and we do a little bit of it in
retros. But this is a continuous
challenge and it happens all day, every day.
And so to kind of address this, we do a lot of communicating and
we do a lot of sharing of documents and status updates and
pushing and pulling information. And that all has a significant
cost, right? I mean, it really adds to
distraction in a lot of cases. It can add to disorientation if
you were thinking in One Direction and some information
comes in that pulls you in another direction.
And then you know on top of this coordination idea that we have
to kind of converge and all get on the same page and maybe we do
big room planning every quarter to coordinate everybody.
That can happen. But we also have to kind of
converge prior to doing a release, right.
We have to bring everybody together.
We got to bring in marketing and make sure that they know about
the thing that's going out. And so all this coordination is
usually very active and intensive, right.
It's like it's hands on. It's very manual.
It doesn't really happen by a kind of radiating information
that people can just pull and do their thing and then contribute
back to the whole. It's a very high cost and
collaboration is another high cost, even more intensive
because we're talking about working actively together, which
means it has to be at the same time and we have to be very
closely aligned and we're kind of passing the baton hand to
hand. So I think these are kind of
unappreciated costs as much as they are incredible benefits.
You know, we talked about the benefits of collaboration, but
it's not free. And the less structure it has,
the less culture it has to support it.
And protocols and patterns and guidelines and principles and
just experience of working together, rebuild, rapport and
familiarity, it all is much more difficult.
So you kind of turn the dial of more people and you're incurring
more cost, but there's more risk of miscommunication and all of
these negative consequences. There was a research report that
we highlighted in one of the early chapter on the cost of
scale from Microsoft and Facebook looking at groups from
1 to 32 people and how well they work together and how much
effort was expended by each individual.
And they came to the conclusion that there was just an enormous
amount of it certainly wasn't additive like the 32 people do
not do the work of 32 people, 30-2 people do the work of like
nine people or 12 people, something like that.
And there was a phrase we we settled on the book.
But then nevertheless there are net benefits to working together
as a group. But there's this huge hidden
costs. And so the reason like I love to
Steve's comment, you know that you solve these problems by
hiring new people. I'm sorry it was Henry.
Henry, you made the point that you're solving these problems by
hiring new people. So the organization is scaling
because you want to do more and more and more and you do do more
and you see the benefits of scale.
But there's this profound hidden cost and beneath the, you know,
whatever 10% per year the company is growing, there's just
this profound inefficiency that's cropping up.
And so we settled on the phrase that working together is best,
but it's not our best work. I might be misquoting myself,
but working together is best. But it's not our best work.
Like we're we're not as well coordinated with everybody else.
There's a lot of waiting time, handoffs, confusion, lack of
effort, thinking that somebody else is going to do it.
Yeah. So I like that quote, right.
So working together is best, right?
But we may not produce the best work if your team is not kind of
like highly effective and highly performing, right?
So I think speaking about this study, right, I think one thing
that I also find interesting, in your book you mentioned this
paradox of scale, right? So coming back maybe to the
topic of people getting disengaged or maybe the cost of
scale, so you mentioned that individuals effort actually
declines as the group size grows, right?
So this is actually also a very interesting phenomena for me,
right? And maybe that's why many people
are disengaged in a big organization rather than a small
organization. Or maybe people don't put up
more in terms of effort. So maybe tell us a little bit
more about this paradox. I'll briefly hit that.
It's the same research report, and it does highlight what's
known as the Ringleman effect, which is that as you get a
larger number of people working on something, the effort that
each person exerts becomes less. And if you think about a game of
tug of war, if it's you and another person playing tug of
war, you both will apply maximum effort on the rope as soon as
you get a second person. The two people are not going to
be applying quite as much effort as they would have if you got 10
people there. Everybody's pulling a little
bit, right? But nobody is pulling nearly as
much as if they were just the only person on there.
And then you can literally measure the force that they're
exerting on the rope. Yeah.
So I mean that's great. I love that analogy of the of
the tug of war and I think we can see this manifested and and
it might be a little bit counterintuitive, right?
Because it's not as if people just inherently take advantage
of the system and take an opportunity to contribute less.
I think what's really happening is that there's so much
complexity that's added when you add people and there's so much
communication overhead and collaboration and coordination
that's happening. It all becomes overwhelming.
And you don't want to be pulling too hard in One Direction when
you have to be working in concert with everybody, right?
I mean, ideally everybody pulls the same and exerts the same
amount of effort, but it's very difficult to know what that is
and it's very difficult to actually effectively do this.
And so I think the way that we pull from that in the book is
say this is an inevitable cost of scale and there are more
benefits than costs, but because of the benefit and that we want
to realize the benefit and we don't have a better alternative
than working in groups. You know, our best work can be
done in highly effective teams of the right size.
And so we have to do this, but there's a big difference between
doing it well and doing it poorly.
And it takes intentional practice and principles and
guidance and the right systems to enable that effective action.
We call it effective collective action that gets everybody kind
of pulling in the sweet spot in their flow state so that we have
individual flow creating collective flow.
Right. So the three elements of this
collective action in your book, which also brought up by Andrew
in the beginning of value, clarity and flow, right.
So you hypothesize like with this tree in place, right.
So as the organization's skills, probably we will see much
benefit rather than having more cost or the tax of having so
many people, which probably brings us into this flow
engineering. What is actually flow
engineering right in the 1st place?
Many people might know about flow, of course, many people
know about engineering, but flow engineering is kind of like new
term. So tell us a little bit more
about this. Flow engineering, you know, in
very simple terms, I think is an effort to share a term that's
memorable and easily understood by folks that doesn't have the
associations with traditional manufacturing that value stream
mapping does. For one, because it's more than
value stream mapping. You know, a lot of people, they
hear value stream mapping and they think, oh great, like that
works for a factory. We don't want to be a factory.
We don't want to work in that kind of environment.
And so we really try to separate the goal, which is effectively
engineering flow from any specific practice, whether
that's value stream mapping or otherwise.
And in our experience with value stream mapping and as you
practice mapping value streams, you really quickly start to
understand that you can't just dive into mapping a value
stream. You know, you have to really
establish a clear direction, you know a sense of value.
What are we trying to achieve? And then understand the current
state landscape, which includes a value stream.
But it also includes things like what other factors are affecting
our performance, What are the things that we're struggling
with, what is the context of our current activity?
Because that really factors into what you notice when you go to
map a value stream. When you go to create this sense
of clarity, understanding this information upfront and all
starting on the same page really makes a big difference.
So flow engineering is partially kind of adding that very
explicitly into the early stages of activities.
So come together and and set a clear target.
But then on the other hand, it's taking what we learn by mapping
the value streams and looking at value streams and looking at
constraints in the data and measurement that we uncover
through mapping and translating it into action.
And that's kind of the second part of the equation is it's
great to find things in a value stream.
It's great to find opportunities and understand to a deeper
degree what's holding us back from Flow, but it's useless if
we don't act on it, right? I think we've all kind of been
in a retrospective where, you know, we discover all these
things and then everyone leaves saying, OK, we'll try harder
next time, right? I think you've always got to
take what you learn and make it actionable and make it part of
improving the system going forward.
So that's where we really kind of add these explicit practices
to kind of introduce value stream mapping with very little
initial context necessary to keep it very lean and very
simple and very minimal. And then at the end, to really
drive that value forward and ensure that it actually makes a
difference the the road map that you build with the insights and
the actions that you're uncovering during the mapping
takes you all the way through a complete program that hopefully
makes a big difference in the organization.
Right. So thanks for explaining about
what is flow engineering. Yeah, First of all, it's about
coming up with a term, right? So that we don't always
associate this thing with value stream mapping all the time.
And it's actually a set of practice and the way it works
just like what you elaborate just now, I think it sounds like
a feedback loop, right. So where you actually first know
where you want to go do something and currently
understand how you're doing it, what kind of problems, blockers
and things like that, and then set the actions right, just like
what you mentioned in the retro, if we do it properly, right, we
will do some actions and then over the time you kind of like
repeat the cycle again, right. So I think this can work at the
smaller scale, you know, in the team level, but also at the
organization level. And I think in your flow
engineering, you have a few things that we can do, the
activities that we can do and actually to map this kind of
feedback loop in the organization, maybe tell us a
little bit more in probably 1 by 1, right.
What are those tools that we can use in flow engineering?
The book introduces 5 primary maps that are the actual
execution of the flow engineering practice.
And you mentioned about the idea of feedback loops.
We borrowed a lot from the principles of cybernetics when
we're talking about the problems of scale.
So cybernetics as a discipline in the 20th century spent a lot
of time trying to understand what are general rules that
would apply to either humans or groups of humans or technical
systems. But is basically some scale free
rules, some rules that apply at any scale.
And so the idea of setting a clear target and you'd mentioned
this right, setting a clear target, getting clarity on
what's your current situation, what are the gaps and so forth
and then having a feedback loop about are we there yet and
continually adjusting in that direction.
That was the spirit of this. So these five mapping exercises,
the first one is really to get clarity on the target state.
We call it outcome mapping. And that really addresses the
issue of engagement or disengagement, opposing
disengagement. You know, I think often
initiatives or directives would be set from a higher leadership
imposed to some degree on the organization and people are
asked to participate in that, but without fully understanding
either what is the outcome that they're supposed to accomplish
or why that matters. And just naturally, as human
beings, one of the things that interferes with our level of
engagement is if we don't understand why we're doing
something, now the executives who set forth the vision might
understand perfectly why we're doing something, but that's not
going to help the individuals if they don't internalize that
themselves. And that's the really, you've
got to span from the psychology of whoever's setting the goals
right to the psychology of the individuals who are executing it
And getting that clarity on the outcome is the first step.
And that often is missed if people just dive right into
value stream mapping. Value stream mapping we
introduce is the second of these mapping exercises and that is
basically to get that clear end to end vision of the process,
the sequence of handoffs that generate that are value
producing. And Steve really encouraged us
to take a working backwards approach like from the final
product, what's the step that precedes you know what are all
the value adding steps preceding delivery of a final product.
The third mapping is dependency mapping, which after a lot of
debate we we settled on just it's zooming in, it's taking a
deep dive view of part of the value stream map that is
suspected to be the primary bottleneck followed by future
state mapping which again is a value stream mapping exercise,
but this time envisioning the future state and current state
value stream mapping, future state value stream mapping.
All of this does resonate with prior work on value stream
mapping. One of the things we really
wanted to do is optimize for these people who are not only
busy and struggling to get approval to set aside time and
so forth, they're also impatient, right?
So how can we break this down in relatively short exercises, 2 to
3 hours to do the value stream mapping, identify that the area
that you think is likely the culprit, and then do dependency
mapping to do a high resolution zoom in on that one section.
Understand that better future state mapping then is OK With
the understanding we've gained. How can we improve that?
And then you identify a sequence of improvement activities in the
final map. Is flow.
Rd. mapping is about? How do we carry that out?
What are we going to do to actually implement these changes
so it's not just walking away and the scattershot approach to,
yeah, making it better? And I think what is really
interesting when you mentioned about people getting disengaged
and not understanding what they are trying to do or the
company's trying to do in terms of outcome, the clarity, right.
So I think you kind of like come up with these tools and uniquely
they are all called maps, right. So map is like something that we
create so that people get a shared understanding.
So I think that's the key thing so that people get the shared
understanding, know where they are going, right.
And probably the road map also tells them that OK, because we
want to achieve this target, we have this plan, everybody gets
together so that they are aligned and maybe yeah, no
matter what scale they are, they will get clarity, they know the
value that they're bringing and they also can do it, I mean in
terms of action, right, do it in a such a flow kind of a state,
right. So I think really important
thing maybe if you can from your experience right, if you can
share which map actually helps people to ramp up the most,
because so many organizations might not have this mapping
exercise. But in your experience, probably
which maps that do you think gives the biggest impact if
organization wants to do it in the first place?
Well, this is a good question. I like this question.
I think that you know in terms of bang for the buck in my
experience and this is part of the problem is that value stream
mapping is extremely powerful like current state value stream
mapping. Everybody I talk to and every
map that I've ever built with a group you find the 20% of what's
happening is totally unnecessary and could go away tomorrow and
would have no negative impact on customers.
It would just make everything faster and easier and that's
very high return on investment. Like it's remarkable and
consistent. And this is part of the reason
why people kind of just dive right into value stream mapping
because they hear that olives, it's fantastic.
We hear great things about it and then they struggle because
they haven't done the the groundwork to understand where
should we focus on that value stream, what level of detail
would be valuable, what is the scope, what's the stream that we
should focus on? And so the outcome mapping, it's
absolutely necessary to have that level of clarity.
And we like to say with flow engineering, like if everybody
knows what is revealed by any of the maps, they could skip it,
right? If everyone is on the same page
and everybody has absolute clarity on the target outcome,
the benefits of that, the obstacles, and how to proceed,
go ahead and skip it. And likewise for everything
else, right? You can skip all the flow
engineering if you already have all the answers.
But we find that's never the case, right?
If you ask three different people what the most important
focal point is or where the biggest obstacle is or where the
constraint is, you will get three different answers.
So we think it's really important to start with outcome
mapping as a foundation. But that's another reason why,
you know, we keep all this very minimal, very small scale.
We're targeting 90 minutes for every map.
And sometimes you can't get everything done in 90 minutes,
but you get so much value for that time that it pays for the
next map and it pays for the next session.
And that's kind of rather than having people try to get by in
for something massive and then doing nothing if they fail at
that, we'd rather make it something that fits into the
spot that they've got for retro, right?
Try something different for your retro, try something different
for your lunch and learn. Try something different for your
off site, just to make it very easy to say yes and try it out.
The five maps are interlinked with each other and they are
sequential. They each build on the other.
So value stream mapping is huge and outcome mapping as the prior
one because it is critically important.
As Steve was saying, we're in the space of unknown unknowns
and we as humans assume we like, we we have evolved to assume we
know the reality. We substitute our mental models
of the world for actually directly perceiving reality.
And so we're continuously acting as if we know what's going on.
And generally that means we ignore all the things we've
learned to ignore. And and where Steve said we've
got these disparate mental models, this aligning and
creating a coherent, shared picture of our disparate mental
models is what we're talking about with the mapping.
And you Henry called out. We're using the metaphor of
mapping and we often say the mapping is more important than
the map. And so the map is like some
final artifact, but it is in the process of mapping that what
you're actually doing is having a visual conversation with the
team. And as I surface part of my
understanding, I externalize it on the map and then you
internalize that and say, Oh yes.
And then you share your understanding and see how that
map and that fits in. And we're able to do it
collaboratively. Digital, you know, digital
whiteboarding or physical whiteboarding, you're able to do
it collaboratively. Really, it's a conversation.
It's a lining of these mental models, and the raw benefit that
you get from this implies that there was this hidden cost, and
this is the hidden cost of scale.
It's this disorientation. It's this sort of lack of
clarity on what's actually going on that really can only be
resolved by making an intentional effort.
I like that you emphasize that the mapping exercise is actually
more important than the map, right?
So that reminds me of this quote as well.
Right? So all maps are wrong, right?
But some, not all maps, all models are wrong, but some are
actually useful, right. So I think the key again to get
the shared understanding between many people.
If you have a larger organizations, definitely it's
really, really more difficult to actually get this shared
understanding. And doing this mapping will
create a mental model so that everyone has aligned mental
models so to speak, right. So people are more aware of what
is going on in the company and what kind of target they want to
achieve. So not only the maps, you know,
the tools that you give people to try out an experiment, but
you also kind of like give 5 principles that we need to adopt
or need to be aware of when we want to practice this flow
engineering much, much better. So I think the principle
sometimes is also more important, because we can be
given all the tools that you know may work right, but
actually if we execute it wrongly, in the wrong spirit
right, the tools may not be able to solve your problem.
So tell us a little bit more about these principles.
I just wanted to quickly talk about that you initially said
all maps are wrong and then corrected that all models are
wrong. But I think you're also right to
say that all maps are wrong, right?
All maps are just a representation.
And the only reason that we kind of settle on any representation
of what we think of as reality is that we all say, OK, well,
that's good enough detail. You know, it's useful enough
that we can use it. It's not so detailed that we get
lost in perfect accuracy and we can't actually extract away what
we really care about, right, because we might just want to
get to a restaurant. But there's diminishing returns
in in perfect detail. And this is one of the things
that I think people really struggle with, with Valley
Stream mapping is they're really unclear about what the right
level of detail and accuracy is. And they kind of trip over this
desire for accuracy and precision when all we really
have to do is find a focal point, right?
We need to take everything that we could possibly do and all
come together and just decide, OK, this is the most important
thing to do. And once we accomplish that, we
can move on to the next thing and we'll be way better off than
trying to divide our focus across everything that we have
possibly to do. And you know, it could be one
thing, it could be 5 things if you've got capacity, but often
it's 50 things because nobody is focusing and nobody has that
level of clarity and decisiveness.
So I I just wanted to mention that and I'll, I'll toss back to
you, Andrew, 'cause I thought that was interesting and I don't
disagree. I think that all maps are wrong.
Yeah, yeah, agree. And I mean a map is just a
model, for example. So it's totally apropos.
You know, Henry, you'd asked early on about what is flow
engineering? And Steve and I, both coming
from technical backgrounds, we're familiar with software
engineering and network engineering and the idea that
everything is a technical problem to be solved.
When it comes to flow, either individual psychological flow or
team flow handoff and so forth, you're working the psychological
environment or sociological environment, right?
These are domains that sometimes engineers are undereducated on.
So I'd say our book is in the same vein as books like Wiring
the Winning Organization by Gene Kim and Steve Spear that are
talking about social circuitry, right?
And helping to use this metaphor of engineering or social
circuitry and so forth for all of these overly technical minded
people to try to make sense of the real human challenges that
we're dealing with in our organization.
So when we talk about this five principles like the third part
of the book is on scaling flow engineering.
So the first part we talk about scale and the challenges of
scale. The second part we introduce
these five maps. The third part of the book is
about scaling flow engineering. And when you talk about scaling
flow engineering, you're wanting to make sure that you can get an
increasing number of people in the organization familiar with
conducting the exercises, but also to sustain the value of an
initial value stream mapping exercise and improve flow.
There are new understandings that need to be internalized by
the team. And so Steve and I are big
believers in the power of principles as like a real
condensation, like the the pith essence of an insight or an
understanding that people in an organization can internalize if
they internalize those principles, those principles
provide wise and reliable guidance in a variety of
situations. And so it's a way of enabling
decentralized action. You train people in principles,
and then those people go off into some.
You never see them again, but they're still operating based on
those principles, and the principles are still working.
And that's the magic of sociology, right?
So these five principles, we spent a lot of time sifting
through what's really required to make this work and so forth.
And I I spent some time organizing, and eventually I
couldn't come up with a better system than these.
What do we call the five principles of Lean?
And these are borrowed from Jim Womack and Dan Jones.
Lean Thinking these books about explaining Lean and so they are
the principle of precisely specifying value, precisely
specifying value, very much like the outcome mapping.
What is the goal you want to accomplish?
Mapping the value stream and so map precisely specifying values
very closely aligned with outcome mapping.
Our first mapping exercise, Mapping the value stream is
basically the second of the exercises and then the idea of
creating flow and really aiming for what can you do to enable a
steady continuous flow And and that's all never possible
perfectly but it's basically it's an idealized state what
would perfect flow be like. But even the idea of taking an
ideal state as your guiding light as your North Star is very
powerful. Psychologically.
It doesn't get old, right? If you keep working towards
enabling flow, that's a reliable North Star, that's a reliable
guidepost GuideStar for ongoing improvement.
Because there's always going to be something different that is
inhibiting that flow. And you know, first of all it's
waiting periods and then it's lack of automation, then it's
confusion, then it's multiple, you know, too many handoffs and
blah blah, blah. But as you try to create flow,
you discover what are the obstacles.
Basically is a continuous process of discovering
obstacles. The fourth of these lean
principles, which we adopted as flow engineering principles
giving credit to the authors, is enabling pull.
You know this idea which was really quite significant from
the TPS, the Toyota Production System, which is really Toyota
has recast that as TPS is the thinking people system.
So they really want people to stop saying Toyota Production
System, start saying the thinking people system to really
point to what that means and then enabling pull, not push,
right. We don't build anything unless
the customers actually requested it.
And that is that creates this most efficient process where
you're not producing more work in progress than you can have
consumed by. And so it's consumed by the end
users, and so it's a characteristic of an optimized
system. The final principle is this
relentless pursuit of perfection.
To quote Lexus, it's continual improvement, continual learning,
Toyota's motto. There is no best.
There is no best, only better. There is no best.
And that your goal is to do better than you were yesterday
and this continual driving. Right.
I think in Toyota they also have this thing called Kaizen, right.
So continuous improvement. So I think pursuing perfection,
doing the Kaizen being better than what you did yesterday is
really, really important. So I like all the principles and
I think this can be a good like guidepost or mental model that
people should think about whenever they are in a current
situation in the organization, first understanding the value,
right, doing the value stream mapping.
Because sometimes in large organizations, as people move,
people come, people go, change of leadership, things change.
Whether you realize or don't realize, right, things change,
maybe new directions, but not everybody in the organization
actually understands what are those changes.
Sometimes even you are just given a goal.
OK, maybe not a goal. You're just given a task, hey,
please build this product or this feature.
And you kind of like assume that that's the right thing to do.
But sometimes it may not be right and you don't understand
the total outcome. Speaking of which, that means
the leadership role is very important here, right?
Because in order to do all these principles, conduct this mapping
right, you need to get the buy in.
You need the people to also understand the benefit of doing
this flow engineering. So if you can probably summarize
like what is the role of leaders in the organization?
How is it crucial so that they can actually utilize this flow
engineering for their benefits? I think that from the leadership
side you could get the sense with borrowing the lean
principles and borrowing a lot of mapping techniques.
We really tried not to reinvent the wheel.
We really tried not to create anything new for the sake of
creating anything new because there's so much fantastic
knowledge and practice that's come before us and it's all been
studied and there's so much depth that you can go dig into
and leadership is well travelled territory.
But you know, when we think about leadership in the context
of flow, the lean principles and sort of guiding and enabling
folks to kind of follow those and build them into daily work
is really important. One of the things that we are
really passionate about is designing feedback loops and
that goes all the way back to cybernetics, right?
I mean, you can't operate an effective system without
feedback. So making sure that those exist
to inform individuals that they're on the right track, that
they know that they're headed in the right direction, that they
can effectively coordinate and collaborate with other people
and that everything that they're doing is in service of the
target goal is so critical. So that's a really big one.
Supporting the individual contributors and the teams that
are making changes by creating enabling constraints and
effective governing constraints. You know, we talk about
constraints a lot in the book and constraints are kind of a
natural counterpart to Flow. You know, we think about
bottlenecks, but something that's really come to light
quite recently in the DevOps space is the idea of enabling
constraints, things that allow us to do the right thing and
make it hard to do the wrong thing.
And so that's a major aspect of what we put into the guidance,
because building these systems and building these guardrails
are really, I think, what unlock the creative capacity of people
and allow them to get into a flow state and stay in a flow
state when they don't have to be managing tons of complexity and
cognitive load because the system takes care of the things
that systems are really good at taking care of, right?
So there's lots of opportunities for automation and capabilities
that do things that machines should do so that humans can do
what humans do best. There's one thing so I I want to
hand off to to Andrew for some other idioms here.
But one thing that I think doesn't get emphasized enough is
that a lot of people, they think about flow, they think about
value streams, and they think about efficiency, and that this
is all just a race to the bottom, and it's a race to
cutting costs. It's a race to eliminating
people and making the most robotic automated system that we
can make. And you know what we're really
passionate about. And the real opportunity is
getting rid of all the things that just have no business being
part of our working lives, right, because they're better
handled by systems and automation and even
documentation and tooling, right?
Like there's lots of opportunities to get rid of the
things that we really don't add value with so that we have more
time to be creative and collaborative and human.
So that's one of the things that we're really, really passionate
about. And you know, we charge leaders
with focusing on that rather than focusing on who's the
bottleneck or how do we get rid of this waste that may be
tightly associated with individuals, right.
We really want the focus to be on systems and enabling people
to do their best and and really enjoy their work so that they
can contribute at their absolute peak.
But I'll hand off to you, Andrew, because I just rambled
for a long time. We started by talking about the
challenges of scale, dealing with the challenges of scale.
And that is the responsibility of.
I mean, a leader is someone who is exerting influence at scale.
And it can be difficult even to understand what is your
responsibility, what's your primary responsibility.
And so here we're really the word, the term flow engineering
is speaking to this balance of the fluid, the liquid, the
changing, the ever changing nature of things flow and the
engineering, the systematic analytical mindset.
And so leaders very much need that analytical engineering
mindset when they're thinking about what is the goal, how do
we systematically improve and so forth.
But they need to understand that what they're operating with,
operating in the world of people.
They're operating this world of psychology, sociology, this
constant flow of change in the organization, flow of
information, flow of people in and out, coming and going.
One thing we noticed that these things value clarity and flow.
They're ephemeral. I'm super clear 10:00 AM in the
morning when I'm fully caffeinated and wide awake.
And yeah, my clarity dims significantly at 3:00 PM in the
afternoon. Right.
So there's an understanding that you're dealing with these
invisible forces, right? This, you're operating in flow.
A friend of mine likens this. She used to be a paraglider and
she's operating in space, you know with all these invisible
forces of the winds and so forth.
And saying that operating in the modern world is very much like
that where you've got all of these invisible forces impinging
on you and you're trying to control the harness, the frame
of the paragliding equipment and so forth to capture that to work
together with that leaders. I think we aim to, if the
leaders focus first on improving the way of working, then they're
increasing the satisfaction of the people that they're leading.
They're increasing the creative capacity of the team and that
investing first in improving that ability for the team to
operate and flow, the coordination and so forth makes
it infinitely easier to accomplish whatever other goals
you have as an organization. I like the paragliding analogy.
So far in this conversation we have learned about tug of war
and we have also learned about paragliding.
I think that's kind of like perfect analogy to explain what
you just explained, right. So I think thanks for that
analogy. And speaking about leadership
responsibilities, of course, it's a tough responsibility.
But what Steve and Andrew has just mentioned as tips probably
is also is a good guidelines for us.
And in the books, there are a few more that you can also
explore. And I'm really excited to see
the book being published in the next few weeks.
So we reached the end of our conversation.
But before I let you go, I have this one last question that I
always ask from my guest. I call this 3 technical
leadership wisdom. You can think of it just like
you want to give an advice to the listeners here from maybe
your experience or maybe from your research and things like
that. I leave it up to you.
How do you want to structure this 3 technical leadership
wisdom? So if you can share them, what
would that be? I can lead off with a few.
One is you don't need to know all the answers.
I think there's often a feeling like if you're a tech leader in
some position responsibility, you're expected to have the
answers. You're not expected to have the
answers. If you try to generate the
answers, you're almost certainly going to be wrong and just
basing it on your assumptions. And we operate so heavily on
assumptions. What you need to be doing is
hosting the conversation, bringing together conversation
to clarify that. So that would be 1 nugget of
wisdom. You don't have to have all the
answers. The 2nd is you need to take
seriously and think deeply about the human aspect of your role.
You might be a technician, you might be excellent at your
craft. If you're in any kind of
leadership role. This is a human management
activity. This is a liberal art, and your
technical knowledge is important that you know the lingo and the
mechanics of your field. But working with humans, your
goal is to draw out of them their own potential for
greatness, right? And then your own internal
maturity, your own internal personal development of
yourself, and then your ability to lead is paramount.
It's basically become your primary responsibility over your
technical skills. So I'll leave it at 2:00 to give
a chance for Steve to. That's great.
I I will do the 1 1/2. I will, yes.
And everything that Andrew said. I wrote these down because I was
thinking about this prior to the meeting.
I wrote down assume you don't know which is kind of the
corollary of but you don't have to know everything.
I think it's very helpful for us to kind of walk into it,
especially as technical folks, we tend to dive right into
solution space without spending enough time in the problem space
and understanding the problem. And then the other one that came
to mind that that is very, you know, I know close to both of
our hearts is none of us is as smart as all of us.
This collective understanding is so powerful and it's so
fragmented under ordinary circumstances.
And the one that I'll add that I'm so fond of is, is this idea
of working backwards, like just looking for a target outcome
that we can focus on and envision and become very
passionate about and then what's going to make that happen.
And that has implications for planning and strategy and
alignment and getting people excited.
But it's also how we create a value stream.
You know, we look at OK, how do our customers get value and what
happens before that and what happens before that and all the
way back. And so that's something that's
really kind of woven through the book and that we really take to
heart going through cybernetics and going through the principles
of Lean like it's just very entrenched in the content of the
book and and in the practice of flow engineering.
So hopefully that's valuable. Yeah.
So working backwards, I think this is also popularized by
Amazon, right. So I think the way they are
thinking in the organization is always like working backwards.
So thank you so much for sharing all the wisdom.
So there are many, not just three I believe.
And I think we'll summarize that in the show notes.
So for people who would love to connect with you or continue
this conversation or ask questions, is there a place
where they can reach both of you online?
Yeah, we we both spend a lot of time on LinkedIn.
We are constantly talking about flow and flow engineering and
value streams and collaboration and DevOps.
So that'd be the easiest place to find me and follow along with
what I'm doing. And we're ramping up talking
about the book. Folks will be able to follow
along if they pre-order the book, they'll get connected with
everything that's happening there.
Flowengineering.org is now live, so go check out Flow
engineering.org For more information and sign up for the
e-mail list. Right.
So I'll put them all in the show notes.
So thank you so much for your time today.
I hope the listeners here can invest more time in, you know,
creating flow in the organization, be it for your
individual's sake and also collective flow.
So thanks again for coming to the show.
Thanks so much Henry. It's been super fun.
Delighted to have the conversation.
The.