The thing I noticed was the business technology divided so
that was apparent in many companies and a lot of companies
have got on this cannon wave of cloud and move to the cloud and
then the value may be has not been there.
It's just a fancy data center. So we get that real value.
You have to really join the business and technology
strategy. So Lady of the value flywheel
effect is when you join business goals for technology goals, you
start to see this momentum this flywheel effect.
Hey everyone. My name is Henry Surya, we
Robin. And you're listening to the
technology, you know, 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.
Welcome to the package, you know, podcast the show where you
can learn about technical leadership and Excellence from
my conversations with great thought leaders in the tech
industry. It's very great to be back here
again with another new episode. If this is your first time
listening to technology, you know, don't forget to subscribe
and follow the show on your podcast app and on LinkedIn,
Twitter and Instagram and to support my journey.
Creating this podcast, subscribe as a patron at technology.
No, dot f / Patron, my guest for today's episode.
Is David Anderson? David is the author of the value
flywheel effect and the co-creator of the several has
aged in this episode. David described the value
flywheel effect concept and it's four stages, the clarity of
purpose, The Challenge and Landscape the next best action.
And the long-term value, David also explained, the importance
of worldly mapping and how we can use it to help improve the
organization's situational awareness within the value
flywheel during our discussion about the first day.
Yes, we also discussed several important Concepts such as the
north star frame up for clarity of purpose, understanding the
team psychological safety and socio-technical systems,
landscape, the Severus first Paradigm as one way for the next
best action and using the well architected framework and
sustainability as guidelines for ensuring long-term value.
I really enjoyed my conversation with David and learning about
the value flywheel effect. I find that all the four stages
when used with Ellen, in any engineering organization, we can
bring the transformation and the flywheel effect that David
described in his book and this episode and the great thing is
David has successfully used this concept to bring technology
transformation and Cloud adoption at Liberty.
Mutual, so definitely, there are a lot of practical things we can
use within all engineering organization.
If you also enjoy listening to this episode, please help me by
sharing it with others who can also benefit from listening to
it. Also, leave this podcast a
five-star Thing and review on a podcast and Spotify, it will
help me a lot to make this podcast easily discovered by
other people. Let's continue to the
conversation with David after hearing a few words from our
sponsors. Today's episode is proudly
sponsored by skills method. The global community and events
platform with more than 100,000 software professionals here
members, can organize their learning experiences around the
technology topics. They care about most you get
on-demand access. This to their latest content
thought leadership insights, as well as the exciting schedule of
tech events running across all time zones.
So whether the devops our data science is your bus or you are a
fan of functional programming or all things Cloud, you can make
real connections with people who share your interests head on
over to skills method or calm to become part of the tech
community that matters most to you.
It's free to join and you will find it easy to keep up with the
latest tech trends. Are you looking for a new cool
swag tekhelet Journal? Now offers you some swags that
you can purchase online? These wax 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 tracks available by visiting
technology, know the death, / shop and don't forget to break
yourself. Once you receive any of those
tracks. Hi everyone.
Welcome back to another new episode of the package.
You know about Outkast. Today, I have a guest with me
named David Anderson, or maybe I'll call you Dave.
So David is the author of the book, titled the value flywheel
effect. So in this book at this is very
interesting, Journey. He gave some principles or how
he actually did a cloud transformation but it's not just
called transformation. There are some principles that
he also adopt which to him is a successful experience, which he
shares that can be adopted by many other organizations as well
or teams in the world. Specifically David.
He's also a fan of serverless architecture, or Paradigm.
So he has done a large-scale survey last deployment,
especially the experience that he went through for writing the
book. And also he was the creator of
the several has Edge. It's a community that Advocate
several has architecture and some principles and paradigms.
So David thank you so much for this opportunity.
Looking forward to talk about your value flywheel effect and
also the serverless Thank you Henry and thanks for having us
on the podcast and I'm a big fan.
So I'm looking forward to the conversation.
So, David in the beginning, I always like to ask my guest to
introduce themselves. So maybe if you can share a
little bit of your background or turning points in your career.
Sure. So I'm based in Belfast and from
dairy open the very north west of Ireland.
I've always studied computer science.
Always been a software engineer. Now, spent the first probably 10
years of my career working in Telecom a lot of Canada building
big systems are working. It on big platforms.
I then joined Liberty, Mutual around 2007, as an architect
building, an e-commerce system. And I'm looking off to get a CT
opposition and around 2013. And I was very lucky because I
was kind of at the table as Liberty, Mutual started speaking
to a, to the S Vector, public Cloud Journey.
So my background being software, the first thing I thought about
was okay, as we move to the cloud, we're going to have a lot
of security network in fuck. Our policy questions that answer
who is answering the question around.
How do we write software and a cloud native way so I can.
It took on that challenge with my small team and that led to a
large canner served as First Transformation Liberty.
Maybe we can touch and not through the book, like, that's
for myself and my two. Co-authors Mark McHale and
Michael Riley. Figure out this technique that
we call the value flywheel effect.
Our vision was, can we make Liberty?
Mutual, I served as first Enterprise.
Which was a very bold statement especially for a few Architects
and then Belfast but I think we seen a lot of successes and that
Journey we see some fantastic things around modernize and
applications of unlike over. Ninety percent Savings, of run
costs, fantastic speed to Market times seen.
Massive satisfaction from Engineers enable, the reduce, a
lot of the operational. Burden around standing up big
infrastructures and really focus on the business problem.
Deliver business Are you really quickly which also created a
fantastic cohesion between the Business Leaders.
All of a sudden 80 wasn't a bottleneck technology was no a
differentiator. So it really it was a lot bigger
than me driving this but there was a general wave of
modernization transformation in the Enterprise and Liberty.
Mutual been a Fortune 100 one of the world's leading insurance
companies. That's a pretty big company
whose exciting time to be at Liberty and to be driving that
story. And we can we touch on some of
the stories as we go into 1021. Like I said, they can move on
the new challenges and it was an agent Car.
Craft whose x Netflix it with a successful.
This is okay. You have to write a book.
This is too exciting. I had no intention of being an
author. So I thought, okay, I'll try
this author thing and see what happens.
So I told you go to the book and was absolutely delighted.
When 80 Revolution and Gene Kim, authors of accelerate devops
handbook, Phoenix project, team, topology, Etc.
So there are divided, you fly To their fantastic portfolio of
books. I was already in that Kenna,
devops Enterprise Community which is fantastic and really
back to work. I can spend just over here with
bizarre voice as a technical fellow driving, their killer
modernization. And of course, they're working
for globalization Partners or GP, which is very interesting
company. The mission of the company is
taken at the breakdown fire, the global business nipple
opportunities everywhere, Global Employment platform, that you
can hire anyone anywhere in the world.
Those are really exciting. We call it a service first,
well, architect its ass. So we're building an entire
employment platform. It's formed again for me, but I
find really exciting is practicing these techniques and
working with both technology teams, business teams really can
drive that value. So it sometimes we would say I'm
a practitioner who accidentally became an offer, I think very
rare, people wrote a book with, you know, like a childhood
dream. I want to become an author,
sometimes it because of an accident right through
experience, Less than some people, advised them to write
the book and you'll become an author.
Think that's also, one thing that I also found throughout my
interviews, a few guests. Thanks for writing the book, by
the way, it's really a great journey, which I think is worth
to share with everyone. So for people who read the title
of value flywheel effect, some people may be confused.
What do you mean by that? Do you have like, maybe one
statement pitch or value proposition?
What is value flywheel effect and how do you get the
inspiration from? Yeah, well it's really around
the thing I noticed was the business technology divided so
that was apparent in many companies and a lot of companies
have got on the scanner wave of cloud and move to the cloud and
then the value may be has not been their competition.
May be treating the cloud like someone else's data center, it's
just a fancy data center so you get that real value.
You have to really join the business and technology
strategy. So Lady of the value flywheel
effect is when you join business.
This gold for technology calls, you start to see this momentum
this flywheel effect, so it's obviously influence from the Jim
Collins is flywheel effect concept which is brilliant from
good to great and then Jeff Bezos.
Also had this amazones virtuous cycle which is really nice.
Cannot fly will really have with the value flywheel effect.
What we find is the four phases. The first pink, Lord, a purpose.
Let's start with why if we need to be extremely clear, that from
technology and business, we know what our North Star is a new
techniques to help people figure.
Right. The second phase is challenge.
You need to create the right environment that we can
challenge each other in the team.
We can challenge how we're going to achieve that North Star and
set ourselves up for Success. The third phase is next.
Best action. Once you're pretty clear where
you're going and you've got the right environment, you will be
execute quickly and for me that's bringing in some of the
modernization techniques around service exception service first.
And then the fourth phase is long-term value.
We can't build a throwaway. You need to have a really Solid
understanding of what good looks like.
So for me that's a problem prevention culture, which is
running, well, architected and sustainability.
I can we build but build effectively for the long term
not just build quickly. So that is a flywheel that will
continue the turn. It's not just warm and on.
Once you start that momentum and it builds very rapidly.
It's like a rocket ship and then one of the things that you end
up doing as you implement that is removing inertia removing
sticking points. What is slowing down that
movement? Because as you well know, Move
to the cloud is not one and done.
You're an acceleration Journey. It gets faster.
You need to change how you think and how you act.
So if I can probably simplify a little bit for people, you take
the concept from the flywheel effect from Jim Collins and also
the Amazon virtuous cycle. So, what I can relate is that,
it's an iterative process is not like one big bang Journey, where
people now becomes transform, right?
Either moving the technology to the cloud or the business
becomes digitalized or something like that.
It's a virtual stink is a flywheel that's why and also So
it's like a lot of things that you need to align alignment from
business and technology. So it sounds like it's very
similar to some other techniques, which are also well
known things like agile software development of a gel business
Transformations or it could be also deaf Ops or death,
whatever, Ops this days, right? So what actually stands up from
value flywheel effect that probably is different than the
other techniques. Well, there's a mindset so that
for me is across the whole thing between extremely collaborative,
main tools that I used as we created this value flywheel
effect as a technique called Wort early, mapping and worldly
mapping for me. It's a complete Game Change in
technique. When you start to map these
different phases, it gives you Clarity on what you should do
and what you shouldn't do. We can explain what worldly mop
and is for me it's really about that Eddie of strategy and what
should we do next? That's not business strategy or
technology strategy is what do we as a team need to do next and
worldly mapping gives you that Insight greater environment that
you can build that alignment. I discovered this probably
around 10 years ago. There's a researcher in the UK
called Simon wardley. The story was, he was a CEO of a
technology company and he realized when he got the
position of high growth technology company as CEO, that
all the strategy was nonsense in his terms, he didn't think it
was deep enough. Off.
So we come up with this idea of worldly mapping and starts with
the canvas, the canvas has got X and Y axis, the very top.
There's like a value chain. So the very top of the value
chain, you've got a customer always starts with the customer
and what's that customers need. So then there's a chain onto the
customer, Nate for a component which is customer might need,
for example, something like a cup of tea.
The customer needs a cup of tea. So then what does the cup of tea
depend on? It could be like a kettle.
Hot water some tea. Mr. Could build a devaluation of
what things are dependent, the solve the customer need.
So as you think in your head of a value chain going from top to
bottom, the y axis of the map is visibility things at the top of
that chain are very visible to the customer.
The customer is aware of the cup of tea, but they may not be
aware of the cattle or electricity will learn that by
Eugene, but they're very aware of the can see the cup of tea on
the and from left to right in the bottom, this is the kind of
exciting part. Art, that's where the x axis has
in. This is really the evolutionary
access for the evil assure access those four areas.
So the first is Genesis. So every component and that will
evolve and capability. I'll explain that in a second.
So Genesis of things that are brand new, they're like
wondrous. I've never seen this before.
It's fantastic in you. I don't even know I needed.
I've never even thought of this. Next phase is custom.
Maybe we understand how we might be able to build them.
We're not very good at it yet. That's still quite emerging.
The third phase is product things.
In the product phase are. We're starting to get good at
building these and there's a strong customer, need the
customer are aware of these things, and they want them to
read customer demand. And then, the fourth phase is
commodity. So things in commodity, we are
very good at building these, we optimized new basically cost of
doing business and customer may understand it, but it's like,
yeah, everyone has one of those, two evil.
Skinner axis is what's really exciting and the copper T sort
of up the cattle. Maybe commodity, you know, a
cattle is a kettle, it warms the water, the water is likely
commodity the cop maybe product may be given a scope which has
the experience and the T could either be something very Bland
like a standard type of tea or maybe something where you can
have like a high quality, that's real differentiator so that
could be more revolutionary and that every single component will
evolve from left to right. So we think of computers when
computer start being used by business in the 60s, it was just
a thing of Wonder, it was actually in the newspaper when a
company got a computer as photographs of a computer being
delivered to a company. Custom is probably more like the
70s and 80s. There was lots of different
types of computers but they were looking at different and
non-standard and then as we move down to the PC era, became
product, computers are everywhere.
They can a standard get different features to solve the
need lie with Claude. It moved it in the Aditi, it's
not a big deal. Everyone has a computer and you
just read one from somewhere. It's not really a
differentiator. So using that technique to
figure out large strategy, business strategy, engineering
strategy, it gets really interesting to figure out what's
the customer need and then, what does it depend on and we can
figure out what are the things that we needed really good at
the things we can rent from elsewhere, survival has been a
great example that we can actually rent a lot of the
compute and services from a cloud provider, and not have to
build them ourselves. Thanks for sharing this.
High-level overview of bodily mapping.
I'm sure like poor people, maybe the first time you hear it, you
probably don't get it. I would suggest looking at the
canvas itself it will definitely give you a much better picture
and analogy. What David is talking about.
There's a great site by a guy called Ben Mercer called, learn
orderly mopping.com bands, get some great videos where he
explains this cause you can only do as you say, you need to see
the canvas. So I would look at the learn
wardley mopping.com and I also, So have a previous episode as
well about what they mapping, so please do check it out in that
episode. We talk about what they might be
in DDD and some other stuffs, please do check out.
So one thing about what, a mapping that I realize,
especially when you look at these websites, they always say
that you will improve your situational awareness within the
organization within the business and technology.
First of all, how do you actually improve your
situational awareness and why it is important for organization to
do so That's great question, actually, one of the things that
we started to realize with myself and some of the
Architects if I was to sit and write a PowerPoint or a
document, it won't. I think we should do.
I would go off by myself right that and present that because
I've maybe spent a week right now to put that together if they
give some feedback. It feels like they've been
critical of my work. So that becomes slightly awkward
sometimes especially if it's a PowerPoint.
Some of these in doing a presentation with a map, several
Textmate sit down or several experts.
Start the mop out in a collaborative manner what do we
think those things are? And as you're performing the
action of mopping, you start to build situational awareness,
people say oh we need X. I know we don't we need X and Y,
why do we need that? So it becomes a more, tune fro
conversation, you create the environment where you can
challenge and build each other's knowledge.
It comes less confrontational. So this is the idea of building
situational awareness. So what you're really doing is
having a structured conversation.
So in the find out what's happening across the
organization and what do we need to do?
So it's a great way of building trust within a team or a group
of people and get in that situation awareness because you
can't have people sitting like right and documents all day
right in PowerPoints. All right, in loads of code
because what you're not doing is exchanging information.
So that idea of mapping is great with a bill situation,
awareness, because you're having more collaborative conversation.
It's about the party we need to solve this problem, so it is not
just about notation, or new techniques modeling techniques.
Where you come up with a different kind of ways of
representing what you want to do.
But it's actually also the collaboration part, exchanging
information, or what you also called Maps different maps at
the end. I think the deliverables will be
a strategy for the organization to execute, so it could be for a
short period of time. Or it could be also for a long
time period of time. Is the outcome is almost like
what should we do next. So will the map away the map
represents our story. You're not creating a model,
it's a thinking tool. It's a bit like the saying about
plans planning is useful. The plans are useless.
So the idea of the action of planning is very important, but
once you got plans on the effect, you got to think on your
feet. Yep.
I've heard about that phrase as well.
I forget exactly the quote, but the I heard about that so you
will fail if you don't plan, right?
But once you plan, you can toss the Lan because in the real
battle field, so to speak, the plan doesn't always work.
So you are always need to adapt. You mention about the four
phases of the value flywheel. So before we start to the faces
actually, what Peaks my interest is the sequence of the faces and
you kind of like pack along a Persona to those spaces.
So the phase one is actually for the CEO.
The phase one is actually Clarity of purpose, the phase to
the challenge and the landscape Are For Engineers.
So you take the engineers Persona there and then for the
third phase is about Out, next best action.
You take product leaders here and then the last one, which is
about the long-term value. You Tech CTO, I find the
sequences little bit odd because normally, you come from CEO and
then you come to product, maybe, then to the CDO and then two
Engineers. This is typically what happened
in so many organizations. Why you're sequencing is like Co
and then Engineers to product leaders?
Then City, oh, maybe a little bit explanation on this part.
Sure, we can walk through each of the phases and definitely
touch on the Persona. And mean, I don't think these
are necessarily sequential but there is definitely an important
order. It's already a purpose, I think
CEO needs to be crystal clear on where we are heading this
organization for me, the CEO is responsible for that vision and
Mission. That's where the buck stops and
it be sure that the camping change interaction for the boat,
one of the techniques we've used as being great.
There's two different areas that are important here.
One Eddie of a North star. I've been using the North Star
framework from amplitude for many years, and it's a great
exercise about asking teams. Okay, I understand you're doing
this work. Do you know what that Northstar
metric is? Can you connect the work to the
metric? Like the CEOs, talking about?
We're going to the Moon is the piece of work.
You're doing. Going to help us get to the moon
and the answer needs to be yes. And if so high it's like there's
maybe what two or three steps if it's like no I'm not doing that.
What I'm doing is different. That useful.
The other thing is about time, the value, a big part of the
North Star framework is leading and lagging metrics and I think
an innovation is a lagging metric, the leading metric of
something different. Maybe it's time to value fast
feedback loops, be able to deploy quickly.
You will have those conversations.
So once you've got good Clarity of purpose, you very clear in
Direction then you want to obsess over time the value which
is how can we create value quickly and test if it actually
is right? We test our assumptions.
This related is like a technical bet.
We think there's a bet that this feature will be useful or
customers. Let's get in their hands as
quick as possible, start the feedback loop.
So really, like Clarity of purpose is understanding.
What are we doing and why? It's very difficult.
As, you know when a software team, the team don't really
understand why we're doing the work.
The work will not be good. So yeah, it's always great to
start with Clarity of purpose, right?
So for example Simon sinek always say start with the why I
think. All understand, you need to
start with a vision with the mission.
The problem statement to solve for the customer at the end, we
solve for our users. Our customers is not for
something else. When you mention about this, not
start framework from amplitude. So for some people who may not
be familiar, what is not star framework here, maybe you can
explain a little bit how it works here.
Mean it's worth looking opportunist, Googling Northstar
framework. John Cutler was the product.
Lines has with amplitude for many years.
I think he's moved on over. There he is.
Is a lot of great talks with the North Star framework.
It's kind of like a V shape. You start off with the work,
which is York in the leading metric.
And then the project of the piece of work, you're doing,
might have good measure of success, not measure of success,
will have an input into maybe an objective and then that
objective will link into your North Star metric Spotify.
They had a nice example about number of minutes listened to by
customers, so how many minutes of Music customers listening to
so that was an All-Star metric. And then after the North Star
metric, there's like a long-term volumetric, which maybe, three
years right, which can be something like a three to
five-year evasion. So you always want to be Tangy
work through that, you know. So you can look at your project
say, well for Spotify, will this piece of work, help increase
listening time on the Spotify platform.
So if you have a project around fixing up, the debug statements
and a what your glasses and maybe it will, or maybe it
won't, it's a nice questions. We will lie in it frame.
The work you're doing. And there's also a nice thing
here, but mapping is the North Star going to differentiate in
the market are used creating a better moisture trap.
We create something that's going to genuinely be different.
So the whole idea of from a business and product
perspective. Are we building something that's
going to meet a market. Need the, a few other techniques
as well. Which I have heard in the
industry. The other one is okay, are, or
you can just list down a few metrics.
So maybe the differentiator here, maybe it's just like the
way it is being mapped if I understand correctly.
There's a scene. Through the book that this is a
collaborative exercise. So it's not like someone shows
you the picture and say here it is, this is the answer, the team
will work through and actually figure out how their work maps
to the North Star. You may have like it's but like
impact mapping. You may have like ten eighty
years. It's like, let's go after this
one because we think this one will be best.
So again, for me, there's something deep rooted in, can I
tell software development? It's not like you just been
handed a piece of work. They go do that.
Now, you're figuring out. Out what type of work you can do
to meet a goal. So you know make sure you really
focus on the problem. Not so much.
Been handed a solution. Yeah.
Focus on the problem. Not handing in the solution.
So the CEO or the leaders, their job is to actually pick the
problem what they want to solve, right?
But then the how how people will solve it is not something that
is defined by the founders or the leaders in the company.
So I really like that. Once you have this Clarity of
the bus, which is your notes app, that's a assume we use the
North Star framework. So once we have the nonstop, The
Next Step that you mention is actually to obsess over time to
Value. I think this is very very
important as well. If you can touch on Mike how can
actually people start to think about time to Value obsess about
time to Value the singer Award of the metrics that matter in
the ID of the dashboard celebrating some kind of Matrix.
A lot of the work done by the Dora, the devops research
assessment around four key metrics could deployment
frequency. And lead time I think there are
other metrics, but really think it's important to understand
what do we mean by value? Can we clarify that can be very
clear and what is the metric that we're going to measure
value by? Is it minutes listen to music?
Or what is that? And then, how are we meeting
that need? And really, if you have a modern
cloud, or if you're in the cloud, you should be deploying
very frequently. It shouldn't be every six
months. You should be able to get
feature some of the Hands Across America quite quickly.
So I think there's something about being very clear what the
metrics that matter I've been quite transparent about those
metrics. Can celebrate nose, creating the
right culture that were trendy actually through these metrics.
And that contains a proof of mindset and they're not kind of
Hidden Away in some secret report somewhere or in a Kinect
comparing teams. It was each other.
So I think there is definitely a healthy obsession over those
metrics that matter. I really like the way you'll
mention it, the metrics that matter because sometimes in any
organization you have so many metrics, do they all really
matter in one Unison? So, It's also one thing are they
contributing to the same node star and the other thing that
you touched on earlier, is that most of the metrics, like, for
example, Innovation, or time to Market and things like that.
Those are actually lagging indicators.
So I think in this face, what you also suggest is that we have
to improve the leading metrics that we can control, for
example, spotify's case minutes of songs.
Listen, sometimes we cannot really drive people to just play
the music, right? But what are the leading
indicators that we can drive within our control to improve
that Big metrics. So I really like this two-step.
So maybe if we can go to the next phase about Challenge and
Landscape the Persona Tech to this space is engineers.
And you mentioned about two things which I find really
fascinating these days. These are the psychological
safety and the socio. Technical aspect of the
organization that started psychological safety.
Why do you think this is very important in your value flywheel
effect? I think massive piece around
been team first, like the team is the you What of delivery
teams deliver software, not individuals, teams lover
software. So it's really important like a
soccer. Team will win the game and
individual player May contribute, but the team wins
the game, no point having a great Striker if you don't have
a defense. So for me, it's always been the
same and software for teams to survive and thrive, you need to
create that psychological safety.
When you walk through, Northstar exercise, people are empowered
to say, I don't understand that metric.
Is that really the right, Patrick it Can't be correct
because the CEO said so there needs to be some rational.
People may just not understand thinking behind the metric which
is okay. You need to be in a safe
environment. You can say can you please
explain to me what that means and it should also be able to
say well I disagree, what's that?
And you can maybe have a conversation.
There's very smart people and software teams so create the
right environment to allow those people to ask questions.
So for me having that team first environments the way a team gels
trusting the team to go after? After a problem and not have
that can a command and control type environment whether just
told what to do. And they're told not to think,
that's also part of how we largely map as well when we're
figuring out. What we need to do, the people
are allowed to respectfully challenge.
The thinking, is that really the right thing?
We need to do. So that whole idea of
psychological safety in how you work is about having that
creative kind of environment, or we can figure out the best thing
to do and okay, the disagree respectfully or board a piece of
work. That's think that's massive.
Again, keep going back to this, especially in the modern Cloud
environment because there's so much technology.
There's so much Choice. Someone may have a much better
way of doing something that someone else just made out of
thought about it. You have to create that
environment that Engineers are already challenged.
Each other. Find the best way of doing
something. So, again, for me, that's a team
first environment, every time I really like that.
So team first is always the unit of delivery, right?
So again, you touch on, it's not about individual and it's not
only about the leaders who set the direction, set the goals and
also even the house Ow, but it's always the team the team comes
first and whenever the team has this psychological safety
almost, kind of like translate to people's engagement and
productivity. They can produce the best
quality product or deliverables, simply because they are
motivated. They understand they can
challenge. They are also okay to say, I
don't know, and also less about blame, right?
So if some mistakes happen, people are safe to say.
Okay, I did make a mistake and we Rectify together as a team.
I really love that one question. Maybe from your journey.
Maybe Liberty Mutual, how do you actually gauge a teams
psychological safety? There's a number of ways.
I mean, I don't think it just depends on a single person.
It's an organizational measure. And I mean, one thing that I
like is, I always would look at the Retro and I tell techniques.
Is there an ID of improvement for me just personally that was
one of the major that I would use.
I would like to see, do I see continuous Improvement and a
team, not forced contains Improvement.
Do I see the team genuinely trying to make things better?
We try and sings failing right and the gel.
So there's a number of things that I had put in place to try
and kidnap Roper. Things we still talk about
hearing demos, the do like kind of engineering Excellence, look
at metrics for teams discuss what they'd like to improve.
And then almost like there's a say, do Gap.
The team say the really unhappy with their deployment Pipeline
and, you know, create the environment or capacity that
they can fix. It could be fix it.
Or did you say no, we didn't have time when you go to the
team. Say what would you like to fix?
Let him say, Well, this here is really annoying us and then you
create the environment where they have space to fix it, they
should actually fix it. If they have this long list of
things that are kind of annoying them and they never get to fix
them. That's a bit of a smell that
maybe there's something else out there.
Team deliver the work, it's not the managers the leadership,
they create the environment to help the work happen.
So I think there's a number of things like that.
It is also something about how the leadership behave or in
those teams as well. That's it for another very
important dynamic. For sure, I mean, there are many
topics this day talking about psychological safety, but I
really like the way you kind of like take as an example.
How to gauge by looking at the how many kind of improvements
the team has done, especially out of their initiatives.
It's not like being told from the top that they need to
improve something because this means that the team also do a
lot of retrospection repeating themselves.
They are okay to say yeah we still do bad in this area and
always continuously improve. They are always Improvement.
I would also be probably concerned if they say the team
doesn't have any backlog. Of improvements that they want
to do, right? Because that also means maybe
they don't dare to speak up about what things are lacking
and they might be possessed made of a lot of delivery ahead of
them, which is also OK and the improvements can drop a bit but
that's all part of the balance flow and the team.
The second aspect is actually, you mentioned, the system is the
asset and you bring up the point about socio-technical systems
view. So, tell us what this system
about, and what is the social technical aspect of this view is
there's an interesting phrase rowing socio-technical, which is
a very old Phrase, I think it's still evolving.
You can't think of the system as just a software system because
there's also what are the teams are connected to those
components, massive link here with domain driven design, and
like, what is the organizational structure?
Or even think of Conway's law where your organizational
structure is related to your software architecture.
There's a piece here about what is that entire system?
Look like teams and software and that is the asset.
That's the thing. You have to design.
You see some companies moving People in teams or own can a
willy-nilly and to fix code, that never really works out too
well. So there's definitely a piece
here around thinking, holistically around the team's,
the organization and the software which combines two, it
solves our business problem, it's a massive node here to him,
topologies the work from Matthew skeleton, and manual part, which
is also a book released on I.T Revolution.
They talked with four different team types streamlined complex
platform and neighborhood teams. So there's a big piece here,
right? Ensuring teams are set up for
success of the right goals and are working on the right parts
of the system. So I think that's certainly a
combination between can of Engineering Management, kind of
architectural, technical management to ensure that there
is a more holistic system at work here, which I think is very
interesting. And once you create that
environment, where teams of a clear goal then you're setting
them for Success, not giving them like ten goals that they're
just completely overwhelmed. So thanks for explaining that
because I think you also mentioned in the book that we
need to Build our enable empowered Engineers within the
team's being able to analyze, not just from the technology
point of view of people point of view, but the interactions
between the technology and the people.
And hence this term socio-technical rights, not just
about the people is not just about the technology, but the
interaction between people and Technology.
That's why you bring up things, like Conway's law, Team
topologies, all these go into this research area, how do we
actually, optimize the social technical aspects of any
organization? So thanks for watching.
Wind up. So let's move to the next phase
which is Phase 3. You will mention as the next
best action. So once we know the clarity of
purpose, once we know the challenge and the landscape that
we have for the empowered teams or Engineers that we have, the
third phase is to choose the next best action.
So tell us about this because it seems very interesting, right?
The next best action, there's two parts to this to high-level
Parts piece around developer enablement, creating the right
environment for the engineers to move at read and that is linked
directly to that service first strategy.
It doesn't have to be service versus Morgan modern application
strategy. But I used the term Service
First Liberty, which is very successful.
And really, the idea is that what service first means?
First of all, any kind of service technology is something
that's more likely to be a managed Solution by the cloud
provider. It's likely to be pay as you go.
So you pay for what you consume and then wanders zero traffic.
Zero charge. So things will scale up at
there's loads of demand and skill right back to zero and
you're done, you know, it's not infrastructure code or you can
people talk about function as a service, it's not really this
concept where everything is a Lambda or everything is a
function, you're really using services to solve the need.
If you need a database, can you get a database behind an API?
If you need an event thing system, can you get an event in
system behind an API? Really, the concept of service
first? Is that the first selection when
you're selecting architectural? Components will be a serverless
service. So when a room that could be
like Lambda event Bridge, step functions, even S3 where you're
minimizing, the amount of infrastructure that you
Day-Lewis from a software perspective Service First.
Meaning, if, for some reason those Services, the work, you
may then fall back to something like kubernetes or container
solution. When we started this thinking
back six or seven years ago, there was something like cold
starts, Etc. There was some features that
weren't quite there yet. It was Reasons to fall back
today. And the 2023, there is a lot
less reasons to fall back. A lot of Service Solutions are
very robust across all the major public Cloud providers.
So once you engineers get into that, thinking that they don't
have to spend time, right? And thousands of lines of care
reform to create all this complex kind of easy to use.
They can focus on the problem that trying to solve for their
business. So, evidenced by his very nature
is event driven, so you start working more on event driven.
Items. But is a nice link back to the
stuff. We talked about teams.
And what the purpose of the team is now you get into teams emit
events to each other using service technology and start to
move and think in a different way.
This can be sometimes challenging if you've spent the
last 10 years working on traditional Enterprise Java.
This is quite the leap to Mac, but if you've been immersed in
clothes, we would maybe even starting your Cloud Journey.
This is the way. These are The Primitives of the
clothes, in my opinion. I think there's a massive shift
toward here. And there's lots of really good
examples out there of body build a service architecture.
Very quickly began that idea of developer enablement is a big
part of this because you need to create the right enabling
constraints for the engineers one being infrastructure as code
as being maybe a single path to production or on your
deployments third movie being a good coin strategy or some good.
Can a cloud infrastructure setup?
You think about how security may be slightly different than
traditional security? There's lots of really exciting
thinking in this space but it's for me I can see this major can
find dacian of how companies modernizing the cloud.
Thanks for explaining that. So if I can understand you are
not just saying everyone should adopt several as Technologies.
Things like Lambda and things like that, but it's more about
doing the simplest thing you can do to deliver value.
So as Engineers, we should not thinking about doing terraform
creating infrastructure managing networks and things like that.
But it's more about doing the simplest.
Thing that we can do. I mean these days in Cloud
Technologies there so many available Technologies, you can
just choose not just maybe as function as a service only, but
they are containers to service these day.
They are platform that enables you to do that last time people
used to do maybe hero, cool or things like that.
So I think that's also another some kind of like a serverless
first Paradigm, right? The key Point here is to do the
simplest thing, you can do to actually deliver value and you
also mention a very interesting thing, you set the code is a
liability. So as Engineers, our job, Not to
write the code, but our job is actually to deliver value for
the business. So, I think this is also very
interesting because when people hire software engineer, they
don't just see how they deliver the value.
But actually the technical competency, how they write code,
how many programs they can create.
So, I think this is also another important aspects in my view,
just very quickly to something about engineers, understand what
they're being asked to do. And sometimes when you have a
problem, what you need to do is I need to notify another
software components. Something's And this problem you
have to solve is a communication problem between A and B.
So many years will say that, okay, I need to stand up like
Africa venting system and we start building the huge
platforms like, well, that may be the answer but the problem
you have to solve is how they get an event from A to B know
what's the simplest way. I can make that happen if it's
even asked us residents to start with that and then as things
started to get complex, then you can think about.
OK, how do I scale that do? Move to that.
Hey scale, infrastructure solution, first.
And also, it depends on the context of the organization,
right? Some organization may have
capability in Kafka. Maybe they have a platform team
so you can just tap on that expertise, but some
organizations. May not.
So, don't just introduce new technology, simply because it's
the fancy. And the latest hype out there,
do it in the simplest way to bring the value first.
So I think that's the next best action.
So, let's move on to the next one, which is about long-term
value. So, this one you mentioned about
problem, prevention, Culture, maybe a little bit of
explanation, how we can actually do this problem.
Prevention culture. Also things that used to sort
worry me slightly. Is that there's this idea that
we don't need Architects anymore.
And architecture is becoming less important.
Architecture is very important. You know, if you're sitting in
the house you should hope that it's been well architected.
It was always problematic for me that, how do we communicate this
to all of the organization sometimes like this feature has
to scale, so we need to spend several weeks figuring out how
to scale this. So it's working, but it's not
ready. You want to reward team?
For doing the work up front to make sure that scales you can't
reward individuals who want a system, doesn't scale and folds
over on a Saturday, jump in and fix it.
So let's try and reward the people who prevent the problem,
rather than the people who fix the problem, is that the sign of
good engineering. People can predict, where these
things are. And for me, we spent a lot of
time trying to communicate this, a big fan of the well,
architecture framework that awas use.
Well, architected is a phrase that a Less Google and deserve
all use, and they'll hold their own versions of well
architected. So, whatever Cloud platform
you're in, I would go and look at the, well, architected
framework for that provider, but the experience I have is an AWS
where the well architected pillar framework has the six
pillars. So it's security cost,
optimization reliability, operational excellence
performance and sustainability which is new is added to just
over two years ago and really each of those pillars.
As use their own 12 or 13 questions, it's a lot of best
practice. What I did in the past was,
instead of having that as a service, where an a SS architect
comes in and assesses, your workload teams could assess
their own workload and turn them into a continuous Improvement
practice. So, the team could say, well
let's span Friday morning during the operational excellence,
pillar, I'll name a spot that their own books are out of date.
So let's add story to your backlog or and contains a proven
to dinner on books. It's because it doesn't seem
that important now. But when the system Falls over
on Saturday night, it's going to be really important.
If certain books are correct and that's for me is a good problem,
prevention culture, because the team may go through a checklist
and release, it doesn't apply, and that's okay.
But the team have the context and expertise.
You understand, what will be problematic, and they're getting
advice from the collective wisdom of all the cloud, vendor
Architects here, all the things that we have seen gone.
Wrong distilled into good practice.
Yes, you would be a fool, not the read that good practice, see
if it applies to your work look. So that's the idea of a problem
for ancient culture and I think if in an organization, there's a
modern Cloud capability should be empowering your team's to do
that work and really hard in the system, because the cloud fails
all the time, distributed systems feel all the time.
So, we need to ensure our teams of the capacity to prevent these
problems from happening. So, yeah, I've seen this a well
architected Frameworks from different Cloud providers.
They are really good. I would also highly suggest
people reading those Frameworks because they touch on many
things, but just one aspect. So, from AWS you mentioned,
there are six pillars. Now, one question for me is that
those things seem to be specific to Cloud, right?
So does the organization also need to create their own version
of well architected framework. Maybe spend not just from cloud
perspective but also maybe application development or some
other aspects within the organization.
That's a good question. Remember when people talk with
non functional requirement and abilities?
No one could remember what all the LEDs are because there's so
many scalability. Observability reliability, what
I think is nice about. Well architected is you're
saying, we're going to look at these six things I have done
well, architected reviews on on-premise systems.
Because you can still ask a question about a run book about
the cost of the system about security about authorization
authentication, you know, roll. Rules all the same questions.
Apply the answer may be slightly different because sometimes an
80s will say you should look at control tire.
For example, you need to think of what's behind that.
So you can still use the same approach for regular workloads
that will have to be closed workloads, but again, for me,
it's the way of standardizing on those non-functional
requirements that apply the every team with.
One thing I used to do list is the theme should say of were
different. We have high amount of
transactions. Were different because we have
low transactions but the high value so every team is
completely different. So being able to say, okay let's
assess reliability across all our teams.
The answer is different for your application but you can still
say you have any critical risks and liability reliability or do
you only have lower risks? So really a good architecture is
about managing risk. So you need to educate your
teams on water, the pillars and help them assess their own level
of risk. They understand their own, Text.
That's a very good point. So when we talk about long-term
value is not just about the fanciness of framework we use,
but it's actually to prevent problems from cropping up in the
future, especially when scale, or when the load comes suddenly,
your system should be able to kind of like withstand that
pressure and definitely, well, architected framework.
The name itself is like well, architect that, right?
That means there are so many experience or design patterns or
best practices that people have come up with.
So you don't always need to reinvent the wheel and come up
with your own version. So what Aspect, which I think
really important you mentioned in this long-term value as far
as well as sustainability. I know, it's trendy topics as
well, these days, but how can all the organizations are all
teams think about sustainability aspect because some people might
think. Yeah, I'm just a small company
or small team. I don't have a big impact on
this so maybe you can have an explanation on this part here.
So I think this is a great measure of good architecture.
I think sustainability is hugely important and there's lots of
different aspects but specifically For software if you
have a software system, one of the things that we used in the
past to measure how efficient a software was cost, you could
look at the actual Cloud Bill and lower cost is more
efficient, but then sometimes the cloud providers will give
like cost savings plans and different discounts.
So maybe hide some of the lack of utilization.
Know what? A lot of the cloud providers are
doing is giving you a carbon score for how much carbon that
workload is using. So it will be an actual measure
know, it's Hard to be very specific on this measure.
It's calculated by the cloud provider.
You could pretty much say that a lower carbon score or carbon
Barn is a more efficient architecture.
And even though there's a lower carbon usage is likely going to
be a lower cost and select Lee going to be simpler or less
complex system probably design their architect slightly better
than once for a wistful and burning a lot of extra Cycles.
It doesn't need. So it's a nice kind of measure.
You think is a goal or do we write sustained?
All software. So it's really about being
efficient and writing well, design software because you
think about it, if you think of a Lambda function you know it's
API call it's been up. It runs four, maybe 500
milliseconds and disappeared versus any c 2, which is running
24/7 with APA. Open one.
Call services that in 500 milliseconds, but it keeps
running and waiting, you know, the amount of compute used
between Lambda and easy to its way different.
So really? It's that idea of, can we Our to
think of our carbon usage measured by the cloud provider.
As a nice measure for good. Architecture has aged or let's
say, they take care of sustainability of the clothes,
they'll make sure the data center is sustainable.
You have to make sure that your workload is sustainable.
Is efficient. I think that's a really nice
kind of measure how we can. Build good systems.
You're dodging a very good point.
I would say that a good architecture is efficient and
probably also gives a very low carbon footprint.
Now, these days are so many technologies that that can just
easily spin up spin down. You don't always have to have a
VM running all the time or maybe except your database I guess.
Right. People don't want to have
database being spin-up and spin-down out but apart from
that I think for many back end so you can touch on a more
carbon friendly Technologies. Things like containers also has
paradigms have less Technologies and I think everyone has the
responsibility. I would say to play our part in
sustainability because the world is also changing because of this
climate change and things related to sustainability.
We all have our Possibility to save the world, so to speak.
So David? It's been a very exciting
conversation. Unfortunately, we have to wrap
up pretty soon, but I have one last question that I would like
to ask you, which I call the three technical leadership
wisdom. So you can think of it like,
advice for listeners out there and maybe from your experience,
or from your journey of from your book.
So what will be your tree Tech leadership wisdom or questions?
First of all, I think is probably around your writing
ability concise writing, think writing the same as coding
whatever line Would you use? You should be a master of that
language, they write in a concise manner as Engineers, we
often learn mathematics and programming and we don't really
learn how to write, but it's very important to be able to
communicate to a lot of people to write well and writing is
also a thinking tool so it helps gather your thoughts.
It's a lifetime practice, you can always get better out.
So I think it's good to focus on concise writing.
The second one's probably emotional intelligence which I
think is interesting one. I think is your attack leader
working with a lot of There's thinking to deal respond that
they now make and different conversations where people are
coming from, can't just assume that you're correct all the time
and everyone else is wrong. You need to consider if
different roles different experience.
So it's really important that at least, understand, emotional
intelligence, and understand different signs, Etc.
And just be a good human being and then the third is probably
only won't, it's okay. Not to know the answer.
People often assume that the technical lead knows all the
answers but often they just know how they asked a question.
Or they're brave enough to say, I don't know the answer.
You create a good environment. So you'll probably find that all
three of those. If not really much through the
technology, is there more to do with communicating with people
think being a technical lead is more about how you can work with
other people in your team's. You still need to know the
technical knowledge. You still need to build the
code. That's also really important but
you need to have those really strong communication techniques.
So, I would say writing emotional intelligence and it's
okay not to know the answer. And really liked the last one
because many people think by being a leaders, you need to
have all the answers. You need to be able on the spot,
give some suggestions or fix the problems, but many things in
software technology, these days are really hard and they are
always new, right? So I don't think anyone could
ever muster everything, so it's okay to be vulnerable and say, I
don't know. I'll try to figure out next
time, so yeah, it's a very good and beautiful message for
leaders out there, especially the engineering leaders.
So David, if people want to connect with you they want to
find out more about your books or Things.
Is there place where they can find you online?
Yeah, we've got the service age which is Surplus eight.com.
Such for will have a lot of our blogs when we have a podcast
called surface crack which is cracked.
That spelled CRA. I see, you can have an Irish
word for can good foam so myself.
Mike, we a very short podcast. We just have over the phone.
Let me talk with these Concepts and obviously the value flywheel
effect is available for all good.
Booksellers from 80 Revolution, so it's on Amazon on Kindle.
Inaudible and give her back. Thanks.
I'll make sure to put all of them in the show notes.
So thank you so much for your time.
David. I really enjoyed our
conversation. Thank you, Henry.
It's been a pleasure. 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 are 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 technology
Arnold death website, including the full transcript enter, In
quotes and links to the resources mention from the
conversation. And lastly, make sure to
subscribe to the shows mailing list on pack leader dot f to get
notified for any future episodes.
Stay tuned for the next technology, another episode.
And until then goodbye,