This was where we pivoted end of year one, running an agile
transformation. We realized the error of our
ways and we pivoted. We took down all of the posters
that said agile and we put up posters that said better
products, faster. We've since pivoted the Simon
said to better value sooner because that's the goal.
We're going after quality, value, time to value, safety and
happiness. The goal is not agile.
The goal is not DevOps. The goal is not cloud.
The goal is value, time to value, safety, happiness and
quality. Hey everyone, my name is Henry
Surya Virawan and you're listening to the Technical
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, everyone. Welcome to The Technical Journal
Podcast, the podcast where you can learn about technical
leadership and excellence from my conversations with great
thought leaders in the tech industry.
Don't forget to subscribe on your podcast app and social
media on LinkedIn, Twitter and Instagram.
And also on YouTube and TikTok for video contents and to
support my work in producing this podcast.
You can either buy me a coffee at techlyjunal dot def tip or
become a patron at techlyjunal dot def patron.
My guests for today's episode are Jonathan Smart and Simon
Rohrer. They are the co-authors of
Sooner, Safer, Happier. In this episode, John and Simon
shared how we can deliver better outcomes in a more human way of
working by delivering better value, sooner, safer and
happier. They shared several principles,
patterns and anti patterns described in the book such as
focusing on the outcomes, the leadership team as the team
number one and the important role of leadership creating
intelligent flow. Why we should stop starting and
start finishing instead? Creating alignment and having
the ability to unlearn and relearn for a successful change
transformation. I hope you enjoy listening to
this episode and find it useful. And if you do, please help share
this with your colleagues, your friends and communities and
leave a 5 star rating and review on Apple Podcasts and Spotify.
It will help me a lot in getting more people to discover and
listen to this podcast and I really appreciate it.
Let's go to my conversation with John and Simon after quick words
from our sponsor. Are you looking for a new cool
swag? Techly Juno now offers you some
swags that you can purchase online.
These swags are printed on demand based on your preference
and will be delivered safely to you all over the world.
Where shipping is available, check out all the cool swags
available by visiting Techly, Juno dot dev shop.
And don't forget to brag yourself once you receive any of
those swags. Hello guys welcome back to
another new episode of the Technician podcast.
Today I have with me Jonathan Smart and Simon Rohra.
They are the co-authors of a book titled Sooner Saver
Happier. I don't know why you didn't put
the better value there. I guess it's too long.
So today we'll be talking about the book, and seems like from
the title itself, I'm quite intrigued, right?
Sooner Saver. Happier.
Who doesn't want this, right? So maybe later on John and Simon
will tell you what do they mean by having all these attributes.
So welcome to the show, John and Simon.
Thank you. Thanks for having us.
Thanks, Henry. Right.
So in the beginning, maybe if you can give a little bit of
background about who you are, right?
Maybe if you can tell us about higher highlights or turning
points in your career, I'll go first.
So this is John Smart and I started out on the trading floor
in investment banking as a business technologist And that
something that's been important to me right from day one is
knowing as much about the business that you're working in
as technology. And I think that's a key
competitive advantage. The way I've always described it
is, you know, I started out as a developer on the trading floor,
so 51% technologist, 49% the business, maybe even 5050.
It's our business, not the business, is part of my belief
system And starting out on the trading floor, we were naturally
agile. This was in the early 1990s,
This was before the Agile manifesto and we were delivering
value continuously, multiple times a day in a small
multidisciplinary team. So for me, the topic of ways of
working is back to the future. It's how I've always worked.
I have experienced waterfall, big batch, sequential ways of
working as well. So I know how suboptimal that
way of working is. And then this led to me leading
ways of working across Barclays Bank.
At the beginning it was 120,000 people, 40 countries learn a
load of lessons and that led to the book.
So that's me. Okay and be just as brief.
So my career started in the early 90s, pretty much the
opposite. My first job was in working on a
sonar system for A. Submarine.
You could not have got more waterfall.
I came in, I think about two or three years into the program and
it was not going to deliver anything to a live system until
about about four or five years later.
I left long before that. I had three years in my first
job, so that was a little frustrating.
I then went into consultancy and soon got placed Financial
services organization. And a year or two into that,
somebody passed me a copy of the Extreme Programming White book.
Extreme Programming explained, embraced change.
It resonated with me incredibly well.
It was how I had been working then, once I'd started in
financial services. So that was the real sort of
turning point number one in my career.
And then about 1314 years later I was working in Barclays and
had the opportunity to work with John ways of working team there.
And I guess that was pivot point #2 for me.
And then John invited me to to write a chapter in the book so
that. Was fun fact I was there as well
at Barclays, although we probably didn't know each other
back then. So I think it's a little
nostalgic moment for all of us here thinking looking back,
what's the project all about? But today we will not be talking
about that project for sure. So I read the first few chapters
of your book, especially the intro, right?
I think there's one fun insight that I would like you to explain
to the audience here about the rapid change of technology
companies, right? Companies who used to be in the
top, for example, I don't know, like SMP 500 and things like
that now suddenly change a lot. So maybe if one of you can
explain to us what is this the age of digital that you're
referring to in your book. Every 50 to 60 years there are
repeating technology led revolutions starts in 1771 with
the first industrial revolution. After that we have the age of
steam and railways, the age of electricity and heavy
engineering, which is Taylorism, the age of oil and mass
production, which leads us to the Toyota production system and
lean. But it's all mass production and
now we have the age of digital. So the previous four technology
revolutions are all about mechanization, mass production,
output output output output, division of Labor,
specialization. So our ways of working in large
organizations have evolved in the last 250 years to suit mass
production and that includes the traditional approach to change.
And if you look at, for example, PMIPMP, Project Management
Institute, Project management, professional qualification, it's
sequential. It's yeah, we do all of the
planning, we do all of the analysis, we do all of the
design, we do all of the build and then we deploy the project
and then the project is declared done.
Unfortunately, that's not how reality works.
It's not knowable, unique change is unknowable and the big
thinking error, the big fallacy. And this was written about by
Royce, who wrote the white paper, the first white paper
that referred to the term waterfall.
He said this invites failure and it's basically a silly thing to
do. And in the white paper in 1970,
whatever it was, he actually had an iterative process was what he
recommended. So we've been living this
fallacy of treating unique, unknowable change like it is
knowable. It's been a collective thinking
error. And in large companies we've
then had projects with drop dead dates and milestones where the
definition of success is hitting a milestone in a plan Not did we
achieve the outcome we were going after.
And the management reporting and the committees are looking at a
rag status at red Amber green and the red rag status is are we
on track for the date and the output rather than what value
have we realized and what have we learned.
So you know now we've pivoted into the latest technology led
revolution. A lot of the manual work has
been automated, whether it's physical robots on the assembly
line, building cars, whether it's knowledge work, customer on
boarding, payments, insurance claims.
A lot of it is automated. So we humans in companies trying
to do stuff. Increasingly we're spending our
time on unique, unknowable change.
And so that's why we have this big pivot where every company on
the planet at the moment, it seems, is on this journey to
adopting agile ways of working. Right.
I think it's pretty interesting. In your book you classify all
this as an emergent kind of work, right?
It is a knowledge work. It's emergent, unknowable.
What do you mean by all these attributes, right?
Emergent, for example. Is it something that always
changing, like something you can't predict?
Maybe you can touch on a little bit about this.
Yes, I think again it is the nature of change in the modern
world, a lot of consumer. Facing products, you really
don't know how they're going to work, what success you are going
to get until they actually reach the market.
And typically this is called sort of sense and respond type
delivery rather than predictable delivery.
Again, it goes back to that thing that in mass production
you planned a thing, you delivered a thing and that was
what the consumers wanted. But again in the age of digital.
Well, to an extent the consumers don't know what they want until
they've got it in their hands. And then they might want more
and they might want lots more and they might want more the
same or they might want something entirely different or
they might want that this month. And then the world changes and
trends change and they want something different.
And working in this age of digital requires that approach
of sense and response. So sense what the consumers?
What you think they want based on data, what they actually want
based on tracking what they're using and then again respond and
the most responsive companies win.
And I think in your book you try to capture some of the
principles patterns and anti patterns, right?
So maybe if you can tell us how this idea came about and how do
you actually distill all these principles, patterns, anti
patterns? Maybe if you can elaborate a
little bit more. So the book is learnings from
the four of us, the four authors of the book.
For all of us, it's a career's worth of learnings.
So there's very approximately, I don't know, 100 to 120 years of
learning in the book just from the authors.
But also there's learnings from about 40 other companies as
well. So I lead a community of
companies that share on this topic and companies in my
network and research for the book and the case studies in the
book. So these are learnings from
ourselves firsthand, and from many other large organizations.
Patterns are approaches to change that will generally lead
to a good outcome, and they'll give you a tailwind.
They will make a hard job slightly less hard, but it's
still a hard job. And anti patterns will give you
a headwind and they will make a hard job harder.
It doesn't mean that you won't be successful, but it definitely
means you're making your life harder for yourself.
So why would you And we have made all the mistakes so that
you don't need to. We have failed fast and often so
that you can succeed sooner. That's what the patterns and the
anti patterns are Key point there.
There is no playbook. There is no one-size-fits-all.
That's why I like the words patterns and anti patterns that
usually successful usually less successful.
With the anti patterns, there is no playbook because every
organization is unique. Because every organization is a
complex adaptive system. Every organization has its
unique history and culture and incentives.
Wow, I think that's a great pleasure to read this book
because you distill lots of experiences from four of you
from many different companies as well.
And there are about 8 principles including patterns and anti
patterns inside each of the principles.
Let's start with covering some of the principles that we can
for today, right? I think the first always have to
start with the title of the book, Which is sooner, safer,
happier. But actually the first principle
that you mention is about focusing on outcomes.
You include better value, sooner, safer, and happier.
So tell us more about this Beefy SSH, right?
Because to me it sounds like an ideal thing, right?
So can we really achieve this? I think we can and I think to an
extent we have to. I think the idea with BVSSH is
achieving a more humane world of work.
It goes against counter some of the things that again some of
the sort of high level anti patterns we've seen which is
just focusing on value or just focusing on.
Faster we evolved better value sooner, safer, happier.
We started with faster. And it's not.
It's about faster, it's about sooner.
It's about time to learning and flow.
So value is at the heart. Value is the thing that makes
your business unique and we'd recommend that's measured with
objectives and key results. So value at the heart, but not
value at any cost. There's then the full balancing
factors of better, which is quality sooner, which is flow.
Again, time to learning. Safer, which is agile and
fragile. It's in particular in the sort
of industries we've worked in where there is compliance,
regulation, security, data privacy, and making sure that
all of these things are done but done in a modern, collaborative
way rather than sort of traditional adversarial way.
And happier, which is happier customers is the obvious one.
But happier colleagues, Happier citizens?
Happier climate as well and Henry to add to what Simon said.
The origins of these words is and the big lesson learnt and
this is chapter one of the book is if you want to do an agile
transformation the biggest learning is don't instead focus
on the outcomes. So to build on what Simon said
better value sooner, safer happier is instead of inflicting
an agile transformation. So the big learning here is back
in 2015 I was the head of the Agile transformation for that
organization. And effectively when I met with
leadership teams, the narrative was, hi, my name is John and I'm
here to make you do Agile whether you like it or not.
As you can imagine some people were like, yay, this is amazing
and other people were like get out of my office.
We got to the end of 2015 and we realized our mistake, which is
we've just been focusing on Agile.
And despite having been an Agile practitioner since the early
1990s, we still made this mistake.
We were measuring the outcomes, but we haven't made them the
headline. So the main headline, the main
measures were how many Agile teams, how many product owners,
how many Scrum Masters, how many people have we trained in Agile
training? Those themselves are not
valuable and you can do Scrum all you like, but your outcomes
cannot improve Nokia Mobile Symbian.
The Symbian development team were doing Scrum, but Scrum
didn't save Symbian. It was a lack of psychological
safety that killed Symbian, according to the chairman of
Nokia. So this was where we pivoted end
of year one running an agile transformation.
We realized the error of our ways and we pivoted.
We took down all of the posters that said agile and we put up
posters that said better products faster.
We've since pivoted, the Simon said.
To better value sooner because that's the goal.
We're going after quality, value, time to value, safety and
happiness. The goal is not agile.
The goal is not DevOps. The goal is not cloud.
The goal is value. Time to value, safety, happiness
and quality. So that's how those words came
about. Thanks for sharing this insights
I would say, right. So still many companies I would
say pursuing agile transformation I think.
And instead of focusing on doing agile transformation, making
teams to become like agile teams, maybe we should focus a
lot more on the values, on the outcomes.
And you summarize that as part of the socalled patterns, right?
Focus on outcomes, start with why, and empower the how.
So for people who are still stuck in this agile
transformation mode, what would you advise to them to start
focusing on the outcomes instead?
So what made the switch that last time you mentioned that you
took down the HR posters? What is the first few things
that you do in order for people to start focusing on the
outcomes and values instead of just the HR thing?
Start with why? Always start with why?
Why change? And nothing to do with that job,
just why change? Why don't we carry on working
the way we're working today? And if is everything OK?
So that's the question I usually start with when working with
teams or leaders. And if the answer is, yeah,
everything's okay, carry on, then don't change.
I've never yet met someone who said, yeah, everything's okay,
okay. So if it's not okay, what are
your biggest problems then? Well, we've got a lack of
alignment. We don't have a shared
definition of value. It takes us too long to get
change. Our competitors are quicker.
We want to increase our customer Net Promoter score.
There's always a list of things. So theory of constraints, what's
your biggest impediment? Therefore, what's your biggest
enabler? And that's the why.
So the why is we want happier customers, We want quicker time
to value. So be really clear on the why #1
#2, make sure you've articulated your measures of success.
So if you want happier customers and quicker time to value, how
are you going to measure that number one, Net Promoter score,
for example, #2, lead time from committing to the work to
getting it in the hands of the consumer.
So #2 make it measurable and that Okr's are very good for
that objectives and key results. The O is the outcome you're
going after. The KR are the measures.
For example, better value, sooner, safer, happier.
You can turn that into an OKR or a number of OK R's.
So that's what I would advise. Start with why.
Be clear on the outcomes, make them measurable.
Make sure you are measuring the things that are measurable.
So you need a data team or somebody doing data full time
and then use that data as your feedback loop.
And then with agility, build, measure, learn, observe, Orient,
decide, act, plan, do check, act.
And you also emphasize empowering the how, right?
So for leaders out there who are thinking of leading all this
transformation. So let's say they have come up
with the outcomes, they have come up with the whys.
They understand why the need for the change.
How do you empower the people? Because some people may be stuck
in the traditional mindset or the traditional ways of working.
So how do you empower them to do the how in the new way?
So we would advise again from our anti patterns not to do
this. Centrally, not to have one sort
of ivory tower wise set of people saying this is your new
way of working. What we advise is a sort of
fractal arrangement, a Federated arrangement to enable people and
to have a Federated center of excellence.
So depending on the size of your organization, great, have
something at group level like we were, but then federate that
sort of helps that enablement down as close as you can to the
individual teams. And say guys, here's some
experts, some ways of working coaches.
Again, they're here to help you. You've told us you want to
improve. So here's some people who have
some ideas, have some patterns, and we'll work with you and your
context and understand the sort of pace of change and the pace
of learning and unlearning that is appropriate for your team and
we'll work with you. So it really is sort of bring
the help to the teams rather than inflicting on the teams.
Yeah, and to build on that, the how then without fractal
support, the how could be agile, it could be lean if it's
repetitive noble work. It could be in some cases,
because of the historical baggage, it could be smaller
waterfalls. So then we're not being
prescriptive around. You must do scrum or you must do
some form of Scrum scaled. It could be the Kanban method,
like I said it could be. In one case it was actually.
Take your 12 month waterfall, do a six month waterfall.
Once you've done that, do three month waterfalls.
Once you've done that, do a two-month waterfall.
Then do a one month waterfall. Before you know it, you're
exhibiting agility without doing agile.
So there's an empowerment in autonomy and now there is one
thing that is needed. However, for that to be
successful, there has to be an incentive.
Because if there isn't an incentive to change, people
won't change because change is difficult.
It's fearful. You're going to fail.
It's going to feel uncomfortable.
I'm not sure I can do this. I might fail, I might lose my
job, I might not be able to pay my mortgage, put food on the
table, feed my family. So therefore there has to be an
incentive. The flip side of incentive is
threat, and a lot of companies miss this point.
You have to minimize threat, nurture, psychological safety,
the number one determinant of high performing teams and
organizations, and you have to maximize incentive.
And from a neuroscience perspective, our brains are
still wired to not be eaten by a tiger, so we have loss aversion.
We are more likely to avoid losing something than gain
something. It's more painful to lose $100
than the benefit of winning $100.00.
So we humans, we would rather do nothing than do something and
fail. So therefore we have to maximize
incentive. That can be implicit incentive
and it can be explicit incentive and we have to minimize threat.
But usually if a company does a top down Big Bang, we're going
to do squad to tribes, chapters and guilds, we're doing a reorg.
10,000 of you are going to lose your jobs.
The threat is high with that type of approach.
So yeah. Yeah.
So I can see from my previous career experiences as well,
right? So many HL transformations is
always coming from the top down, from new leaders.
They come in, they bring in all this.
You know, we have new ways of working, new roles, new
everything, right? And then they enforce people at
the bottom to actually adopt these practices.
And I think it's still happening these days as well, although I
don't work in such an enterprise anymore.
And that's why we go to the next principle, which is about the
leadership role, right. So if listeners here are the
leaders, so you say in the principle, leadership will make
it or break it. So tell us more about this
important principle so that leaders can understand what is
actually their role in all this change of the ways of working.
Leadership is the biggest enabler.
It's also the biggest impediment.
It's the biggest lever, and that's because change is 80%
culture, only 20% process. So doing Scrum won't help.
I mean, it might help, it will help a bit, but you know, if
you've got a bad culture, you'll still have a bad culture and the
outcomes won't necessarily improve.
So there are three key behavioral traits.
I believe the top three behavioral traits are #1 role
model, the definition of leader. The definition of the word lead
is to guide from the front to guide on a journey.
That's the etymology of the word lead.
So lead from the front role. Model the behaviors you expect
to see in others. For example, a couple I'm going
to come on to like. Psychological safety,
experimentation, empowerment, autonomy, servant leadership,
intent based leadership. How can I help?
So that's the role. Modeling #1 #2 is psychological
safety, nurture and environment which is psychologically safe.
Now what that means is minimizing a culture of fear,
because people need to be able to experiment and fail without
fear of failure. And I'm talking about
intelligent failure here, Not stupid failure, not deliberate
failure, not being fraudulent, but, you know, actually trying
to improve. So that means having a blame
free culture. It means setting the stage.
This is a behavioral trait that is important.
It means inviting participation. And then it means responding
positively. And those steps 123, those are
from Amy Edmondson, who wrote a book called the Fearless
Organization. So that's Psychological safety
Project Aristotle. Google determined that
psychological safety is the number one determinant of high
performing teams. And then #3 is an emergent
mindset. As a leader, that means
acknowledging that the future is not knowable.
So therefore we're going to have outcome hypotheses, which we're
going to test. We're going to run experiments.
We're going to try to turn the unknowable into knowable.
The opposite of an emergent mindset is a deterministic
mindset where we treat the future as if it is predictable
with a Gantt chart, with a 24 month project plan, with
milestones and language like drop dead date, which is an
analogy of death. So those are the three key
behaviors, role model, psychological safety, and an
emergent mindset. I really love the way you
summarize it though. I think the first key thing be a
role model, right? You mentioned it in your book.
The pattern is leaders go first, right?
So showing the example, maybe doing 7 leadership, intent based
leadership, right, then nurture psychological safety.
And then the third is actually the emergent mindset, right.
So don't think things could be determined, doing a lot of
analysis and you know, upfront big design and things like that,
but doing it as a series of hypothesis, right, outcome
hypothesis. So I really love that.
And I think that's also one thing in particular I found when
I read that chapter right, you mentioned that leadership team
is actually the team #1. So especially in some companies
where the leadership team probably is a bit dysfunctional
that have ego, they have politics.
So could just tell us a little bit more about this part?
So yeah, concept of the leadership teams team number one
is start with the leadership team, ideally the most senior
leadership team possible on this journey in terms of.
Ways of working. You will have a bubble of ways
of working, anchored at the top by the most senior leader who's
supporting it. So if it's not the CEO of the
company, you'll have bubbles of better ways of working in a
company, but it won't be able to span the whole company.
And when you go and talk to finance or HR or procurement,
there's no incentive to have a conversation about improving our
ways of working. If it's not coming from the
executive committee, the top table, so leadership team is
team #1 and that's because the more senior the leader you are,
the bigger your shadow. And it also comes back to this
word incentive. This whole topic boils down to
one word, which is incentive. And the senior leadership team
can create the incentive, the explicit incentive the most
senior leadership team can say. It is one of our top three
priorities for this organization that we continuously improve how
we do what we do. Bingo, everyone's in.
You put it in your performance appraisals, your appraisal, your
promotion, your pay is dependent upon you continuously improving
how you do what you do, including your behaviors like
psychological safety, servant leadership and so on.
Now in terms of your comment, Henry, about often there are
leadership teams that are political or dysfunctional or
whatever. Obviously, as humans, change is
messy. It's always organized chaos.
In a way. We are emotional, irrational
human beings and also we have our own get back to incentives.
We have our own incentives and threats.
So often if you have a team of people and there is a lack of
harmony in the team of people, typically it's because people
feel threatened and either they know that they feel threatened
consciously or sometimes people subconsciously don't even know.
That they feel threatened. So it could be because you've
got two people who are competing to become the leader or to be
promoted because there's only one promotion spot, but we've
got two people. And that leads to some negative
behaviors around I'm going to withhold information or I'm
going to. It's like politics, isn't it?
I'm going to dig out dirt on you so that you don't get promoted
and I do. And that's a problem with our
appraisal system rather than having shared goals.
Having siloed goals and OK ours can help solve that problem.
So my personal philosophy on this is empathy, kindness, and
understand what people's motivators and incentives and
threats are. Because there are very few
people who are deliberately setting out to be a pain.
Very few people. There are a few people who are
just not sound people. Very few.
And it's unfortunate that there are some companies that tolerate
some negative behavior. So that's very rare in my
experience. So figure out the incentive.
One other thought to add is the diffusion of innovation curve.
You'll have innovators on the left.
You'll have laggards on the right, any group of 10 people.
You will have innovators on the left and laggards on the right.
Identify your champions. It might be one or two people in
the leadership team for all of your energy behind those people.
Don't try to convince the laggards of anything, just leave
them be. And just to add to that to build
on that. I think one of the things that
I've sort of found practically really useful here is that focus
on the movements, the focus on outcomes, where previously
you've got sort of hippos highest paid person's opinion on
the next thing that they think would be good to do.
If you're focusing on outcomes, if you're focusing on
measurability, transparency and especially if you're focusing on
a sort of cascaded OKR objectives and key results
framework where the highest level goals of the organization
of transparent, so the North Star style goals and then
everything aligns not necessarily cascades but aligns
to those and the measurable outcomes that everybody in the
organization is working on are clear.
It's not a silver bullet, it's not going to solve everything,
but it definitely helps aligning people and taking some of the
politics and some of the egos out of some of those decisions.
Thanks for adding that. So I like the way that John
mentioned, built the right incentives, right and also
create like nurture the environment so that people are
not threatened, They want to cooperate and focus on the same
outcome, like someone said aligned with the same outcome,
which brings us to the next principle, which is the build
the right thing or intelligent flow.
In the beginning you mentioned about flow, lead time and all
that. So assuming that we have a good
outcome set, we know what we want to achieve.
The why? We have the fully functional
leadership team, so how to translate this to building the
right thing and creating this intelligent flow?
So intelligent flow build the right thing, it segues nicely
off of what Simon said which is outcomes and in particular the
important thing here is the golden thread of value is the
important thing and aligning strategy to execution and vice
versa. So you have your multi year
outcomes, your annual outcomes. Double click your quarterly
outcomes, double click monthly experiment, weekly iteration,
daily story. Now if you have all of that in
some tooling that's really powerful because you could be
working on a one hour task or a one day story and you can see
how your work aligns to the multi year strategic intent.
So this is the golden thread of value.
Super powerful because you then end up with two way strategy.
So usually strategy is one way. Top down, fire and forget.
Here's our three-year strategy with very little feedback loop.
Now we can have effectively a daily if we wanted to, we could
have a daily feedback loop on our multi year strategy.
So for example, we might have a multi year ambition to be the
number one brand in our industry in three years.
We want to increase our market share in, let's say, North
America to go from #3 to #1. By the end of the year, we want
to be in a subset of our market market share.
We want to go from #5 to #2. By the end of this year, in the
next quarter, we want to double our sales in New York City.
To do that, we're going to run a promotional Instagram and
Facebook, and we're going to do that in the next month.
So that's an example of how you might slice the outcomes.
And the important point here is to the point of the quarterly
outcome. It doesn't say how we're going
to do it. We're articulating the outcome.
We want to double our market share.
We want to increase our sales in New York City.
The boundary is when you go from the quarterly OKR down to the
monthly EPIC initiative experiment, now we're in output
land. So you end up with both an
outcome road map, which doesn't change very much.
And at the same time, in parallel, you have an output
road map, which is your product road map, and you will have an
architecture vision, an architecture runway, a product
vision. You know, UXCX, everything else.
However, your product road map should be pivoting all over the
place without change control. And your outcome road map won't
change much because, you know, we thought that doubling our
sales in New York City would lead to us increasing our market
share in the US. Turns out it doesn't.
We were wrong. We need to be selling more
products on the West Coast. Quick, let's pivot.
Let's double our sales in LA and San Francisco.
Let's run a promotion. So that's how you focus on
building. The right thing is through the
OKRS objectives and key results through the KR.
A regular cadence on the KR and you pivot your output.
Thanks for the example of how the OKR alignment works, right.
So one maybe extension from that example, right.
So typically in some companies that I see is that instead of
just pivot means like change from what they're doing.
They create a new initiative, maybe a team, you know, whatever
that they set up, meaning that they will add more initiatives
inside the company. And in your book you mentioned
this stop starting, start finishing, right.
So I think that's a very, very important pattern I would say.
Maybe if you can elaborate. Furthermore, what do you mean by
this? Stop starting and start
finishing. So really this comes down to
smaller batch work. It's down to some of the sort of
lean approaches that say any feature that's not in front of
the customer, that's in the middle of being delivered is
eventually and two degrees waste until it's there in front of the
customer. Goes back to what we said
earlier that what we're trying to really improve on is time to
learning. One of the patterns to improve
time to learning is to deliver smaller and smaller and smaller
chunks of. Value.
Get them in front of the customer soon.
Get them done. If that works, do more.
If it doesn't work, if the indicators, the key results that
you're seeing are showing that actually, again, you need to
pivot or change, then do that. The only way you're going to do
that is by delivering valuable features faster, and one of the
tactics to do that is to make them smaller.
So thanks for sharing that, Simon.
So I think, yeah, focusing on bringing it to the customer
instead of finishing in, I don't know development or in testing.
So that actually doesn't mean anything.
So in lean, they categorize that as ways, right.
So by delivering value, it means that you deploying it to
production and being used by the customer.
So I think that's very, very important concept from AGR, from
lean, right. So don't focus on too many
things at once, right. Try to deliver that as early as
possible. Ultimately, I'm sorry, Henry,
there's this sort of definition of done thing for me.
It's fairly simple. It's done when the customers
using it. That's it.
Yeah, thanks for emphasizing that.
So another key thing about doing all these ways of working is
about how people can get into it right, can adapt to the ways of
working. First of all, understands also
the need for change the techniques that they're going to
use, right? How do they come up with the
how? How they come up with the road
map alignment and things like that?
And how do you actually bring people so that they can all
align, they can all get upskilled, they can all have
this learning ability. So maybe some tips from your
previous experience, past projects, how can you align
people so that they are into this change?
So again, start with the why. So that's step number one.
There has to be a clear why for change and that why should
ideally appeal to the individual team, the organization, to
clients. And to society.
Now usually when an organization articulates why change, it's
purely for the company. And that articulation doesn't
cover why change for the individual, for the team or for
customers or for citizens for society.
So usually the why is not well articulated and the why
typically comes from usually a focus on shareholders.
Yeah. What do we need to do to
increase the share price to achieve our own personal
incentives at the executive committee level?
Where the incentive is typically aligned to the financials not
surprisingly in the current construct.
Good news is you know there's a bit of evolution on this.
So it's not just shareholders, it's stakeholders and
stakeholders is a broader term which is good that includes the
planet. So that's good.
So start with Y with the balance Y and then once the Y is clear
invite over inflict because we want the Champions, we want the
passionate people and we want to minimize threat.
If it's inflicted upon people, it's very threatening.
And there'll be lots of antibodies to change.
The change will be rejected. In some cases it will be
sabotaged if it's perceived to be threatening.
So invite to participation. And again, there needs to be a
clear incentive here. So the why is part of the
incentive. But also there should be both
implicit incentives, which is as an element of social proof here.
So the implicit incentive is all my colleagues are doing this and
they're having a great time and they're loving the new ways of
working. I want to do that too.
Don't leave me out. FOMO, fear of missing out
explicit incentives is pay, promotion, performance
appraisal. And again, that's not about
doing Agile. It's not about are you doing
Scrum, it's have you improved your outcomes, quality, value,
time to value, safety and happiness.
And I think, Henry, that's the recipe you need really, a clear
why a clear incentive invite participation to continuously
improve, aligned to measurable outcomes, and then you're off to
the races. You know, maybe just one thing
to add is there are minimal viable guardrails.
A wide Rd. with high curbs. There are some things that are
just not negotiable. Information security, data
privacy fraud, anti money laundering compliance.
Depends on your industry. There are some controls that are
non negotiable, but within them knock yourself out.
I like the term minimum viable guardrails.
This is like the constraints, the boundaries, right?
So it's like the hard rules that people cannot.
You know, violate, I would say. But apart from that, they are
free to be creative, try to adopt the new ways of working.
Another thing that I think I found really interesting in that
particular chapter about learning is that you said that
people have limited velocity to unlearn and relearn, especially
for leaders who come with this agile transformation mindset.
They all want a fast change, right?
Like people have to adopt from 1:00 to 2:00 to 3:00 to 4:00 and
suddenly they become all agile teams, right?
So tell us about this important thing about limited velocity.
Yeah, the pace of change is determined by the speed of
unlearning and relearning. You can't force the pace of
change in an organization. You have to read the tea leaves.
You have to do sense making. So if the speed of change is
determined by the speed of unlearning and relearning, the
next question is how do we increase the speed?
Assuming we don't want to take too long with change, and we
want to do it sustainably, how then do we increase the speed of
unlearning and relearning? So, Henry, what do you think is
the number one determinant of the speed of unlearning?
Well, there are a few things in my mind.
The 1st is whether we want to change.
That's the first thing, right? Coming back to the why, why we
have to change. The second thing is I have so
many work that I'm doing as well.
So these things seems new and I'm tied up with what I'm doing
now. Yep.
So incentive, incentive to change is one of them, because I
have to now make time for change and then the other one is again
psychological safety. So the speed of unlearning and
relearning is determined by the amount of psychological safety,
the minimal amount of a culture of fear.
If there is a culture of fear and failure is punished, nobody
is going to unlearn and relearn. You will have stasis.
Nobody will change. And there was one organization
I've worked with where the previous leadership had a
behavior of a lot of fear. Messengers were shot.
People were punished. And so the language that I was
hearing from people was that it is safer to do nothing than to
do something. And I mean absolutely nothing.
And I'm not talking here about just change.
I'm talking here about even just your daytoday work.
The pace of work at this organization was so slow, was
because people didn't even want to do their daily work for fear
that they'd get something wrong, never mind changing how they do
what they do. This was just what they do.
It's incredible. So psychological safety, again,
the speed of unlearning is determined by the amount of
psychological safety, minimizing threat.
So that I can say, hey Simon, do you want me to help you out on
that thing you're working on? I've never done it before, but
in order to become multidisciplinary T shaped or π
shaped or comb shaped broken comb shaped teams, I'm going to
jump in and I'm going to learn something about big data or BI
or something. Simon, can you show me how to do
it and then next time I'll be able to take some work and help
you. Yeah we compare on it next time.
So you've got to be able to fail and say you don't know and also
challenge authority which is a learning from airlines.
The first officer needs to be able to challenge the captain to
avoid some bad outcomes and likewise for large companies.
Usually 2 levels up all of the rag status.
The red amber, green status. It's all green green green
because bad news is buried And I've spoken to some senior
leaders who say John if I look at my.
Status reports. Apparently everything's on
track. Of course it's not.
So there you go. Yeah.
It's a classic thing.
I think it's almost everywhere, right?
When you go to the top, right, people always report the greens.
If there's an ember or the red, right, people will try to hide
it or maybe do something, maybe massage the information such
that it doesn't look so bad, right.
So I think thanks for emphasizing again about fear,
psychological safety. Unfortunately due to the limited
time, we have to cut pretty soon.
But I have one last question for each of you.
If you can give us some, what I call 3 technical leadership is
them. So think of it like an advice
that you want to give listeners here to learn from you.
So maybe one of you can start first.
I would say the one piece of advice is listen to people, have
some empathy. There is a great book on clean
language, which we've not. We talked about at all today
called from contempt to curiosity.
People will be doing things that you disagree with.
You'll be genuinely if you are experienced in ways of working
in technology. Our first reaction from any
technologists is WTS is going on here.
But if you take the theory why approach, people are always
taking their best intention and their incentivized to do
something in some way there in a context.
She's led them to do something in somewhere.
Listen to them, talk to them, take them for a coffee cup of
tea and just find out and then put yourself in their shoes.
That's the best place that you can then help them, if they need
help at all. Or maybe you do.
For me, in terms of three pieces of advice, the first one is you
are a leader. Doesn't matter how many years
experience you have, It doesn't matter what your grade is.
Everybody is a leader. Look at Greta Thunberg.
She was at school. And she is a great leader.
So this topic is leaders at all levels.
So you are master of your own destiny.
You are not a victim. One of my personal bugbears is a
victim mentality. So it's not a case of pointing
up and blaming them up there, which is easy to do.
It's also likewise on social media.
It's easy for some people just to be negative or moan, moan,
moan, complain, complain, complain.
Don't just moan and be a victim and point and blame other
people. No, you're a leader.
Exhibit some leadership. And it doesn't need to be
positional power. It doesn't need to be people
reporting to you. You can create a rebel alliance.
And that's what I did back in 2012.
I created the ways of working community of practice in the
organization I was working in. Nobody asked me to do it.
I connected multiple business divisions geographically,
worldwide. We ended up with two and a half
thousand people in this community.
Entirely voluntary, entirely law of two feet.
And we created a movement, we created a social movement, which
ultimately led to, with support from the leadership team at the
top, doing it across the whole company.
So that's my advice. Number one is be master of your
own destiny. Don't be a victim #2 is just
general career advice. And this is my personal
philosophy is get good at every level before you.
Take on your next role and it could be a sideways role.
It doesn't need to be a move up always, especially for
individual contributors, but become a guru at your topic
before you move on. That's been my personal
philosophy. Be the best whatever your role
is you know, whatever your speciality is.
Be the best developer. Be the best scrum master.
Be the best product owner. Be the best product manager.
Be the best leader. Because then in the future,
whether you're an individual contributor or whether you are
leading people, you know the jobs that the people are doing
that you're leading because you've done it.
And that's the philosophy at Toyota.
The leaders at Toyota have been on the assembly line.
So that's a general piece of career advice, that one.
And then #3 is change your company or change your company.
As you create the movement, you create the Rebel Alliance.
Hopefully you pick up champions at multiple levels of formal
leadership and then you change your company.
But however, if there are leaders who don't want to
change, then go and work somewhere where you're happy and
where there is a desire to improve, which is back to the
point around being master of your own destiny.
I really love the last one. Change your company or change
your company. Right.
So I think that's really, really a key thing for everyone who are
not fulfilled in the company because they want to instill
change, but they couldn't, right.
And they are always trapped in this kind of bad ways of
working. So thank you so much for your
time today. If people want to continue this
conversation, any place they can reach out online.
LinkedIn or sooner saferhappier.com.
And we have a Slack community there as well, right?
So maybe we'll put it in the show notes later on as well.
So thank you for sharing today about BVSSH.
So better value, sooner, safer, happier.
So I hope people learn today how we can achieve this ideal thing,
right. So with principles, patterns and
patterns that you put in the book.
So thanks again for sharing this with us, John and Simon.
Thanks so much for having us, Henry.
Yeah. Thank you.
Thanks, Henry. 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
Techlyjournal 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 techlyjuno dot dev to
get notified for any future episodes.
Stay tuned for the next Techlyjuno episode, and until
then, goodbye.