Hey, a quick message from me. Thank you for being part of the
Techledjournal community. This show wouldn't be the same
without your ears and you are the reason this show exists.
Creating this podcast is a labor of love, but the truth is it
also takes time, resources, a whole lot of passion, and an
extra bit of caffeine. So if you're loving TLJ and want
to see it keep on growing, consider becoming a patron at
techledjournal dot dev patron or buying me a coffee at
techregional 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.
If we want to deliver better results, what should we do?
We need some model that says what improvement looks like.
But we also need to focus our attention on the things that
matter. And the way to do this is by
changing the system. So if you want to deliver better
results, you need to do something to your way of
working. 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 again, my friends and my listeners.
You're listening to the Technically Journal Podcast, a
podcast on technical leadership and excellence.
If you haven't, please subscribe on your favorite podcast app to
get notified for new episodes. Keckley Journal also provides
bite sites contents on LinkedIn X, Instagram, YouTube, and
TikTok. My guest for today's episode is
Gil Brozer. Gil is an Agile leadership
expert and the author of the latest book Deliver Better
Results. In this episode, Gil discusses
ways to level up our value delivery system to deliver
better results. We first delve into the
fundamental concept of systems thinking and cause effect
relationships, which are exemplified by reinforcing and
balancing loops. Gil also explains the importance
of ways of working, particularly on shifting mindset and focusing
on people first before the process.
Gil then explains the square model detailed in his book and
how we can use it to assess our fitness for purpose by
understanding the distinct levels described in the model.
He also shares some of the 10 strategies from his book that we
can use to enhance our fitness level and deliver better
results. I hope you enjoy listening to
this episode and learning a lot of insights to improve your
value delivery. Remember to share it with your
colleagues, friends and communities and leave a five
star rating and review on Apple Podcasts and Spotify.
Now let's go to my conversation with Gil.
Hello guys. Welcome back to another new
episode of the Tech Regional Podcast.
Today, I'm sitting here with Gil Broza.
He's the author of a book titled Delivering Better Results.
So I'm sure all of us here want to deliver better results,
right? But sometimes it's very hard and
challenging to know how to deliver better results.
So today, I hope we'll be learning a lot more things about
how we can deliver better results in a systematic way,
right? So, Gil, welcome to the show.
Thank you for having me. Gil, I always love to ask my
guests to first introduce themselves by telling us about
highlights or turning points in your career that you think we
all can learn from. OK, I started like many people
as a developer, then became a manager and that was my exposure
to the significance of process and the significance of
collaboration. And after moving couple
companies I discovered also what's the difference between a
loose and simple process and a big and heavy one.
And I really didn't like the big and heavy one.
So I that's around the time I discovered XP Extreme
Programming. And I really got into that.
And the turning point for me was when I decided to make this my
full time profession became an XP coach right at the time
nobody said Agile coach, it was just speak and I got exposed to
so many interesting companies at all sizes.
We didn't even use the term scaling back then, but I had
some pretty large clients. This became, you know, my work
of a lifetime. And then a turning point for me
was when I realized that I approach my coaching work and
the advice I give clients in a different way than most.
I really emphasize the human side.
So yes, there is process. There are techniques.
I taught test driven development.
I paired up with developers. I did all of that.
But it was all about how we engage as a group in the
creation of value. And so that ended up being my
first book, The Human Side of Agile, which was pretty unusual
for its time, 2012 or so. So that was a big turning point.
In the next one was when I realized that another aspect of
what I do is to help people be cognizant of the choices that
they make and how you know you can execute the exact same
practice like continuous integration or story point
estimation or any of those things.
You can execute with one mindset or a different mindset,
basically choices and you get totally different outcomes.
That's turned into the second book and into some really super
interesting clients. And since starting I've worked
with about 100 clients. So I've seen so much.
I've seen the good, the bad and the ugly.
I've seen the big and the small, the fascinating and the boring.
I've really seen it all and I really love this angle or
perspective that I have on our industry.
And so this is really turned into some of my newest work,
which is what we're going to be talking about today.
So I think it's very interesting, right, when you
have coached so many different clients, right?
Big, small, fast moving, slow moving, right.
I think you have seen a lot of patterns and I'm sure today
we'll be learning a lot from you today.
So you wrote this book, deliver better results, maybe a little
bit of background story. How did you come up with the
idea? What kind of problems are you
trying to solve with this book? So like I said, I've worked with
about 100 clients, but I've spoken with a lot more
companies. So you know, AVP will call me
up, a director, CTO, they'll say we need, we need some help here.
So I do discovery calls and I really learn how the companies
work and what's getting in their way.
And I found it a little bit difficult to articulate what
exactly needs to be done now without doing a really serious
assessment. I can really understand the lay
of the land, what's connected to what, what's affecting what and
so on. And you know a lot of the
clients I work with, I do actually start with an
assessment and they pay for it and they get you know basically
we strategically designed the next few steps.
But I was looking for something that would be quick and simple.
So quick and simple that an executive can, you know in 10
minutes figure out we are doing this well and therefore we need
to do AB and C to level up. You know, think about it like in
terms of health, we can step on the scale and we can weigh
ourselves and that is, I mean we get a precise number, but what
matters is like what range it is in and based on the range we can
sort of understand, you know how well we're doing and even that
is a partial metric, but it's sort of a starting point.
So I was looking for something that would be this simple, and
at the time I didn't even have a term for this.
How well we're doing and even what is we?
Because I come from the agile space where for the longest time
our focus was the single team, and then the focus became the
bigger teams and like, you know, scaling frameworks and whatnot.
But when it comes to creating software, when it comes to
delivering value, more people are involved in that.
The analogy I give to this is like, you know, the credit roll
in a movie, right? Yes, it starts with the producer
and director and actors and the writer, but there's a million
more people, and every little decision they made had an impact
on the end result, even the people who took care of the
catering, Right. Because, you know, hungry actors
probably don't perform as well as they do when they're not
hungry. So I was looking for a way to
describe this construct that creates value and a way to
understand what I learned came to term it's fitness for
purpose. So in the book I talk about the
value delivery system and that's a whole bunch of people.
If you're in a product company and I think a lot of the
listeners of this podcast are, you'd have product people and
engineers in Sr. ES and UX and whatnot content.
And it's all these people and all their managers who make
decisions and how they work so that at the end your customer is
able to do something different. So that's a system of value
delivery. Now we do have terms in the
industry there's like value stream, but in many cases it's
not a complete system, it's a portion of it, at least that's
what I've seen. I'm sure there are exceptions.
And when we say value stream, we sometimes blind ourselves to the
fact that some dependencies go backwards.
It's not a sequential flow or as a value stream sounds like
everything kind of goes downstream.
So everything is connected and that's the concept of system
from system thinking. And then I came up with the
definition of fitness for purpose.
And, you know, it took me a few months to figure out what I was
doing here. But then I came up with this
model and I was able to say, you know, here in 10 minutes,
literally 10 minutes, I can have a conversation with you or you
can do it on your own And you can say, well, we are at the
level 2, here's what level 2 means, or we are at the level 4,
here's what Level 4 means. And the amazing realization I
had is that this is not really a lossy calculation in the sense
that, well, I'm level two, OK, anybody could be level 2, then
what? No, if you're at a level 2
sustainably. So you really need to do these
couple things, what I refer to as strategies to level up.
And I tested this with so many people and it seems to work.
So this has been the background and how it evolved.
So I spent about a year in doing all of this and trying it out,
and then another year writing the book and of course any of
the process that evolved even more.
Right. Thanks for sharing this story,
right. So I think it's pretty
interesting. I mean you know what just a
couple of months back I was trying to do the same thing,
right. So assessing how my engineering
team is working in the company, right, and trying to get
so-called the maturity model, I call it borrowing from like CMMI
or maybe all other maturity model out there and trying to
assess level 1 until maybe 5, right.
And also figuring out like what kind of practices that maybe
level one versus level 5 should be different, right?
And I think it's pretty much the same idea.
And I think I when I read a book, some concepts really
resonate with me. So I think the first thing is
about value delivery system, right?
Some people call it value stream as you mentioned, but you
emphasize a lot about the system aspect of the value delivery
system. Tell us a little bit more like
why some people seems to not get this idea.
You know, like software engineering is a socio technical
problem, some people say, right, It's a system thinking.
So, yeah, maybe elaborate a little bit more.
You know, I don't think it is that people don't get it.
I actually think that a lot of professionals in our industry
definitely get the concept of a system.
We see it all around us. We know vicious cycles when we
see them or maybe when they're pointed out to us.
But we know what that is. We know, virtuous cycles, we
know. But feedback, feedback isn't
just, you know, customers saying yay or nay, any type of thing is
a feedback, a failing test is a feedback.
So we get it. But I think we have such a
history of working sequentially, functionally, hand off, throw
over the wall, right. Our organizations are structured
this way. And the way the organizations
are structured, somebody who could be, let's say, Director of
engineering, right? That's somebody with authority,
right, in the span of authority. But they don't actually have
authority over the entire system in most cases because there's
product people and there's the designer and there is maybe a
marketing person who also participates in deciding what to
work on or whatever. So I think it's also what we're
used to and what we perpetuate through the org structure and
the management ethos. But I have seen so many
exceptions. One of my clients, I love them,
their VP Engineering and the VP Product.
Yes, they owned the separate groups, but they always travel
together. I actually tell the example in
the book, right, Every time I met one of them, the other one
came in. And these are busy people,
right? And they had this understanding
that neither one would do something to surprise the other
because, you know, it's hard to coordinate schedules.
So that's an example of how you can manage even though you have
more than one person in charge of the place.
Or generally, you know, simply making decisions while you know,
consulting with your colleagues, right?
So for instance, you might be an engineering manager and you want
to turn out better code. OK, better quality code.
That's useful, right? But we live in a system, meaning
that whatever you decide will have ramifications.
If you decide to regression test everything, obviously that will
slow everything down, right? If you constantly regression
test, you can be writing a ton of unit tests.
That's good, assuming the unit tests are good.
But even then, if you're not being strategic and you're unit
testing everything because you want 100% coverage, that's going
to slow things down because you're going to apply some of
your effort to things of low value and low change.
So for the most part, we just need to be aware that we operate
in this type of environment. Which is why in the book,
whenever I explain system thinking, it's in plain English,
I don't draw diagrams. I don't talk about all sorts of
amplifications and this and that and whatnot, because I don't
think people need too much theory.
It's a pretty straightforward concept.
So I find also very exciting whenever I read about system
thinking, right? So I think if more people read
about this concept and some examples, typical examples in
software engineering, I'm sure they will all get it.
There are two things that I want you maybe to try to explain a
little bit more so this concept of reinforcing loop and
balancing loop. I find it is also very very
insightful, especially for people who don't know about the
terms, but I'm sure when they experience the situation they
will get it right. Yeah.
So reinforcing loops is when you do something and that creates a
response and that response maybe triggers another response and so
on until it kind of comes back to you, OK, And it comes back to
you and it reinforces something that you were trying to do.
And it may not be positive, it may actually be negative.
So when we think about increasing psychological safety,
for instance, or having people collaborate more, that's usually
a good reinforcing loop in that it creates positive effects, but
it doesn't end with those effects that again, it kind of
cascades down and and creates more positive effects, for
instance, in engagement. OK, balancing loops, push back
against your change. The example I gave in the book
is really within terms of like, again, writing unit tests.
Writing unit tests is the type of thing that most tech leads
and engineering managers that I know.
They think it's a good thing and it is a good thing, but somehow
it tends to die. This idea tends to die in
organizations now. Why?
Because it pushes against all sorts of things, such as when is
this feature going to be done right and I need you to deliver
now. I don't need to worry about the
future too much in all sorts of system forces, which basically
manifest in behaviors and meetings and complaints and
escalations and whatnot. And the loop here is that
eventually the pressure comes back to the people who want to
write those, you know, tests and they say you know what, maybe
not this time and maybe not this time.
And before long the idea dies. Right, thanks for explaining
those two concepts. I'm sure if people listen they
would get it right. So this kind of readforcing loop
and balancing loop. So another thing in the book you
mentioned a lot apart from just looking at the system holistic
level, right. So you mentioned about ways of
working, so maybe touch on a little bit like why ways of
working is very, very important for delivering better results.
So if we want to deliver better results, what should we do?
We can tell the team deliver better.
Here's the metric. Raise it, increase it, increase
your velocity, reduce bugs. I don't know.
Whatever. We can slap goals and things, we
can say by next year, 20% increase in productivity.
OK, so how do we achieve that? By working harder, By typing
longer? By doing what we need some model
that says what improvement looks like.
But we also need to focus our attention on the things that
matter. And the way to do this is by
changing the system. Now, what does it mean to change
the system? So like I said, no system is a
whole bunch of people and their ways of working.
So we're not changing the people.
Unless it's an extreme case, of course.
But we're changing how we work. So we change the process.
We change practices. We change team structure.
We change how we make decisions. We change what we commit to.
We change who makes which decision, things of that nature.
A way of working is basically made-up of two things.
One is all the tactical stuff. Practices, processes, roles,
tool usage, meetings, artifacts like backlog or whatnot, and the
choices that we make in their use.
So if I use the backlog as a short, small holding place for
good ideas, and I update it frequently based on your
information, that means I'm using it with probably an agile
mindset. And if instead I use the backlog
as a holding place for everything that management wants
and nothing's coming off the backlog and we'd like not to put
more things on it and whatnot. And then I'm approaching it with
a more traditional mindset, which kind of equates the
backlog to a project plan. So that's why I never talk just
about process, because process is meaningless without the
choices that we make in the use of it.
So a way of working is both the choices, which is what I refer
to as mindset. It's not some loosey goosey
psychological thing. It's simply a collection of what
we value, what we believe in, our principles for action and
those tactics, both of them together.
So if you want to deliver better results, you need to do
something to your way of working.
Maybe you keep the process constant, wait till you change
the structure, maybe go the other way.
Usually we do both so that we engage with the work
differently. And no, we take inputs, we
convert them differently to outputs.
That's basically what it is. I think I assume many people
when they do this kind of transformation or maybe changing
the productivity right, they focus a lot on the so-called the
tactical aspect of what you mentioned like processes, team
structure, maybe new leaders coming in right.
But they probably they seem to neglect a lot on the mindset
part right? What you mentioned values,
beliefs and principles. So why should we consider a lot
more on the mindset, maybe a little bit here?
How does the values, the belief and the principles actually work
in the way of working? OK.
So the way it works is that we choose what's important to us in
the doing of work so that we're successful.
Historically, those are the values.
Historically, what we chose is predictability.
We chose standardization. We believed that's the other
component in mindset. We believed that we can have a
process or workflow or whatnot, SDLC that will guarantee success
no matter which person carries out the activities.
Because people come and go and maybe we need contractors or we
hire or we fire or whatnot, but people were the variable.
The assumption was the process can be the constant.
OK, so that's an example. Agile comes along and say no, we
value adaptation for us. Adaptation is so, so important.
That we're going to reflect it in everything that we do.
Now, why do we value adaptation? Not because somebody said so or
because it's popular, but because if we don't adapt, we'll
die. If we don't adapt, we'll fall
behind. If we don't adapt, we'll get
disrupted. Whatever.
So the values are, again, what we are optimized for and the
beliefs are sort of what we take for granted or what we think is
true, and they give rise to everything.
So the third component in mindset is principles.
For instance, collaboration, self organization, transparency,
sex, safety, deferring decisions to the last responsible moment
that one's from lean, organizing, functionally handing
off, sign offs. All of these are principles, so
nothing in what I described as a practice or a tool or a
procedure. It's something that permeates
everything that we do. So for instance, if we want
collaboration, it's not just between 2 devs, we want
collaboration between product and engineering, between IT and
business, between US and customers.
And if we have too many customers and we need Go
betweens, let's at least collaborate with the Go
betweens. So these principles permeate
everything that we do. So the way it works is values
and beliefs give rise to our choice of principles, which in
turn kind of determine which tactics we will actually be
using and how we would be using them.
Now just going back to something that you said before you asked
me the question, I don't know that people necessarily neglect
them. I think for the longest time
people were not aware that that is the role that values beliefs
and principles played. And one reason for this is
because for decades we've been taking things for granted.
Again, those are beliefs. For instance, we believed in 10X
developers. We believed that if every
specialist or expert does their part, the result will be great.
So hire the best, right? And if you do any system
thinking, of course you realize that there's more to it.
And the other thing is those values, they're invisible.
So yes, organizations talk about values, but they talk about
cultural values and they put them on a wall and a poster.
But those cultural values don't actually say anything about what
matters when it comes to doing work.
So yes, we can be inclusive and diverse and whatnot, and yes, we
should be. But how do we carry out work?
Are we being adaptive? Are we being predictive?
Are we being collaborative or are we being siloed?
We're optimizing for something. We're optimizing our way of
working to achieve certain effects.
And nobody thought this way because for decades we optimized
for the exact same things. The predictability, the
standardization, the making early commitments and be on time
and on budget. That's what we knew.
And in a lot of organizations, that is sort of what management
still optimizes for because their boards pressure them and
there's a whole mess there. But fundamentally there is just
3-4, maybe five of those values that govern your entire value
delivery system. Be aware of them, choose them
intentionally and be explicit. And sometimes that's all you
need, honestly. Yeah.
So I think I've been there as well in multiple companies which
are doing transformation right. They seem to get a new leader,
put a posters here are new values who here are maybe you
know new whatever that we are adopting, right and let people
follow. So I think what you mentioned
here is sometimes like the people aspect, right, because
changing human is actually very difficult, right?
And no one can predict. So maybe a little bit more on
this concept, right? You put people first versus the
process first. How can leaders be more
intentional and be more conscious in the decision to put
people first? OK, so first let's define this.
What does it mean to put people first, what's second and what's
third? So typically nowadays the
understanding is and that is by the way aligned with the Agile
line of thinking is that people are first, product is second and
process is third. No, that doesn't mean that we
don't care about process. It doesn't mean that we don't
care about product. But what it implies is that if
we take good care of our people, if we're being good enabling
leaders, we draw good boundaries.
We trust their safety there. There's a whole bunch of stuff
there. If we enable people to bring
their best selves to work and all this good stuff, they will
take care of the product and they will come up with a process
that makes sense for the making of this specific product.
So that's what that means to put people first.
Again, historically, we put process 1st and product 2nd and
people last, which is why every person is a resource, right.
If we're standardizing, then we're standardizing people too.
Headcount, FTE, buzzword resumes and all of that stuff.
We're standardizing people. Now we can believe that that's
legitimate because the entire industry is doing it.
We can believe that that's a useful way to go or we can
believe something else. And there are many, many leaders
these days who believe something else that if you trust and
enable and support and catch when they fall, but you still
lead, right? You're not a pushover, you still
lead, you give direction, you show what good looks like and
all of that. This tends to create better
results. And we see this in engagement
scores and in product success and in retention in a whole
bunch of things now and even that I say, well, you believe
this or you believe that, but even that is a little bit black
and white because there is context.
I may believe that my team, let's say I'm a team lead, I may
believe that my team means the best, but I may not believe that
they could actually pull off the entire work because maybe
they're all juniors, shouldn't be this way.
I know, but maybe that's how it is.
And so I may need to support them more and look over their
shoulders sometime, trust and verify and all of that so that
they're actually more successful.
So yeah, I think what you speak just now is really, really true,
right? Leaders should care about people
more, right? Every decision that leaders
take, I think they should also think about the implications to
the people, because most likely the people are the one who get
affected. Yes.
And by the way, when we say people, the typical
interpretation is the team, because that is the unit we
typically talk about. But managers are people too, in
case we haven't noticed, customers or people too, they
have complete lives and wants and needs and frustrations.
And they would really love not to have to use our product.
But you know, the good outweighs the bad.
And our sea levels, they don't get it.
But they're people too. They have fears, they have
wants, they have constraints. So that that's really what it
means. Yep, thanks for the pluck here.
I think it's very important, right?
Don't think about people as just the employees, the staff who are
working on the problem, right. But also think about the
managers, the customers and so the executive leaders, right?
So for delivering better results, apart from system
thinking, improving ways of working, I think the most
important thing also like coming up with a model of framework for
people to follow, right? It's like a playbook, some
people say. And in your book you mentioned
this model called Square model. Maybe let's go through your
model and maybe elaborate a little bit more.
How does Square work? What are the kind of the things
that we can learn from this? So Square is basically the
entire subject matter of the book and it has several
components. One of them is the first of the
realization that we care about the fitness for purpose and we
want to improve it by in operating the ways of working.
So one of the components is what is fitness even made-up of?
Because it's pretty vague. I mean even think about fitness
of physical body, right. There is agility and speed and
flexibility and there's a whole bunch of stuff there.
It's not just unfit. So I define six aspects of
fitness which, contrary to a lot of what I saw out there, is not
about how will you track to a particular process framework,
How will you do Scrum, how will you do safe, how will you do
this or that. But for your system to be fit,
it needs to have its kind of outward looking aspects at a
certain level, its throughput of delivery, the outcomes it
accomplishes, the timeliness of its deliveries, how adaptable it
is, how consistent it is and how cost efficient.
Actually, all of these are aspects of how the system helps
the company achieve its mission and objectives, which is really
how I define fitness for purpose.
And so part of Square is also a fitness assessment tool.
We can already say this spoiler alert here, right?
That's the listeners are going to get it right.
That's fitness assessment tool, super simple, takes 10 minutes.
It's, I don't know, 15 pages in the book because it's like
mostly examples of how to use it.
Very simple, you don't need metrics, you don't need data.
And in 10 minutes you kind of rate how these aspects are with
relation to what's optimally possible for your system and out
of that you get one O 5 levels. So fitness, I discovered it kind
of grows along a scale of five levels, 12345, which are really
characterized by, again how well it helps the company achieve its
objectives and mention for instance, a Level 2 system.
And those are I think the most common.
A Level 2 system helps achieve the objectives, but it's not
effective or efficient enough. Or a Level 3 results are
satisfactory, but they're really dependent on just a few people
who make all the big decisions. So it's sort of defined by the
risk there. Another element in square is,
once we know the level, what do we do?
And there are 10 strategies. And what's really groundbreaking
about this model is how it sequences the strategies,
because our listener is. When you hear about them, or
when you read about them, many of them won't surprise you.
But the cardinal sin that we commit all the time is that we
overwhelm teams with change. We put people in cross
functional teams and we give them the boards and we expect
this type of velocity and we want to write our unit test and
everybody's in meeting, it's planning together and what's
not. And I've been guilty of doing
the same thing for years in terms of, you know, just
creating a whole lot of change at the same time.
And human systems, social, technical, like you said, they
have limited capacity. So that brings up something
interesting. A lot of leaders know that, you
know, you don't build Rome in a day, right?
So you do have to choose what to do for a second.
Third, And what this model says is what is the sequence of doing
things, For instance, to get from level 2 to Level 3, one of
the strategies is to stabilize the system, to use Deming
terminology, it's to reduce the variation and eliminate special
causes. But it's more than that.
It creates the realistic expectations for you know how
inputs transform into outputs, how your requirements and
projects and epics and commitments and road maps.
You know kind of when and in what shape will you get things
right. So if you can have, you know, a
sort of good balance there, your system is stable.
OK, well, how do you do that? Well, there's plenty of good
ideas from Kanban, from agile, from lean.
The nice thing is they all fully apply, even if you use
waterfall, which is not a bad word.
But what the model says is you do this at level two.
You don't do this when you're level one.
At level 1, before you ever got to level 2, you had to manage
your project portfolio strategically, meaning you
cannot overwhelm the teams with too much work at the same time.
So you can limit WIP and visualize and again common
ideas, but you first have to limit again your portfolio WIP
to really manage it to capacity, manage it strategically and only
then all the team level stuff that everybody does like with
their content boards and their lead times and this and that
only then it would even stick. We kind of do things backwards
because managing the product portfolio takes a lot of work
from senior managers and a lot of accountability and a lot of
saying no and not yet. And you know it's tied to
managers objectives and OK Rs and what have you.
So it's sort of easy. Hey teams, you just do this
thing, but it won't matter as much.
It won't stick as much. It will quickly kind of degrade
if the teams keep getting overwhelmed and you keep
reprioritizing and you keep running escalations.
So there's 10 strategies in all. You need 2 to go up from level
1-2, from level 2-3, from Level 3, and three from level 4.
But the other big deal is that you need to apply them across
the system. It's not going to be any good
just doing something in your engineering teams, even if you
have cross functional teams and in every team you got the
product owner. Let's say, let's say you have
five teams and you have 5 POS, right?
So it's like textbook Chrome. If all you're changing is how
the engineers behave or some of the choices they make in terms
of producing good code, but the POS still act in a bit of a
different way, or like how they acted a month ago, you're going
to run into trouble and you're not going to get the improvement
that you're looking for. You might get some temporary
improvement, but because of those balancing loops, things
are going to fall down pretty quickly.
So we gave one example. Did we give before unit testing?
How will that idea dies? Another idea that dies on the
product side is experimentation. So you might have a product
manager, say we need to experiment and do AB testing,
and let's buy this platform and do feature flags and whatever.
But if management still wants you to commit to a lot of
things, if your reward structure has to do with executing on a
backlog as opposed to proving what should not be done, if you
still measure velocity on things, but experiments, we
should measure them differently, then, you know, people respond
to the pressures from the environment.
We might think of pressures as incentives or constraints, but
it's pressure. So we need to make these
changes. And all of these 10 strategies
are very much about changes that we make across the system.
And the way we carry them out is by having leaders just work with
each other. It's that simple.
Thanks for the overview of the Square model, right?
I'm sure it's a lot for listeners to catch up, but don't
worry Jill. Later on we'll share the summary
of the book, right and also give you the the free assessment so
that you can understand where you are in your current
situation and what kind of levels that are out there for
you to aspire to. So you touch on a little bit
more about few strategies, right.
There are 10 strategies in total for the book.
So maybe we won't be able to cover all of them for sure, but
maybe we can cover some more. So the first you have already
mentioned about managing the project portfolio, right, with
greater strategic control. So in a sense some people also
understand this like limit work in progress, right?
Not to have too many in the companies at the same time.
And then the second strategy is actually to design way of
working based on what matters most for achieving the mission
and objectives. My favorite.
This is my favorite. So what's the big deal?
So we talked earlier about what the way of working is, right?
So again, mine's the tactic. Structure, process isn't that
companies will sometimes restructure.
Sometimes they'll transform. They'll hire a, let's say middle
manager or a senior manager who says hey, I know how to do this
stuff and you know creates a new structure and creates A
transformation and a journey and and what not.
The question is what is the target state?
How will we come out of this? What structure will we have?
What process will we have? How will we engage with each
other? What I suggest in the book, and
this is really how I work with clients, is you want to design
this rationally. And if we go back to what I said
before, values, beliefs give rise to principles give rise to
tactics. You basically follow this flow.
You articulate collaboratively what we should be optimizing for
if we're to be successful. You kind of validate this
against your model of the world, your beliefs like what you think
is going on here and so on and so forth.
This is explained in the book. What comes out of this is a
custom design. This is super different from
what I'm going to say 99% of the world does, which is to go with
the popular or familiar or certified or.
I've done this in my previous company and this is not
necessarily bad because you know if you work in a similar setting
then it might make sense to have a similar type of setup, right?
But there's a limit to how similar those are.
And so every company is different.
You can be a tech company, a product company, staffed with
super intelligent people, gifted developers and so on, but
they're different because they're different humans and
you've hired them, you know, based on a certain company
culture and your business landscape is different and the
constraints that you have are different.
And the pressure from the market, the pressure from the
board, your legacy situation, all of these complicate things.
So I just don't see how it's possible to say let's just take
Scrum, let's just take safe or for that matter, let's just take
Kanban and start where you are, right?
That's how Kanban does it and sort of iterate our way.
I think it needs to be a bit more holistically designed.
And let me tell you, this doesn't take long.
This is most of not most, but this is a step I've done so many
times with my clients. I mean you're looking at like a
day or two of work seriously. Might be spread out across a few
meetings, but that's it now, not what you end up with.
It might happen to look like Scrum.
If that's a good fit, that's fine.
I've had clients like that or it might look like nothing in
particular. I have had clients like that
too. And.
But The thing is, it's not a mix and match.
It's not a pick air quotes for people not seeing the video.
Pick best practices and just put them together.
It doesn't work that way. You start by identifying your
values and because that's what will make you succeed, not a
backlog in the daily stand up. And based on your values and
again the context for them, which is the beliefs based on
that, you come up with the structure.
You don't need to be a process expert.
It helps, but you don't really need to be one.
It helps to have somebody who kind of gets, who has process,
education or theory in the room, which is really why I make a
living. But that's it.
And the other thing that's remarkable about this is that
you end up with a fairly simple and informal process because you
start with OK values principles. Yeah.
So we want to optimize for adaptation and we want to really
be collaborative with our customers.
And therefore, we're going to do short cycles and we're going to
do quick reviews and quick and dirty prototypes and I don't
know, whatever. And then you don't need to worry
about little things like, OK, So what exactly do we need to do
our code reviews for? Of course your code reviews are
important, but they will be so easy to do, like to define the
standard for code review after you've designed the framework,
as opposed to saying no no no, let's look for.
Let's Google for the most comprehensive code review thing
ever and just pluck it in. Or you might realize that doing
pull requests slows you down. Because in your context, if you
want to minimize delays, why do them asynchronously?
If you can just call your a colleague over or share a screen
and say, hey take a look, I'm not telling you not biasing you
take a look and then we'll have a conversation that will reduce
your delays. That's the big deal with
designing your way of working and it creates so much
engagement, it shows trust and it shows that you know, autonomy
and safety to the extent we have them are for real.
It's a big deal. But The thing is, you will not
be able to graduate much past Level 2 if you got there on a
shaky way of working. And I see this all the time.
Companies call me up and they say, well, so we've got in
whatever, let's say Scrum, just because it's popular.
We got Scrum and it things are not great.
Yes, we have sprints, yes, we have deliverables every two
weeks, but things are not great. And I look inside and I see,
yeah, you know, scrum could be a good fit if it were modified, if
other things were in place that bolstered it.
Maybe if we took away a couple of things that's really all it
takes. But instead of being reactive,
you can just. You know, take a day out of your
you know your team's life and say, well, let's just design our
thing. Right.
So I think those two strategies are the key, so-called key
strategies, right, for you to move from level 1 to level 2,
right. So again just to recap, right,
the first strategy is to manage the project portfolio for rater
strategy control and the second one is about designing the way
of working that can help you to achieve the company's missions
and objectives. So after level one, hopefully
people have moved on to level 2. You mentioned maybe most
companies are in this level. So there are two strategies you
kind of like cover a little bit on the first one to stabilize
the system. The other one is about
establishing clear and appropriate decision making.
So maybe tell us a little bit more about this strategy.
Yeah, So what happens at what companies?
Well, not companies. Systems reach level 2 is they
they tend to have gaps in decision making.
Again, this is not to pick on Scrum.
Scrum is actually fairly clear, but I'm just saying what I see
out there in the wild, you can have a meeting at the beginning
of a Sprint or release cycle or something, and you can set a
date for big release, maybe not just out of a Sprint, but
something like big and impactful.
OK, so we know who gets to set that date.
What happens if we're midway through the release and we
discover that there is, I don't know, a ton more work to do and
quality is kind of here and there and we need to shift the
date. Who makes that call?
So again, Scrum has something to say about that, but I'm looking
at what's your reality in your specific organization with your
specific people and it's specific chain of command and
culture and this and that. And what happens is that in many
of those situations, this example, and there's a bunch
more, they don't have good answers.
Is it the Product owner? Is it the Director of
engineering? Is it the business sponsor?
Who is it? Is it all of them together?
If it is, does one decide? Is it consensus?
How is it we don't know. So sometimes we default to
things like cultural norms or the chain of command.
The strategy is simply this. Every product impacting decision
needs to have a home. So list them out, and if some of
them don't have a home, decide who makes it and how.
That's it. I'm not telling you to decide
what's consensus and what not. Just make sure that they have a
home so we don't end up in this situation when some decisions
get overturned or not really implemented or they're just kind
of vague because we just didn't make them properly.
I want you to make them properly and maybe be wrong, this will
happen instead of just kind of, you know, half assed them.
So this is what you need to do to get to Level 3.
So at Level 3, again, results are satisfactory but sort of
dependent on a few key people. Now those key people are usually
not a team. They might be a product lead, an
architect, a director of engineering, someone like that.
They don't act as a team, but they basically hold the place up
and they make all the big decisions.
So what we want to get to level 4 are three things.
One of them is to, and this is the beginning of what we do, is
to increase the safety and the teamwork and the collaboration.
A lot of systems reach Level 3. They have so-called teams, air
quotes, but those are not teams that are groups.
They don't act as teams. Now is the time to fix that.
People don't collaborate enough, not just within their teams, but
they don't collaborate across teams.
They go through the hierarchy. We need to fix that.
We all need to make it a three for all.
That's not the goal at all. But we need to bring it to a
point where people feel comfortable to contribute.
If something needs done, it needs to be done.
It's that simple. Once we have implemented this
strategy, again, just enough. The other one we want to do is
to start the fairing commitments and increasing release
frequency. So this does not mean that you
need to go to continuous delivery.
That's not the point at all. You need to make less
commitments to what exactly and how you will deliver when.
You need to relax some of these because the more of them that
you have, the less freedom to move you have, which means the
less fit the system is. So this is super situational.
If you read this in the book, it's not like I'm telling you do
this, but I am telling you if you're for instance, if your
releases are every six months, consider going to every two
months or three months. If you release every quarter,
let's say you do safe and maybe you have some big big release at
the end of the quarter, maybe you can also have interim
releases. Maybe this is not your
situation, so don't bother, don't worry about it.
But if it helps you become more fit, do this.
So these two kind of go hand in hand.
But the big idea is to 1st defer more of the commitments because
they have ramifications across the company.
Every commitment you make, effects, marketing and customer
support and finance is going to care and whatnot.
So we need to work with them. And the third thing is to really
engage people in planning. So it's not just always the same
people deciding what gets on a plan.
You probably already have teams sitting in planning meetings
like from Level 2, but typically what's still happening is that
they don't actually contribute significantly and that's what we
want to change. So you do all of these and and
by the way, every strategy, it's not like you need to do it to
perfection. The book actually says how far
you need to go. Like what would you see if
you've done enough so that it's done its part.
So we're not looking for perfection.
There's really no need. But each strategy does have a
threshold and if you kind of stopped before or you don't
really ingrain it, it needs to become second nature.
Then you won't be sustainable at your next level.
Thanks for overview of the Level 3 strategies, right?
So I'm sure there are plenty of things that people should learn
from the book, right? Maybe one last before we wrap up
at the end later on, right. So people understand about this
model, they understand about system thinking now and the way
of working, how important it is, how to get started, right.
So, assuming that all organizations are in the chaotic
moment at this point in time, right, how can they start?
You know, using your book or using your strategies?
So you start by getting together with colleagues that are in the
system. You make sure you're clear about
the boundaries of the system. So who's in it?
Again, it's not just a bunch of engineers.
It's also it's everybody who is part of making and delivering
your product. Again, think movie, credit role,
do the assessment together, start it on your own so you
don't bias each other and then compare your notes because that
will show you how aligned you are on how things need to be and
how they are right now. And based on the level you're
at. See if the strategies from the
lower levels are really baked in.
If they're not, fixed that in ascending order and then turn
your attention to the strategies from this level.
I think that's a pretty good way to summarize how we can get
started, right? So of course you need to
understand the system first, right?
Not just optimizing at the team level.
Yes, and by the way, I know everybody loves their metrics.
One reason my model does not use metrics, I mean, it does
recommend a few for some things, but it doesn't rely on metrics
to know where you are, like what your current fitness level is,
because nobody has a complete set of metrics that covers
everything about systems fitness.
And it is accurate. It's not garbage in, garbage
out, and it didn't get funched and played with.
So it's like, you know, if you look at Dora metrics, they're
awesome, but they're just one side of your system.
They don't talk about did your features actually make a
difference and are you being cost efficient about it And how
adaptive are you? They don't.
That's not what they were supposed to do.
So yes, there's a whole bunch of, you know, frameworks and
this and that, but people get into so much trouble and they
make such headaches for themselves trying to get just
the right metrics and so on. And I was looking for something
that can be, you know, quick and useful enough.
Am I 20 kilos overweight or 10 overweight?
I could use that information. If I'm 20 overweight, I'll do
this. If I'm 10 overweight, I'll do
that. As simple as that.
Yeah, I think we all want to chase for silver bullets, right,
and want to have precision, so to speak.
So that's why all these metrics, you know, some people chase for
that, right. What's the industry best
practice and you know, just follow and implement that in the
organization. But I think like what you
mentioned, right, system has a lot of dimensions, it's not just
one aspect. And actually capturing metrics
is also difficult and could be expensive as well and in the end
it may not. Be accurate, yes.
Accurate, but also sometimes partial, right?
And there's something else. Every time you have a metric and
it has management's attention, maybe it comes up in management
meetings or it's somehow has to do with allocation of budgets or
rewards or what have you. People will modify their
behavior. Like if you have velocity X, if
you measure velocity at all and you want to increase it,
everybody is going to infer that velocity is important, so
they'll work on increasing it at the expense of something.
I don't know what that is. I know what usually is, but I
don't know what it's going to be in your case.
Or what's another metric. Escape defects, Escape defects
are really, you know, that's a good metric to know, right, the
defects that you discover in production.
But what do you do about it? Do you use it as a signal for
changing the way of working so that you're better?
Or do you use it in a blaming way or in a way to put people on
improvement plans or I don't know what, but every metric is
going to have some form of consequence.
And maybe AI can do this for us, but we are not in a position to
know what all those consequences are going to be.
So I'm not against metrics, but I want you to use them with
caution and I want you to have just a few and I want you to be
very careful what you say and don't say and do and don't do as
a result of a metric. So that's why again, this model,
it assesses fitness. And by the way, also as a
relative measure, not as an absolute.
It's not like you deploy 50 times a day, therefore you're
elite. No, because it could be that
deploying 50 times a day is totally useless for you.
Yes, your team has built it, but it actually makes no real
difference to your business. And it could be that deploying
once a month is perfectly fine for your business context.
And maybe the theoretical optimum that is again relevant
and practical is every two weeks.
OK, so you're not there yet, you're not doing great on that
aspect. Fine, but it's not like you're
doing poorly because it's once a month and everybody's talking
continuous delivery. Yeah.
I think don't forget, right? People behave as how they're
measured, right? So always think consciously the
kind of impact when you create measurements and metrics.
So, GAIL, thank you so much for sharing about your model and
also delivering better results. The book, right.
So for people later on, we'll put it in the show notes, right,
some of the links that they can check out.
I have one last question that I would like to ask you before we
end the call. Right.
So this question is called the three technical leadership
system. You can think of it just like
advice you want to give to us, the listeners.
So maybe if you can share some of your 3 technical leadership
system. OK, so one of them that will
come as no surprise because we've talked about this
regularly. Work with your colleagues across
the system, so not just send your silo, make choices with the
system in mind. It's always good to have
connections, friends who do slightly different work, but you
all contribute to the same thing, and #2 is really people
before process. There's a quote from Deming that
says that a bad system will beat a good person every time,
meaning you can have the most wonderful I CS and managers and
whatnot, but if the system is broken, they will not perform at
their best. They will struggle, They cause
mental issues, all sorts of things.
And the third thing, we haven't touched about this today, but
it's a big one for me. Your words reflect how you
think. If you ever refer to people as
resources, what are you communicating by that word?
If every work item is a ticket, what is that communicating and
how does that affect the motivation of your team?
I don't know. For me, ticket sounds like
there's an endless flow of them and they're boring.
That's that's me. If meetings are ceremonies, are
you implying that they are repetitive and boring, and
you're doing them because somebody told you to?
Every word you use carries some associations and connotations,
and there are many words that we're just used to using, and we
don't even notice the effect that they have.
So your words matter. Right.
So I think that's really important.
Yeah. Sometimes we unconsciously pick
a word and maybe even like from the industry practice, right.
Ceremonies, right. You mentioned.
So I think some blog posts mentioned about that.
So I think do choose the correct words in your context.
And especially people have different cultural background
these days and some words actually matter a lot more to
some cultures. So, Yale, for people who would
like to follow you or maybe ask you something online, is there a
place where they can reach out? Yeah.
So the main place to do this is LinkedIn.
But I think I would like to offer and we we mentioned this,
I would like to offer or listen there is something even better
or like a next step, something that they can immediately put
into use. And that's the first chapter of
the book. It's not an introduction, it's
actually both foundation for the rest of the book and you heard
good deal about this today, but it's also a just enough read if
you're a busy leader or your boss is a busy leader.
So in like the 20 minutes it takes to read it, you get all
the highlights, all the key points, whatever strategy is
like and you get this in a written fashion, right.
So you can also share that with colleagues or executives so you
can all develop the same mental model.
That chapter also includes the fitness assessment tool that I
mentioned, so I've made this chapter available to our
listeners at a worthy URL. It's called Heard on
podcast.deliverbetterresultsbook.com. Right.
Yeah. We'll put in the show notes for
sure, right. So yeah, and I've read the
chapter one right. It's not the introduction kind
of a chapter. Definitely.
It's very useful by itself. So thanks for sharing that for
the listeners. So thank you so much for your
time today, Gil. I really learn a lot, You know
some of the concepts right And I hope listeners here also learn
as well. It's been a pleasure.
Thank you. Thank you for listening to this
episode and for staying right until the end.
If you highly enjoyed it, I would appreciate if you share it
with your friends and colleagues who you think would also benefit
from listening to this episode. And if you're new to the
podcast, make sure to subscribe and leave me your valuable
review and feedback. It helps me a lot in order to
grow this podcast better. You can also find the full show
notes of this conversation on the episode page at Techly
journal dot dev website, including the full transcript,
interesting quotes, and links to the resources mentioned from the
conversation. And lastly, make sure to
subscribe to the show's mailing list on Techly journal dot dev
to get notified for any future episodes.
Stay tuned for the next Techly Journal episode, and until then,
goodbye.