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. 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.