New Course: Run Better Retros in Jira

Learn with Easy Agile

Easy Agile Podcast Ep.20 The importance of the Team Retrospective

Listen on
Subscribe to our newsletter
  • website.easyagile.com/blog/rss.xml

"It was great chatting to Caitlin about the importance of the Team Retrospective in creating a high performing cross-functional team" - Chloe Hall

In this episode, I was joined by Caitlin Mackie - Content Marketing Coordinator at Easy Agile.

In this episode, we spoke about;

  • Looking at the team retrospective as a tool for risk mitigation rather than just another agile ceremony
  • The importance of doing the retrospective on a regular cycle
  • Why you should celebrate the wins?
  • Taking the action items from your team retrospective to your team sprint planning
  • Timeboxing the retrospective
  • Creating a psychologically safe environment for your team retrospective

I hope you enjoy today's episode as much as I did recording it.

Transcript

Chloe Hall:

Hi, everyone. Welcome to the Easy Agile Podcast. I'm Chloe, Marketing Coordinator at Easy Agile, and I'll be your host for today's episode. Before we begin, we'd like to acknowledge the traditional custodians of the land from which I am recording today, the Wodi Wodi people of the Dharawal Speaking nation and pay our respects to elders past, present, and emerging. We extend that same respect to all Aboriginal and to Strait Islander peoples who are tuning in today. So today, we have a bit of a different episode for you. I'm going to be talking with Easy Agile's very own Content Marketing Coordinator, Caitlin Mackie. Caitlin is the Product Owner* of our Brand and Conversions Team*. Now this team is a cross-functional team who have only been together for roughly six months. And within their first few months, as a team, mind you they also had two brand new employees, they worked on a company rebrand.

Chloe Hall:

A new team, a huge task, the possibility of the team being high performing was unlikely at this point in time. So, the team was too new to have already formed that trust, strong relationships, and psychological safety, but somehow they came together and managed to work together, creating a flow of continuous improvement and ship this rebrand. So, I've brought for you today Caitlin onto the podcast to discuss the team's secret for success. Welcome to the podcast, Caitlin.

Caitlin Mackie:

Thanks, Chloe. It's a bit different sitting on this side. I'm used to being in your shoes. I feel [inaudible 00:01:45]. I feel uncomfortable. [inaudible 00:01:46].

Chloe Hall:

Yeah. It's my first time hosting as well, so very strange. Isn't it? How are you feeling today?

Caitlin Mackie:

Yeah. Good. I'm excited. I'm excited to chat about our experience coming together as a cross-functional Agile team, and hopefully share some of the things that worked for us with our listeners.

Chloe Hall:

Yes, I know myself, and I'm sure our audience is very excited to hear what your team's secret to success was. Did you want to start off by telling us what was this big secret that really helped you work together as a team?

Caitlin Mackie:

That's a great question, Chloe. And that's a big question. I'm not sure if there's one key thing, I suppose, it is that ultimate secret source or that one thing that led to the success. I'm sure we all want to hear what that is. I would also love to know if there's just this one key ingredient, but I think something for us, and probably one of the most memorable things that really worked for us, and there was a lot for us to benefit from doing this, was actually doing our retrospectives. So that's probably the first thing that comes to mind when it comes to what led to our success.

Chloe Hall:

Okay. Yeah. In the beginning, why did you start doing the retrospectives?

Caitlin Mackie:

So, we were a new forming team, like you mentioned before, and we seen retrospectives as another Agile ceremony, and we saw other teams doing it and they were having a lot of success from it, so we became to jump on that bandwagon. And I think with being a new forming team, there are so many things that come into play. So, you're trying to figure each other out, how we all like to work and communicate with each other, all of that. And we were the first ever team dedicated to owning and improving our website. And we also knew it was likely that we'd be responsible for designing and launching a rebrand.

Caitlin Mackie:

So when you try and stitch all of that together, and then consider all those elements, we knew that we needed to reserve some time to be able to quickly iterate and call out what works and what doesn't. And what we did understand is that retrospectives are a great opportunity for the whole team to get together and uncover any problematic issues and have an open discussion aimed at really identifying room for improvement, or calling out what's working well, so we can continue to do that. So, I think retros allowed us to understand where we can have the most impact and how to be a really effective cross-functional Agile team.

Chloe Hall:

Wow. That is already so insightful. Yeah, it sounds like the retrospectives really helped you to gain that momentum into finding who your team is, becoming a well-working, high-performing cross-functional team. So, how often were you doing the retro? Were you doing this on a regular cycle, or was it just, "Okay. We have a problem. Some blockers have come up, we need to do a retro"?

Caitlin Mackie:

Yeah. I think initially retro, we kind of viewed retros as this thing where like, "Oh, we've done a few sprints now. We should probably do a retro and just reflect on how those few sprints went." It was kind of like this thing. It was always back of our mind. And we knew we needed to do it, but weren't really sure about the cadence and the way to go about it. So now, we do retros on a Friday morning, which is the last day of our weekly sprint. And then we jump into sprint planning after that. So after bio break as well, so let the team digest everything we talked about in retrospectives. And then we come into sprint planning with all the topics that we're discussed, and we will have a really nice, fresh perspective.

Chloe Hall:

Yeah.

Caitlin Mackie:

So, I think this works really well for us because everything is happening in a timely manner. We've just had a discussion about the best things that happened in the sprint or what worked really well, so you want to make sure you can practice the same behavior in the following, and vice versa for the improvements that you want to make. So, that list of action items that come out of a retrospective provide a really nice contact, context, sorry. And you have them all in mind during sprint planning.

Caitlin Mackie:

So for example, in the previous sprint, it might have come up that you underestimated your story points or there wasn't enough detail on your user stories. So, with each story or task that you are bringing into the sprint, you're then asking the question, is everyone happy with the level of detail? What are we missing? Or we've only story pointed this or two, is it more likely to be a five? So, everything is really fresh in your mind, and I definitely think that helps create momentum. When you've got the whole team working to figure out how you can be more effective with every sprint.

Chloe Hall:

That's such a great point that you just made Caitlin. And I love how going from doing the team retrospective, that you actually can take those action items and go into your sprint and put them into place straight away. It's really good. Otherwise, I feel like if you do the sprint retrospective on the Friday, and you're like, "Okay, these are our action items," get to Monday sprint planning and you're just thinking of the weekend. That [inaudible 00:07:20]

Caitlin Mackie:

Yeah, a hundred percent. Yeah. They're super fresher mind for everyone. So, it might not work for every team, but we find it works really well for us, because we're being really deliberate with how we approach sprint planning.

Chloe Hall:

Yeah. And then with that, I could see how doing the retro, how it could easily go over time, but then your team has sprint planning scheduled after. So, it's like you can't go over time. How have you managed to kind of time box that retrospective?

Caitlin Mackie:

Yeah, that's a really, really good question. And it is on purpose as well that they are scheduled closely together. Som as mentioned above, the discussion you've had in the retrospectives provides a nice momentum going to the sprint planning, but it does mean we have to watch the clock. And initially, this can be quite awkward, because you want to make sure that everyone feels heard and that everybody has the same opportunity to contribute. And I think this responsibility falls on the scrum master, or the product owner, or whoever's facilitating the retrospective to call it out and make sure everyone has the chance to be heard. You'll naturally have people tell the longer story or add a lot of extra context before getting to the point. And then you'll have others that will be a lot more direct. And I'm a lot like the latter. I struggle to get to the point, which doesn't work well when you're trying to time box a retrospective, right?

Chloe Hall:

And I can relate, same personality.

Caitlin Mackie:

Yes. So with this, I think it really comes down to communicating the expectation and the priority from the get go. With our team and with any team, you will want to figure out who you can perform really well and continually improve to exceed expectations and be better and learn and grow together. And I think if you all share that same mindset going into the retrospective and acknowledging that it's a safe


space to have difficult conversations. And as long as you're communicating with empathy, the team knows that it's never anything personal, and it's all in the best interest of the team. And that then helps the less direct communicators, like myself, address their point more concisely and really forces them to be more deliberate and succinct with their communication style.

Caitlin Mackie:

And that's really key to being able to stick to that time box, I think. And it does take practice, because it comes down to creating that psychological safety in your team. But once that's there, it's so much easier to call out when someone's going down a windy track, and bring the focus back and sort of say, "I hear you, what's the action item?" And just become a lot more deliberate.

Chloe Hall:

Wow. I couldn't even imagine like how hard it would be, with the personalities that yourself and I have, just trying to be so direct and get rid of all the fluffy stuff. I mean, look at what it's done to form such an amazing team that we have. So, you mentioned that aspect of psychological safety before. And how do you think being in a new cross-functional team... Only six months together, you had those new employees, do you think you were able to create a psychological safety space at any point?

Caitlin Mackie:

That's another fantastic question. And I feel like, honestly, it would be best to have a team discussion around this. It'd be interesting to hear everybody's perspectives around what contributes to that element of psychological safety and if everybody feels the same. So, I can't speak for the team, but my personal opinion on this or personal experience is that creating an environment of psychological safety really comes down to a mutual trust and respect. And at the end of the day, we all share the same goal. So, we all really, really respect what each other brings to the table and understand how all of these moving parts that we are working on individually all come together to achieve the goal. So, when we're having these open discussions in retros, or not even in retros, just communicating in general really, it's clear that we're asking questions in the best interest of the team and individual motives never come into play, or people aren't just offering their opinion when it's unwarranted or providing feedback, or being overly critical when they weren't asked to do so.

Caitlin Mackie:

So, none of those toxic behaviors happen, because we all respect that whatever piece of work is in question or the topic of discussion, the person owning that work, at the end of the day, is the expert. And we trust them, and we don't doubt each other for a second. And I think the other half of that is that we're also really lucky that if something doesn't go as we planned, we're all there to pick each other up and go again. So, this ties quite nicely into actually one of our values at Easy Agile is commit as a team. And this is all about acknowledging that we grow and succeed when we do it together, and to look after one another and engage with authenticity and courage. Som I may be biased, but I wholeheartedly believe that our team completely embraces that. And there's just such an admiration for what we all bring to the table, and I think that's really key to creating the psychological safety.

Chloe Hall:

I love that your team is really embracing our value, commit as a team and putting it into place, because that's what we're all about at Easy Agile, and it's just so great to see it as well. I think the other thing that


I wanted to address was... So again, during this cross functional team, and you've got design and dev, how do you think retros assisted you in allowing to work out what design and dev needed from each other?

Caitlin Mackie:

For sure. So, for some extra context for our listeners as well, so in our team, we've got two developers, Haley and David, and a designer, Matt and myself, who's in the marketing. So, we're very much a cross-functional little mini team. So, we all have the same goal and that same focus, but we also are all working on these little individual components that we then stitch together. So,, I think... We doing retros regularly. What we were able to identify was a really effective design and development cycle. So, we figured out a rhythm for what one another needed at certain points. For example, something we discovered really early was making sure that we didn't bring design and dev work into the same sprint. We needed to have a completely finished design file before dev starts working on it. And that might sound really obvious, but initially we thought, "Oh, well, if you have a half finished design file, dev can start working on that. And by the time that's done, the rest of the design file will be done."

Caitlin Mackie:

But what we failed to acknowledge is that by doing that, we weren't leaving enough capacity to iterate or address any issues or incorporate feedback on the first part of that design file, or if dev started working on it and design then gets told, "Oh, this part right here, it's not possible," so the designer is back working on the first part. And it just creates a lot of these roadblocks. So in retros, this came up and we were able to raise it and understand that what design needed from dev and what dev needed from design in order to make sure we weren't blockers for each other. And the action item out of the retro is that we all agreed that a design file had to be completely finished before dev picks up the work.

Chloe Hall:

I think it's so great that you were able to identify these blockers early on. Do you think like doing the retro on a weekly reoccurring basis was able to bring up those blockers quickly, or do you think it wouldn't have made a difference?

Caitlin Mackie:

No, definitely. I, a hundred percent, think that retros allowed us to address the blockers in a way more timely and effective manner. And we kind of touched on that before, but yeah, retros let you address the blockers, unpack them, understand why they're happening and what we need to do to make sure they don't happen again. So, for sure.

Chloe Hall:

Yeah. Yeah. I guess I want to talk a little bit now about the wins, the very exciting part of the retro, the part that we all love. So, how important do you think the wins are within the retro?

Caitlin Mackie:

So important. So, so, so important. It's like, when you achieve something epic as a team, you have to call it out. Celebrate all the wins, big, small. Some weeks will be better than others, but embrace that glass half full mentality. And there's always something to be proud of and celebrate, so call it out amongst


each other, share it with the whole company, publicly recognize it. Yeah, I think it's so important to embrace the wins. It just sort of creates a really positive atmosphere when you're in the team, makes everybody feel heard and recognized for their really positive contribution that they're making. And I think a big thing here as well is that if you've achieved something epic as a team, it's helpful for other teams to hear that as well, right? You figured out a cool new way to do something, share it. If it helped you as a team, it's most likely going to help another team.

Caitlin Mackie:

So I think celebrating the wins isn't even just reserved for work stuff either, right? If somebody's doing something amazing outside of work or hit a personal goal, get behind it.

Chloe Hall:

Yeah.

Caitlin Mackie:

To celebrate all the wins always.

Chloe Hall:

Yeah. And I think it's so good how you mentioned that it's vital to celebrate the wins of someone's personal life as well, because at the end of the day, we're all human beings. Yes,, we come to work, but we do have that personal element. And knowing what someone's like outside of work as well is an element to creating that psychological safe space and team bonding, which is so vital to having a good team at the end of the day. Yeah.

Caitlin Mackie:

Yeah, a hundred percent. Yeah, you hit the nail in the head with that. We talked about psychological safety before, and I definitely think incorporating that, acknowledging that, yeah, we are ourselves at work, but we also have a whole other life outside of that too, so just being mindful of that and just cheering each other on all the time. That's what we got to do, be each other's biggest cheerleaders.

Chloe Hall:

Yeah, exactly. That's the real key to success. Isn't it?

Caitlin Mackie:

Yeah, that's it. That's the key.

Chloe Hall:

So, you've been working really well as a new cross functional, high performing Agile team. How do you think... What is your future process for retros?

Caitlin Mackie:

We will for sure continue to do them weekly. It's part of the Agile manifesto, but we want to focus on responding to change, and I think retros really allow us to do that. It's beneficial and really valuable for


the team. And when you can set the team up for success, you're going to see that positive impact that has across the organization as a whole. So yeah, we've found a nice cadence and a rhythm that works for us. So, if it ain't broke, don't fix it.

Chloe Hall:

Yeah.

Caitlin Mackie:

Is that what they say? Is that the saying?

Chloe Hall:

I don't know. I think so, but let's just go with it. [inaudible 00:19:02], don't fix it.

Caitlin Mackie:

There we go. Yeah.

Chloe Hall:

You can quote Caitlin Mackie on that one.

Caitlin Mackie:

Quote me on that.

Chloe Hall:

Okay, Caitlin. Well, there's just one final thing that I want to address today. I thought end of the podcast, let's just have a little bit of fun, and we're going to do a little snippet of Caitlin's hot tip. So, for the audience listening, I want you to think of something that they can take away from this episode, an action item that they can start doing within their teams today. Take it away.

Caitlin Mackie:

Okay. Okay. All right. I would say always have the retrospective. Don't skip it. Even if there's minimal items to discuss, new things will always come up. And you have to regularly provide ways for the team to share their thoughts. And I'll leave you with, always promote positive dialogue and show value and appreciation for team ideas and each other. That's my-

Chloe Hall:

I love that.

Caitlin Mackie:

That's my hot tip.

Chloe Hall:


Thanks, Caitlin. Thanks for sharing. I really like how you said always promote positive dialogue. I think that is so great. Yeah. Well, thanks, Caitlin. Thanks for jumping on the podcast today and-

Caitlin Mackie:

Thanks, Chloe.

Chloe Hall:

Yeah. Sharing your team's experience with retrospectives and new cross functional team. It's been really nice hearing from you, and there's so much that our audience can take away from what you've shared with us today. And I hope that we've truly inspired everybody listening to get out there and implement the team retrospective on a regular basis. So, yeah, thank you.

Caitlin Mackie:

Thank you so much, Chloe. Thanks for having me. It was fun, fun to be on this side. And I hope everyone enjoys this episode.

Chloe Hall:

Thanks, Caitlin.

Caitlin Mackie:

Thanks. Bye.

Related Episodes

  • Podcast

    Easy Agile Podcast Ep.35 Jeff Gothelf on Customer-Centric OKRs, Goal-Setting, and Leadership That Scales

    TL;DR

    Jeff Gothelf, renowned author of "Lean UX" and "Who Does What By How Much," discusses the evolution from output-based work to outcome-focused goal setting with OKRs. Key insights: Teams need to shift from "we're building a thing" to defining success as "who does what by how much" – meaningful changes in human behaviour that drive business results; the biggest barrier to agile ways of working is that people get paid to ship features, not deliver value; leaders should change their questions from "what are you building?" to "what are you learning?"; psychological safety is critical – teams need to feel safe admitting when something isn't working; start small by simply asking "what will people be doing differently when we ship this?"; rename teams around outcomes (mobile revenue team) rather than outputs (iPhone app team); proactive transparency through weekly three-bullet-point updates builds trust with leadership. Bottom line: OKRs, when done right, are the "Trojan horse" that enables all other agile practices to succeed.

    Introduction

    For years, agile practitioners have championed better ways of working – Lean UX, design thinking, continuous discovery, customer centricity. Yet despite widespread adoption of these practices, many teams still struggle with the same fundamental problem: they're rewarded for shipping features, not delivering value.

    In this episode, our CEO Mat Lawrence sits down with Jeff Gothelf to explore how this misalignment of incentives undermines even the best agile practices, and why customer-centric OKRs might be the missing piece that makes everything else click into place.

    Jeff Gothelf is a renowned author, speaker, and consultant whose work has shaped how product teams approach collaboration and customer-centricity. Along with co-author Josh Seiden, Jeff wrote "Lean UX," which revolutionised how designers work in agile environments. Their follow-up book, "Sense and Respond," helped leaders understand how to manage in software-based businesses. Their latest book, "Who Does What By How Much," tackles the thorniest problem yet: how to align incentives and goals with customer outcomes.

    This conversation traces Jeff's journey from helping designers work better in agile teams, to helping leaders create the conditions for success, to finally addressing the root cause – the goals and incentives that determine what gets celebrated, rewarded, and promoted in organisations. It's a masterclass in shifting from output thinking to outcome thinking, with practical advice for both team members and leaders navigating this transformation.

    About Our Guest

    Jeff Gothelf is an author, speaker, and organisational consultant who has spent over 15 years helping companies build better products through collaboration, learning, and customer-centricity. His work focuses on the intersection of agile software development, user experience design, and modern management practices.

    Jeff is best known as the co-author (with Josh Seiden) of three influential books that have shaped modern product development practices. "Lean UX" (now in its third edition) began as a guide for designers working in agile environments but has evolved into a comprehensive framework for cross-functional collaboration and risk mitigation in product development. The book's core principle – moving from deliverables to outcomes – has influenced how thousands of teams approach their work.

    Following "Lean UX," Jeff and Josh wrote "Sense and Respond," a book aimed at leaders and aspiring leaders. It makes the case that the overwhelming majority of businesses today are software businesses, and that managing software-based businesses requires fundamentally different approaches to team structure, management, and leadership. The book provides a roadmap for creating organisations where teams can actually practise the collaborative, customer-centric approaches described in "Lean UX."

    Jeff's latest book, "Who Does What By How Much," represents the natural evolution of this work. After years of helping teams work better and leaders manage differently, Jeff and Josh identified that the real barrier to change was incentives and goals. Teams kept saying, "That's great, Jeff, but I get paid to ship features." This book tackles that problem head-on, showing how to use objectives and key results (OKRs) to create customer-centric goals that align with – rather than undermine – modern ways of working.

    Beyond his books, Jeff has also authored "Forever Employable" and "Lean vs Agile vs Design Thinking," and he regularly speaks at conferences and consults with organisations on product strategy, team effectiveness, and organisational transformation. His approach is characteristically practical and rooted in real-world experience, making complex concepts accessible through clear frameworks and relatable examples.

    Jeff's work continues to evolve as he helps organisations navigate the challenges of building products that customers actually want and need, whilst creating work environments where teams can thrive.

    Transcript

    Transcript

    Note: This transcript has been lightly edited for clarity and readability.

    Why Write Another Book? The Journey from Lean UX to OKRs

    Mat Lawrence: Well, Jeff, welcome. I'm Mat Lawrence for our audience. I'm COO at Easy Agile, and today I'm talking with Jeff Gothelf, who is the renowned author, speaker, and consultant. You've written a good few books, Jeff. I've been looking through the list – Lean versus Agile versus Design Thinking, Forever Employable, and co-authored a few. The latest one being "Who Does What By How Much," and I was just telling Jeff in the intro here how you've managed to get across a lot of the things that I care about when trying to build teams and get them to understand OKRs. I've already given it to a few people and I'm definitely going to be giving it around. So, Jeff, welcome.

    Jeff Gothelf: Thank you so much, Mat. That's very kind of you on all of that stuff. I appreciate it. Thanks for having me.

    Mat: I'd love to cover a little bit around the book and the concept you're trying to get across. So I suppose the first question I have is what problem are you hoping to solve with the book? Why did you write it?

    Jeff: It's really interesting. I wrote a blog post about this a while back because somebody challenged me on LinkedIn – and I appreciate a good challenge. They said, "How can you write about all this stuff? There's no way you know enough about each one of these topics to write a book. You're spreading yourself way too thin."

    I thought that was a really interesting challenge. No one had ever asked that question, and it got me thinking. The answer that I came up with is that this book, "Who Does What By How Much," and it's a conversation about customer-centric objectives and key results, is the natural evolution of the work that Josh Seiden and I have been doing together for more than 15 years.

    "We started with Lean UX, and Lean UX was a solution for designers helping them work more effectively in agile software development environments. The response to that book was, 'That's great, Jeff and Josh. We'd love to work this way. My company won't let me work this way.'"

    So we wrote "Sense and Respond," which was a book for leaders and aspiring leaders to inspire them to manage differently, to recognise that the overwhelming majority of businesses today are software businesses, and that managing software-based businesses is different.

    As we began to work with that material and talk about that, we kept bumping up against the same ceiling, and that ceiling was incentives and goals. No matter how hard we tried to convince people to be customer-centric, to learn continuously, to improve continuously, to work in short cycles, they said, "That's great, Jeff. But I get paid to ship features."

    The goal, the measure of success, was shipped – preferably on time and on budget. That's what got celebrated and rewarded, incentivised and promoted. It was in the job descriptions and all that stuff. So it felt like we were really fighting a losing battle.

    Objectives and key results has been gaining momentum for the last decade or so. To us, that felt like the perfect Trojan horse – and I know Trojan horse has a negative connotation, but I don't think of it in this case as a negative thing. It was the perfect way to have a conversation about goals in a customer-centric fashion that, if applied in the way that we describe in the book, would enable everything else that we've done to happen more easily.

    "What Will People Be Doing Differently?" – The Question That Changes Everything

    Mat: I love the evolution of it, Jeff. I've been working in tech now for about 15 years. Prior to that, I used to work in the arts and special effects, which in itself is a very agile industry where you're constantly building prototypes and figuring out what things need to do before they go on stage or be filmed.

    When I entered into the tech world as an inexperienced founder and product developer, I was designing to solve problems, and I found the teams I was working with responded really well to that. "What are we trying to do? What are we trying to get here?" They used to give me feedback all the time on whether I was helping them see far enough ahead with the value we're actually trying to deliver.

    When I joined Atlassian in 2014, when we were introducing OKRs there, I think we were facing a problem that you described really well in the book, which is around people focusing on shipping their to-do list. They have a backlog that is predefined, full of great ideas, and they really want to get it out the door. Trying to change that conversation to be around "how do we know if this is any good?" – the answer was we just don't know.

    I'd love to touch on how have you guided teams to move from that more traditional output-based metrics and shipping into that outcome approach? Maybe you could give an example of where that shift has led to some significant success.

    Jeff: Sure. The title of the book is "Who Does What By How Much?" Overwhelmingly, the teams that we've worked on and with over the years have focused on delivering output, making stuff. The question that we tried to get them to understand is: if you do a great job – let's say when – when you do a great job with this feature, how will you know? What will people be doing differently?

    That's the question that starts the mindset shift from outputs to outcomes. Outcomes, the way that we describe them, is a meaningful change in human behaviour that drives business results. The human that we're talking about is the human that consumes the thing that you create.

    "The question is how will you know you delivered value to that human? Traditionally, it's been like, 'Well, we made the thing for them. There it is.' We made the Sharpie. Terrific. Did anybody need a Sharpie? Anybody looking for a Sharpie? How do we know? What are people doing now that the Sharpie is out there?"

    The mindset shift starts with that question. Even in an organisation that just doesn't get this yet, it's a really safe question. I think it's a safe question to say, "Okay, we're gonna build the thing. What do we expect people to be doing differently once we ship this thing?" And when I say people, let's get specific about who. Which people? Who?

    This is the evolution of the book title and how we teach this stuff. So what would people be doing differently before we start? Which people? Who? Okay, it's accountants in large accounting firms. Great. When we ship this new system to them, what are they gonna be doing differently than they're doing today? Well, they'll be entering their data more successfully and finishing their work in half the time.

    Terrific. What are they doing? Who does what? And how much of that do we need to see to tell us that this was actually valuable? Well, today they're seeing at least a 30% error rate in data entry. Okay, great. What's meaningful? What's a meaningful improvement? If we cut that in half, that's a meaningful improvement. By how much?

    All of a sudden, we've constructed the success criteria that has moved the team away from "we're building a thing" to "accountants in large accounting firms reduce their data entry errors by 50%." Who does what by how much. That begins the mindset shift in that conversation in a safe way because we're not saying let's set new goals, let's rewrite our incentives. We're just saying, "Look, I'm just asking a question."

    Then once we start to build stuff, and especially once we start to ship stuff, you remember that conversation we had three months ago? We talked about who does what by how much. Is it happening? Do we know? Can we find out? And if it isn't, let's figure it out.

    The Non-Profit That Changed Their Approach - From One Million Buses to Ten Iterations

    Jeff: I'll give you an example. There was an organisation I worked with – I really loved working with them. They were a non-profit organisation that was looking to address major diseases in the developing world. They had three or four very specific diseases that they were targeting in very specific locations around the world, and I was thrilled to be working with them and helping them.

    They managed everything with a task list. They were like, "We're gonna create this campaign and we're gonna put it on buses in China." And I was like, "Okay. How do you know that? So what? If the campaign works, what will people be doing differently?"

    "Well, they'll scan the QR code that's on the bus."

    "Okay, alright. And then what?"

    "They'll sign up for an appointment to get a cardiovascular check."

    "And then what?"

    "For those who need actual care, they'll sign up for care."

    "All of a sudden, we've taken 'put an ad campaign on a bus' to 'who does what by how much.' When we started to think about it that way, they fundamentally were rethinking the level of effort."

    Because you might imagine, it was going to be one million buses and hope that it works. Instead, they decided, "Hey, we're gonna do 100 of these in one locality, and we're gonna give it a week, and we're gonna not only see what happens, but find out if people saw the ad, if it speaks to them, if they understood what it said. Then based on that learning, we're gonna iterate on the campaign."

    So instead of getting one giant shot at this advertising campaign to drive people to take better care of themselves, now they're gonna get ten iterations. I think that was massively impactful in helping that organisation do better work and help more people.

    Mat: I love how you're bringing that back to the experimental and iterative approach that people so often want but really struggle to get to. I've seen so many occasions where OKRs end up describing something that takes three, four, five months to build and ship, and they're only trying to measure the big outcome at the end, whereas what you're talking about there is breaking it down, making it far more iterative and experimental.

    Jeff: Reducing your risk. Imagine this organisation had, let's say, £100,000 for this campaign. Traditionally, they would spend that whole hundred grand and hope. The reality is there's no need to do that. They could spend 10 and learn and do a better job with the next 10 and a better job with the next 10, and if they've de-risked it enough, take the last 50 and dump it on the thing that you've actually validated.

    It's a de-risking strategy as well. You're increasing the value you're delivering and reducing the risk of spending money on stuff that isn't gonna work. Feels like a no-brainer, doesn't it?

    The Reverse Five Whys - Asking "So What?" to Find Your Outcome

    Mat: You make it sound like everyone should be doing it, which I agree with. There was something that you did in the middle of that conversation which I really like, and it's kind of like the opposite of the five whys. You know, where you see the problem and you ask why, why, why and you go back to the root cause. Whereas you took that in the other direction there.

    Jeff: Right. We were moving forward in time for the desired outcome.

    Mat: Yeah, exactly. You said, "Okay, you want to put this thing on a bus. So what?" And you took that three or four steps forward to get to that ultimate outcome. I love that, and that's probably a tactical, practical approach that our audience can take.

    I think some of the stuff that I've struggled with over the years is getting teams who are new to OKRs to understand how to move from writing their to-do list, writing their backlog, turning that into their key results, and actually getting it into the outcome base. I think that's one of the things that a lot of teams find hardest to grasp.

    Jeff: And as I kicked off with, if your entire career you've been rewarded for shipping and producing and ticking off a to-do list, then it's really hard to break away from that without some form of leadership buy-in. That's coming back to that incentives and performance management criteria side of things. That's really hard because that's what people optimise for.

    We can preach outcome-based work until we're blue in the face, as they say in America at least. But if you're paid to ship product, you're gonna optimise in most cases for what gets you paid. That's an important component of this that I think gets ignored a lot.

    Two Audiences, Two Approaches - What Should Teams and Leaders Do Differently?

    Mat: Let's talk practically around this. We're probably going to have different people listening to this. We could probably give two bits of advice. One is somebody who's in a team and they really want to try this, or maybe they've been trying this and struggling because the incentives don't match. The other group may be someone who's in leadership who is trying to change their organisation to move into this more outcome-based approach. What advice would you give to each of those people?

    Jeff: Great question. Let's start with the folks trying to make this happen initially. In my opinion, one of the easiest ways to move this conversation forward in your organisation is to ask that question I mentioned: What will people be doing differently when we ship this?

    Have that conversation. Position it any way you'd like, word it any way you'd like. But ultimately, you're not challenging the work. You're not saying "I'm not gonna do the work." You're not pushing back yet.

    "All you're saying is, 'Look, we're gonna build this thing, and we're gonna do a great job. What do we hope people will do with this once we have it out there? What are we trying to see? Are we trying to see them increase average order value? Do we want them to abandon their shopping carts less? Are we trying to get them to sign up for a medical check-up at least once a year?'"

    That starts it. That starts getting people to think about more than just "I am making a thing."

    Mat: If you took that to leadership and said, "Yeah, we're gonna get this stuff out the door, but I want to check with you that you're happy that this is the outcome we're trying to get to, that this is the result if we get it right."

    Jeff: I think that's great, and I think that you should come back to them after you ship and say, "Look, remember we met three, six, nine months ago and I said we're building this and we're hoping people will do this? Well, we built it as designed, on time, on budget, and so far we're not seeing the results that we anticipated. We talked to some customers, and here's why we think that is. What we'd like to do next..."

    To me, that should be a safe conversation inside your organisation.

    Mat: I can imagine people listening to this and getting some cold sweats at the concept of going to someone and saying, "I did everything that you expected from me, but it wasn't good enough."

    Jeff: It's not that. What tends to happen in these situations is a lot of upfront planning and commitments, and then we execute. Regardless of all the work that people have done to convince people that there are better ways of working, that's generally speaking how people are doing work still. We did the thing, and guess what? It didn't work. It didn't work as we had hoped. It's not because we built it poorly. It works as designed. We did usability testing on it. People can use it, they can get through the workflow.

    What we think is it's not solving a meaningful problem, or we decided to put it somewhere in the workflow that didn't make sense, or whatever the case is. I understand it's not a risk-free conversation. I'm not encouraging people to do things that are career-limiting per se, but at some point we've got to talk about this kind of stuff. Otherwise, we're just a factory. I don't think anybody wants to work in a factory.

    It's Not About the Quality of Your Code, It's About Learning

    Mat: I couldn't agree more, and I think that the heart of what I spend a lot of my time doing is helping people understand how to get the benefits out of being agile, that agility piece. What we've been discussing there is that key part of learning. You can plan and you can build, you can have alignment on those things, you can improve how you're building all the time and reach quality standards and pass usability testing. But ultimately, if you don't learn, you're never gonna get the insight that you need to adapt what you do next.

    "Where a lot of people fall down with agility is they go through all of the motions up to that point, and then through fear, self-preservation, or they've just not seen anybody else around them do it before, they hesitate to say, 'This thing that we've all invested all this time and effort into isn't working as expected.' It does take some courage to do that."

    Jeff: It does. I agree. But it's an evidence-based conversation. It's not "we did a crap job." We didn't. It's bug-free, it's high performance, it's scalable, it's usable. But you can build products like that – there are infinite stories of products that were amazingly executed that didn't meet a need, didn't solve a problem.

    Mat: Yeah, I built one of those and had to close a business for it, so I know that all too well. If there's a lesson I learned through the years of doing that, which you touched on earlier, it's around by focusing on the outcomes that you want to see, those behaviours you want to change, and bringing the work down, de-scoping the work to start to experiment and iterate, you de-risk all of that. You'll learn a lot earlier whether you're on the right track or not rather than getting that big bang at the end.

    Jeff: Yeah. Again, you're reducing the risk of building something that people don't want. Let's just use round numbers because they're easy. If you have a million-pound budget to build something – a new product, a new feature, a new service – and you spend 100 of that million and find out that this isn't the right thing to make, it's not a real problem, for whatever reason, you've just saved the company £900,000.

    They should hoist you up on their shoulders and sing your praises, parade you around the halls. That's how it should be. You're a hero, and now we can take that £900 and do something that actually will deliver value with it.

    If You're a Leader: Stop Asking "When Will It Be Ready?" and Start Asking "What Are You Learning?"

    Mat: The second half of that question was around if you're a senior leader in an organisation and you want to move to an outcome-based approach, maybe you start with celebrating the people who are trying to do that and positively reinforcing it in that way. But what advice would you give that person?

    Jeff: Absolutely. Celebrate anybody – literally hoist them up on your shoulders and parade them around the halls and say, "Look, this team tried this, figured out it wasn't going to work, and pivoted, and saved the company a million pounds." That should be a regular conversation and a regular thing that the company celebrates.

    What's interesting is that you can find yourself on a team with resistant leadership, and you can also find yourself in leadership with resistant teams. And for a variety of reasons, not the least of which is that they've never actually been allowed to work this way and don't believe you that you're gonna let them work this way.

    "Without getting caught up in too much process or training or dogma, I think as a leader you start to soften the conversations around this stuff by changing the questions that you ask."

    Normally, it's like, "Hey, what are you guys working on? When will it be ready? How much is it gonna cost me? What do you predict the ROI is gonna be?" That's a typical line of questioning for a product team.

    Conversely, you can say, "Hey, folks. What are you learning this week? This sprint? This quarter? What did you learn?" You might get a bunch of blank stares initially. They'll say, "What do you mean, what did we learn? We're building what you told us to build."

    "Okay, well, cool. Next quarter when we meet, I'd love for you folks – I'm gonna ask you this question again. What did you learn this quarter about the product, about the customer, about the value of the thing that we're delivering? If you don't know how to answer those questions, I can help. I can get training for you. I can get some folks who've done this in other parts of the company to show you how they're doing this work."

    To me, you're not enforcing. One of the issues of organisations just mashing process on top of organisations is folks don't understand why. Why are we doing this, and how is this supposed to make anything better? One of the ways to ease folks into a different way of working is to change your expectations of them and make that clear to them.

    Instead of saying "What are you building? When will it be ready? What's the ROI?" say "What are you learning? Are we doing the right thing? How will we know?" And then if they don't know how to get the answers to that, don't make them feel stupid. Say, "Look, I'm gonna help you with that. I'll show you how the other teams are doing it. I'll get you some training. We'll work on this."

    That's super powerful because you're changing the expectations that you have for your team, and you're making it explicit to them.

    Navigating Conflicting Forces - Outcomes vs. Predictability

    Mat: I've got this image in my head of people in a large organisation where they're on this journey that you've described with their team. Maybe they're a leader somewhere in the middle of the organisation, working with multiple teams, and they're starting to see some progress. The teams are on board, they trust that the questions you're asking are genuine and authentic, and they really want to understand the outcomes.

    They're starting to come back with great questions themselves around who does what, what's the behaviour we're trying to change, how are we trying to change it, are we successfully doing that or not. Whilst that starts to get some traction and momentum, at the same time this leader's got other people in the organisation – maybe some more traditional executives who are getting investors on their boards asking for their KPIs to be met and the efficiency and the predictability they expect so they can forecast.

    They have jobs to do themselves, and they seek some predictability. How do you help guide that person to navigate those two conflicting forces?

    Jeff: It's hard. I've seen it multiple times. I think there are a couple of ways to navigate those political challenges in an organisation. One is you have to model the behaviour that you want to see both in your teams and in your colleagues as well.

    Every interaction that you have with your peers at leadership level should contain these types of conversations around the customer, around learning, around value, around risk mitigation, and continuing to model the behaviour you want to see.

    Someone says, "Well, we just have to build the iPhone app."

    "Okay, great. But why? Why do we have to build the iPhone app?"

    "Because we have to increase mobile revenue."

    "Why? What is it today? What are we hoping to get?"

    The Power of Renaming Teams

    There's a super simple trick I wrote about probably a decade ago. If you're in a leadership position to get the organisation to start to think differently about how to do work, it's simply changing the names of the teams.

    For example, let's say you and I work on the iPhone app team. What's our mission? Build an iPhone app. Exactly. So that's the iPhone app team, and that's the CRM team and that's the Android app team, whatever.

    "What if we change the name of that team? Same team, same people. But it's the mobile revenue team. All of a sudden, the purpose of the team has fundamentally changed. It's no longer 'build iPhone app.' It's 'increase revenue through the mobile channel.'"

    That might be an iPhone app, might be an Android app, might be a better website, might be a million different things. But from a leadership perspective, one of the things that you can influence is the name of these teams, and how you name them determines what work they do. That's really powerful.

    Prove the Model

    The other thing that you can do as a leader is prove the model. There's a lot of "my idea is better than your idea" type of conversations at work. Instead of saying, "I think we should work this way," say, "Look, I've got a pilot team in my group that's been doing this for the last three months. Here's what the team looks like. Here's the work that they're doing. Here's how they work. Here's what they're producing. Here's their happiness score. Here's their productivity. Here's their efficiency. Here's the impact of the work that they're doing with the customer."

    If you've got one or two of those teams working that way, that's a compelling argument for saying, "Look, let's give it a shot." You've got the evidence that says this is a better way of working. Proving the model is always a good way to go.

    Team Autonomy and Empowerment

    Mat: One of the things that I'm picking up on in what you're saying leads to an outcome within teams that I've seen – around autonomy and empowerment within teams. Something I'm always trying to do in my role in organisations is make myself redundant. If the team don't need me anymore, I've done my job.

    I'm at work where I've been very clear with the rest of the leadership team: I'm getting involved in way too many decisions, and I need to remove myself from those decisions because I'm slowing us down. If I have to have all of the context to be able to get involved with that and help move us forward, then we're gonna go slower than we should.

    We're very quickly removing me from decisions, and it's been a great journey. Terrifying for me because I don't know as much about what's going on. But I'm seeing the teams themselves equipped with questions like "who does what by how much?" – that's one tool around the OKRs. Also equipped with other tools and ways of working, and usually it comes down to: are they asking the right questions? Are they applying the level of critical thinking to achieve those outcomes?

    "Ultimately, if we can get teams to be more autonomous, leaders have a much better time of scaling themselves without burnout, without having to get really drawn in. When teams make decisions when you're not in the room that are fighting to achieve the outcome that you also want to achieve, that's when you really start to move quicker. That's when you start to really see the benefits of agility."

    Have you got any thoughts on that that you'd like to share?

    Jeff: It's a really tough sell. I see it all the time because I think that leaders have defined themselves – I don't want to speak in absolutes, so the majority of leaders have defined themselves in a way that says, "I tell people what to do." That's my job.

    If you ask any kid – 10 years old, 12 years old, 9 years old – "What's a boss?" they'll say "A boss is someone who tells people what to do." I think we grow up with that, and I think leadership canon for the last hundred years has roughly said that, with the exception of the last 20 to 30 years where we've seen a lot of agile-themed, agility-themed leadership books and materials come out.

    Still, I think the overwhelming majority of people believe that it's their job when they're in a leadership role to tell their teams what to do and to be keenly aware of every little detail. Because what if my boss comes to me and says, "Hey, what are your teams doing?" If the answer is "I don't know," that's probably a bad answer.

    I agree with you. Day-to-day decision stuff – who better to make that decision than the teams doing the work day to day? They know far more about it than I do. They're with the work every day, they're with the customer every day, they're getting the feedback.

    There's no reason for you to run these tiny things past the leader every day. It's exhausting for the leader, as you said, and the team knows more about it. Big strategic shifts, invalidated hypotheses, radical shifts in the market, new competitive threats – absolutely, let's talk about that.

    The Two-Way Solution

    I think there's a two-way solution here. Number one, leaders need to let go a little bit and understand that the most qualified people to make decisions about the day-to-day trivial stuff are the team doing the work.

    David Marquet said this in "Turn the Ship Around." He ran the worst-performing nuclear submarine crew in the American Navy and turned it around to the best-performing crew. Basically, what he said was he pushed decision-making down as close to the work as possible. The only decision he kept for himself was whether or not to launch a nuclear missile, because people are gonna die and he didn't want that on anybody. That's his job as the leader.

    Same thing here. You're gonna push decisions all the way down, and we've got to get folks to think about that.

    Demand Proactive Transparency

    To make that easier for people to swallow, people who are not used to this way of working, I think we have to demand greater proactive transparency from the teams.

    Teams love to play the victim. "They don't let me work this way. My boss won't let me work this way. My boss doesn't get agility, doesn't get customer-centricity. She just comes down here and yells at us."

    "What if on a weekly basis, without being asked for it, you sent your leader three bullet points in an email every week? Here's what we did this week. Here's what we learned. Here's what we're planning on doing next week."

    If there's anything significant, you're gonna put that in there as well. But otherwise, just those three things. You're not even asking for a response. Weekly update, three bullet points, 15 minutes max of effort on your part.

    In my opinion and in my experience, what happens is leaders chill out. Because all of a sudden they know what's going on. They see that you're doing work, that you're making objective decisions, and that you're taking the time to keep them informed. When their boss comes to them and says, "Hey, what are your teams doing?" they can just look at that email and be like, "This is what Mat's team is doing, this is what Jeff's team is doing."

    To me, if there's a role here – and it's not an insignificant one – for the teams to play to improve their ways of working or to improve the comfort level that leaders have with new ways of working, this is it.

    Mat: I have had the privilege of being someone on the recipient of those equivalent three-bullet-point emails running 12 different product teams, trying to understand what was going on. You're right – the stress levels go down when you understand proactively what's going on. It became the first thing I would do on a Monday morning knowing I had all that information.

    It was something that teams were doing as part of their own weekly reviews as a team, and they just captured it and shared it. So there's no extra work for them. But it made this huge difference of suddenly I could understand where did I need to actually spend my time to help, rather than trying to chase and get information or get too close into managing people who didn't need it because they had it in hand.

    I was able to prioritise and think, "Oh, that team looks like they're struggling, so we're gonna go and ask them some questions, see how I can remove some blockers for them."

    Jeff: And if there is a blocker, add it in there. "We've been trying for three months to get access to customers. The sales team keeps blocking us. Can really use your help here."

    The Shift from Being Rewarded for Knowing to Being Rewarded for Learning

    Mat: There's a thing I've observed over the years – it takes a while to get there before you actually start getting rewarded for it in most organisations. In forward-thinking, very agile organisations, it starts a lot earlier, and I think that's something I'd like to try and shift left, try and get it earlier in people's careers.

    It's this shift between: spend your entire career being rewarded for being knowledgeable, for being the expert, and knowing how to do something. You get promoted for that, you'll get a bonus for that, you'll get rewarded for it time after time. The more you learn, the more capable you become, the more experienced you are, you've got the answers for everything, you get promoted. You work your way up the career ladder.

    Then you hit this tipping point where you hit a level where you realise there aren't many people around you at that point who are seeing the problems. Everyone's busy, everyone's focused on their thing. Then you realise that actually it's your job to call out that this thing isn't working. It becomes your responsibility to say, "There's a problem here we need to address as a company, as an organisation."

    As an exec – Nick Muldoon is our CEO – we have an exec weekly, and the majority of that conversation is each of us saying what we don't understand, what we don't know, what we haven't figured out yet. We trust each other that all the rest of it's in hand and working beautifully. The things we really want to talk about is what don't we understand and what are we learning or what are we seeing that we need to try and figure out what to do with.

    I see people struggle with that transition if they've not started it earlier in their career. Going back to the basics around sharing the learnings and are we actually achieving what we wanted to, are we seeing the behaviour shift, are we seeing it measured – if we're saying no, having the freedom to be able to call that out earlier, I think it makes that transition in life a lot more straightforward.

    Jeff: Look, there's a level of seniority, and the subtheme here that we are dancing around but haven't yet named is psychological safety. It's this feeling that I'm comfortable calling things out that are against the grain, that contradict the plan, that are not working, and I keep seeing and nobody's addressing.

    "I think there's a level of seniority that brings some psychological safety. But ultimately, organisational culture has to make it safe."

    In other words, if leaders like you and your leadership team are consistently curious – "What do we not know? What are we not aware of? What's not working?" – your teams are going to feel comfortable calling those things out to you because you're asking those questions.

    When they change the questions that they ask, it models psychological safety. It models the kinds of questions they want their teams to ask, and that's how change starts.

    Building Psychological Safety - "If You Don't Know How, I'll Help You"

    Mat: I couldn't agree more, Jeff. I think we've covered a lot of ground today, and psychological safety is one of those really hard intangible things for some people, particularly if they've never experienced it. We see it when we get new people joining our team. We're in a privileged environment where we have a lot of psychological safety.

    When new people join from organisations that haven't had that, their behaviour is almost fighting against it. They hold on to their protected ways of working where they get a little bit territorial and they don't want to be vulnerable. It can take a good few months for people to settle in and relax into it.

    There was a piece that I want to go back to, and maybe we wrap up on this. You talked earlier around a leader talking to their team and asking them questions to help them understand that it's okay to come back and say, "This thing that we've been developing, this product that we've been getting out the door, isn't having the desired impact." To look at it, question it, be curious, and come back to it.

    The thing that you touched on there which I really love was that supportive nature of it. It's okay to do this, and if you don't know how to do it, I'll help you. If you were to give one last tip to our audience – how would you encourage people, leaders specifically, to move more into that space?

    Jeff: I think it's a question of asking the right questions. I've been married a long time – half my life, it turns out. I did the maths the other day. If I've learned nothing in my 20-plus years of being married, I've learned that you don't start out immediately solving the problem. You listen and you ask questions. I've learned that. It took a long time.

    I think that's our nature as leaders as well. The tendency is "let me solve that for you." Well, hang on. Before you jump to solutions, dig into the problem. What's the issue here? What's the problem? How can I best help you?

    "Well, listen, we've set these customer-centric goals now. We've got great OKRs. Thanks for teaching us how to do that. Normally though, we're told what to do, and no one's telling us what to do now, and we don't know what to do. We have no idea how to figure that out. In the past, people have told us. Now I don't know what to do. Can you help us? How do we figure that out?"

    To me, those are the kinds of answers you want to elicit from your teams. What's actually going on here?

    This is where five whys comes in. "Well, you know, we keep hearing that we should be talking to customers. The reality is it's really difficult to get to our customers."

    "Why is it difficult?"

    "Well, because we're in a B2B space and we sell aeroplane engines."

    "Okay, great. And why does that make it difficult to reach customers?"

    "Well, because we have a sales team."

    "Why does that make it difficult?"

    "Well, because they guard their contacts and they don't want us messing with it."

    "Okay, now I understand."

    "I think if it's about asking the right questions as a leader, and then when you get to the root cause, you say, 'Well, listen, I can try to unblock it in this way. Do you think that would be helpful? Yes or no?' That becomes far more of a partnership than a hierarchical relationship."

    Then you trust me to be honest with you about how well things are working and where things need help, and that's tremendous.

    I run a very, very tiny business in the sense of number of people – it's three and a half people total. Even in a three-and-a-half-person business, people try to do good work and people don't want to bother you with what's going on. Sometimes people get overwhelmed, whether it's with work or personal stuff or a combination of the two, and then things start to slip.

    The more you can foster that kind of transparency and trust, psychological safety, the less you find out that something is broken with the consequences of it being broken. You find out well in advance of anything actually happening.

    Mat: I love that, Jeff. I think that's a great place to wrap up. I'm really grateful for your time, really enjoyed the conversation, and thank you for sharing your wisdom.

    Jeff: My pleasure, Mat. Thanks so much for having me. This was fun.

    ---

    Thank you to Jeff Gothelf for joining us on this episode of the Easy Agile Podcast. To learn more about Jeff's work and get your copy of "Who Does What By How Much," visit jeffgothelf.com. You can also find his other books, including "Lean UX" and "Sense and Respond," which provide the foundation for the customer-centric approach to OKRs discussed in this episode.

    Subscribe to the Easy Agile Podcast on your favourite platform, and join us for more conversations about agile, product development, and building better teams.

  • Podcast

    Easy Agile Podcast Ep.31 The Release Train Engineer + SAFe Summit 23

    "Lieschen's wealth of experience is absolutely incredible! Not only did she provide invaluable advice, but I thoroughly enjoyed our conversation."

    In this episode Caitlin Mackie is joined by Lieschen Gargano Sr, Release Train Engineer at Scaled Agile. They delve into the role of the Release Train Engineer, sharing tips and tricks, FLOW activities, lessons learned and how to get started in the role. With SAFe Summit 2023 just around the corner, Lieschen also takes some time to talk about what she’s most excited about for the event and shared some advice for first time attendees.

    If Lieschen's expertise and passion have piqued your interest, be sure to explore the Scaled Agile RTE course. It provides comprehensive training, equipping you with the necessary skills and knowledge to excel as an RTE.

    Scaled Agile RTE course

    We hope you enjoy the episode!

    Transcript:

    Caitlin Mackie:

    Hi there. Welcome to the Easy Agile Podcast. I'm Caitlin, your host for today's episode. At Easy Agile we specialize in developing apps for Atlassian Jira that help your team move from simply doing agile to truly being agile. Our apps have gained recognition and trust from over 160,000 users across top companies worldwide. With our products, teams can transform their flat Jira backlogs into something visually meaningful and easy to understand. Whether it's sprint planning, retrospectives, or PI planning, our apps are designed to foster seamless team alignment.

    Before we begin the episode, we would like to say an acknowledgement of country. This is part of our ongoing commitment towards reconciliation. Easy Agile would like to acknowledge the traditional custodians of the land from which we broadcast today. We pay our respects to elders past, present, and emerging, and extend that same respect to all Aboriginal Torres Strait Islander and First Nations people joining us today. Let's jump into today's episode. So today I'm joined by Lieschen Gargano, a senior release train engineer at Scaled Agile. Lieschen is a highly experienced professional when it comes to change management, system design and stakeholder engagement, and has a passion for developing teams and connecting strategy to execution. Lieschen welcome to the Easy Agile Podcast.

    Lieschen Gargano:

    Thank you. I'm happy to be here.

    Caitlin Mackie:

    So Lieschen, you are a release train engineer. For our listeners, can you explain a little bit about the role? For anyone that's not familiar, how would you describe a Release Train Engineer?

    Lieschen Gargano:

    Yeah. I think one of the easiest ways for people to think of a Release Train Engineer is kind of like a coach or scrum master for the art, for the Agile release train. A servant leader facilitating all of those art events, facilitating the processes and process improvements. And really measured in value delivery, and using flow metrics to measure those improvements and support of the arts.

    Caitlin Mackie:

    So you mentioned flow metrics there. I've heard a lot about this recently and optimizing flow. What are some of those flow activities that a RT is responsible for?

    Lieschen Gargano:

    I like to look at feature flow and cycle time. So really looking like are we bringing all of our features in progress at once or are we managing our WIP, not just at the team level but at the art level. Are we taking the whole PI to get a feature through the system, or are we able to finish something before we start the next thing? So I look at that a lot and also just are we making and meeting commitments. Those PI objectives that we set, are we in that 80-100% range? A lot of people want full credit, extra credit and to be in the 120, but for us, predictability really means you tried really hard and you stretched, but you also still made and met commitments. So I look at that really closely too.

    Caitlin Mackie:

    I love that. You mentioned just then quite a lot of different responsibilities that a RTE has. Do you think that there is one in particular that you really need to get right from the start?

    Lieschen Gargano:

    Oh, as an RTE, I think the biggest thing is building the relationships and intention. As a servant leader, we really are there to help make the art better, to make being on the art enjoyable and productive and flow. So building that trust and those relationships as a servant leader is the first thing. If you get that wrong, no one will help you do the rest.

    Caitlin Mackie:

    Yeah-

    Lieschen Gargano:

    And you need a lot of help. You're not doing anything alone as an RTE.

    Caitlin Mackie:

    Yes. Yeah, for sure. I can definitely imagine that. Let's go a little bit deeper on that servant leadership that you just mentioned. Can you share your approach and what servant leadership means to you?

    Lieschen Gargano:

    Servant leadership to me is helping people understand the direction, communicating early and often so that they know where you're going. And then not just saying, "how can I help you get there? What can I do?" But saying, "how can we go together?" A lot of coaching and understanding the problem to solve and connecting it to how it benefits the people. Just like we ask them to connect their work to how it benefits the customer. As the RT, they're my customer. How does what I'm asking you to change benefit you? Not changing is always easier than changing even if we don't like our current state. So why is it worth it?

    Caitlin Mackie:

    I love that. Yeah, always asking the why and being really clear on it. Yeah, I think that's great. I've done some LinkedIn digging of your profile, as you do, had a little bit of a stalk and noticed that you hosted a webinar recently on tips and tricks and lessons learned as an RTE. Can we start with maybe some tips and tricks? What can you share?

    Lieschen Gargano:

    The first thing I will say is lean on the Scrum master team, and if you're lucky enough to have an Agile coach or another RTE, lean on that team. Your lean Agile Center of Excellence, those people have the expertise. They're also building the relationships. They're there to help you. Don't try to just prove yourself or go it alone, it's not possible. That team is your team for success. So 100% go to them. They're a wealth of knowledge, a wealth of relationships, and the best support.

    Caitlin Mackie:

    Yeah, I know it's so important to have that support network around you. You just mentioned the Agile Center of Excellence. Maybe for some of our listeners aren't familiar, could you explain what that is?

    Lieschen Gargano:

    Yeah, so the Lean Agile Center of Excellence can look a few different ways depending on your organization. At our organization, it is the coach, release managers, RTEs and Scrum masters or team coaches. And some larger organizations than ours might have that hub and spoke model of a centralized change leader. And then RTEs and Scrum masters that are in different arts and around the org. And some even have separate laces in different parts of the organization if it's really big. But really they are that community of practice that holds your lean Agile practices and the standards of those practices and talks to each other and debates and evolves them to make sure that it's consistent throughout the org. That the org is getting consistent coaching, consistent guidance, and they're not being told five different things about how to transform. Because again, change and being lean is so hard. If you add too many voices into that coaching, it gets really overwhelming for folks.

    Caitlin Mackie:

    Yes, 100%. And an Agile transformation is already overwhelming as it is, so you can imagine that laid on top. I suppose speaking, if we explore a little bit around those on an agile transformation journey, at what point would you say it's important that that lean Agile Center of Excellence is formed?

    Lieschen Gargano:

    Oh, I think it should be in place pretty quick. I mean, we talk about training your leaders, training your experts and then doing safer teams and launching trains. You need that Center of Excellence there from the start so that they can go out to the rest of the org that they can do all that training and they can be there to support people through title changes, role changes. Launching an art can feel very scary to folks. If you don't have that in place beforehand, you're going to have a lot to reel in after the fact.

    Caitlin Mackie:

    Yeah, I really like that. It's almost having this really solid foundation and unified voice to sort of go forward and support the rest of the org.

    Lieschen Gargano:

    And it's so great to have consultants support, to have partners come in and help you and to have the right tools, but they need the help of people inside. They need that lean Agile Center of Excellence of employees inside the company to help you be successful. As an RTE, you need your team. Anybody, any tool, any people trying to do a change, a transformation are going to need that Center of Excellence because all those parts, that's what makes the whole.

    Caitlin Mackie:

    Yeah, yeah, definitely. So you mentioned as an RTE, a big tip or trick is to rely on that lean Agile Center of Excellence. What do you think has been your biggest lesson learned as an RT?

    Lieschen Gargano:

    There are a few things that have been particularly difficult for me. One of them is that I don't like to say no and not in that I take on too much or whatever, but more in that if someone has passion for something, I want them to be able to take it on. I want them to be able to move forward with it. And there are times where we really have to say it's too much change. It's too much for this group to manage. In particular, the Scrum Masters and RTEs people come to us for a lot of things and they need that consistency from us, and they need predictability in a change to feel like we know where they're going and if we introduce too many things or if we try to hold too many things at once, it's easy for us to forget about it later or drop something else. So learning when and how to say no, again not necessarily in that capacity way, but just in the width of change, if that makes sense.

    Caitlin Mackie:

    Yeah, definitely. I think that what you just said there, learning how and when to say no. I think that's not even exclusive to the RTE role as well. I think that's an amazing piece of advice for anyone listening and to share across our audiences, because I know it's definitely something I struggle with as well. So that's my takeaway from this is to, okay, I'm going to constantly imagine like 'no Lieschen told me to when and how to say no', and just focus on that. So yeah, I think that's a great piece of advice. What was your journey like to an RTE? I know we caught up last week and I got a little sneak preview into this, and I know it wasn't straightforward, so if you can share a little bit about that, that would be great.

    Lieschen Gargano:

    Yeah. I actually started in conflict resolution. I worked in public private reconciliation doing a lot of natural resources facilitation, so hundreds of people, governments, companies, private landowners, residents, trying to bring all those people together to get to consensus or at least to build relationships that allow them to move forward. So really strong foundation and facilitation in particular, and just day-to-day conflict. When we say conflict, we get so worried, 'oh, I don't do conflict', well conflict's everything all the time. It's all the disagreements we need to succeed in life. So that gave me a great foundation when I became a scrum master, and I did that for a few years working with development teams. One of my favorite teams was our infrastructure team, 10 foot pole because no one wanted to touch their work or the 10 foot pole, and I learned so much there and eventually became a coach and started doing more strategic planning and coaching parts of the organization that weren't used to being on arts. Marketing and other groups, which helped me transition to Scaled Agile, where I started working with our CMO and as he grew the marketing team, helping coach that marketing group into an agile way of working, a safe way of working, before actually becoming a product owner, because I loved organizing around value, and I loved those different topics that we were working on internally.

    And one of the people I work with at Scale Agile said, "well, help us develop the product then for everybody else". So I did that for a little while, which gave me so much power in that learning how to say no and prioritize and coaching people to decisions is one thing, but as the product owner, I had to practice being where the buck stopped. There are five right decisions, just make one so that people are unblocked, and that prepared me really well for transitioning into RT.

    Caitlin Mackie:

    Yeah. You have such a wealth of experience there across so many different roles, and you can really see that each of those key roles have taught you something valuable that you can take into this RTE role. So I think that's amazing. It's so cool to see that even though it's not this straightforward linear journey, there's all these parts that there's traits within each that ladder up to helping you succeed as an RT. So I think that's really cool.

    Lieschen Gargano:

    And I know people are afraid to make some of those lateral moves sometimes, but the skills that you can build might just be that thing that gets you other open doors that you didn't even think about.

    Caitlin Mackie:

    Yeah. Yeah. I absolutely love that. Yeah, just embrace every opportunity for what it may be, what it may not be. You don't know until you give it a shot. So I think, yeah, I love that. I think that's really great advice. So everything we've spoken about in regards to being a Release Train Engineer may have really hit the spot for some of our listeners. How does someone get there? Were there certifications, courses? What's the process that way?

    Lieschen Gargano:

    Another thing I probably did backwards. I started with a scrum master cert and then actually ended up getting a SPC certification through Scaled Agile when I was a coach. Because I was a coach before I was an RTE, and I learned about so many other parts of the business that way. But then to become an actual RTE, taking the safe RTE course, but then actually there's a community of RTEs... Which we didn't really talk about this, but being an RTE is a lonely thing. I said earlier, if you're lucky to have another RTE, this is a lonely role. You're really kind of on your own. So not just getting that cert, but being part of that community and being able to send people messages and ask them crazy questions was part of my certification process, but also just community building to where I could feel like I had the connections and competence. So yeah, I found all of them similar to holding each of the roles, also getting that certification, just another tool in the tool belt.

    Caitlin Mackie:

    Yeah, for sure. I don't want to touch on something you said there about an RTE being sometimes quite a lonely role. What do you think makes it lonely?

    Lieschen Gargano:

    It's a role that a lot of people have strong opinions about what they need and what success looks like based on where they are in the organization. And there are usually few of you, and even if you're in a large organization with many, you're with your art, you're very focused on your section, and so having all of those pulls and expectations and not having anyone who understands what that feels like just makes it kind of lonely. Now that we have two RTEs and a coach at Scaled Agile, it makes a big difference for me because they are right there in it with me and it's very helpful.

    Caitlin Mackie:

    Yeah. You can see in that scenario why that community of RTEs is like you said, so important to lean on them as well. Yeah.

    Lieschen Gargano:

    I find even just connecting to RT's outside our organization too. I grabbed beers with one a couple weeks ago. Those little things, even if you can find that person, meet them at a summit, meet them out in the wild, find them on LinkedIn and just say, "Hey, we live in the same area. We have the same role". It can go a long way because it may seem weird to reach out like that, but they probably are looking for that connection too.

    Caitlin Mackie:

    Thank you so much for sharing. And for any of our listeners, I might pop some links to any certifications and some scout Agile courses. I'll pop that in our episode notes, so feel free to check those out. You mentioned about connecting with other RTs and meeting at summits, which is a really nice segue to the next part of our conversation. Just around the corner is the 2023 Safe Summit and we're heading to Nashville Music City. What can we expect from Safe Summit? What are you looking forward to?

    Lieschen Gargano:

    Well, what I'm most looking forward to is that I am putting together an RTE breakfast. So all RTEs are welcome, or even if you're a solution train engineer or you do the role of an RTE with a different title. I'm really excited to meet with those folks over breakfast and just chat it out. And my goal with that really is to have people to connect with so that as we go through the rest of the summit, listening to the talks that we have people enroll, that we can check back in with over drinks and stuff on the later days and say, 'oh, what do you think? How might that work?' So that's what I'm most looking forward to.

    Caitlin Mackie:

    Amazing.

    Lieschen Gargano:

    But obviously there are going to be some great talks and the product labs are always really fun. We get to play with the product together.

    Caitlin Mackie:

    Yeah, cool. Tell me a little bit about the product labs, what's involved in that?

    Lieschen Gargano:

    The product team puts it together and they have computers set up and you can bring your own and they talk through some of the new releases or things they're working on and help you log into it and use it in your context, but also try to get some feedback on how it works or how you might use it in your organization. So it's a nice two-way street. It's sort of, 'I need this, how might I do it?' And then them saying, 'well, why don't you try and let me see how it works and how we should change it based on how you interact with it'. So it's just really fun. It feels really practical because it's so hands on.

    Caitlin Mackie:

    Yeah, amazing. I love that. I'm definitely going to have to try and come along and suss that out. It sounds really great. Where do you hope or where do you think we'll see a lot of conversations focused at this year's Safe Summit?

    Lieschen Gargano:

    At Safe Summit I think the conversations will be really focused on just the day-to-day of Safe. We have new topics that come up. We obviously have new ideas that are going to be presented. But every time I go to one of these, it really is the connecting one-on-one to say, here's where I'm stuck, here's what I'm trying to learn. So we'll hear a lot about Flow, we'll hear about Team Topologies, but we'll also hear those 'I'm just getting started and we're stuck, we have change fatigue. We don't know if our arts are set up correctly'. A lot of those classic conversations that are just really impactful and why people come together.

    Caitlin Mackie:

    Yeah, definitely. Yeah, I love that. Creating these spaces for people to bond over shared experiences and problems they're facing or wins they're seeing and sharing them. I think that's where these events are amazing for creating that kind of environment. Lieschen, this is my very first Safe Summit. I haven't been to one before and I'm really excited. What advice would you have for first time attendees, returning attendees, what's the way to get the most out of Safe Summit?

    Lieschen Gargano:

    If you're attending with other people from your organization, the best thing is to split up so you can cover more ground and then come back together and share. The second advice is find people with a similar role as you, because again, you can do that same thing with those folks and split up and then meet up again and try to talk about it in your context. It's great to do that at the parties too, because we throw great parties, but that's the best because no matter what room you end up in, what talk you end up at, you're going to get a great nugget. But where it really sinks in for me is talking with someone else about what I heard and then thinking about, 'okay what does that mean?', when I go home.

    Caitlin Mackie:

    Amazing, great advice Lieschen. If anyone listening happens to also be attending Safe Summit and they see Lieschen on the floor or myself, make sure you say hello, and if you've got any questions for Lieschen about the podcast episode, I'm sure she'll be more than happy to answer and engage in a great conversation. And anyone looking to get advice around the RTE role, make sure you find her and have a chat. Lieschen I'm really excited to meet in person. We've done this podcast with yourself in the States, myself in Australia, so I'm excited to connect over in your world. And yeah, really thank you so much for your time. I hope you enjoyed the episode. I know, I sure did.

    Lieschen Gargano:

    I did. Thank you.

    Caitlin Mackie:

    Thanks, Lieschen.

  • Podcast

    Easy Agile Podcast Ep.19 Combining Ikigai and OKRs to help agile teams achieve great results

    In this episode, I was joined by Leandro Barreto - Lead Software Engineer at Miro.

    Leandro is responsible for helping engineering and product teams to be more productive through metrics and KPIs with a focus on increasing their operational efficiency. Before moving to Europe, Leandro worked for an Atlassian partner company in Brazil as Head of Technical Sales.

    In this episode, we spoke about;

    • Ikigai - what is it and how do you achieve it?
    • The benefits of OKRs
    • How can we combine agile, Ikigai and OKRs?
    • How Ikigai can help agile teams achieve great results and stay motivated

    I hope you enjoy today's episode as much as I did recording it.

    Transcript

    Robert O’Farrell:

    Welcome, everyone, to the Easy Agile Podcast. We have an episode today with Leandro Barreto who is a lead software engineer at Miro. I'm your host for today, Robert O'Farrel. I'm the Growth tech lead at Easy Agile. Before we kick off this podcast, I'd like to acknowledge the traditional custodians of the land from which we broadcast today, the people of the Duruwa-speaking country. We pay our respects to Elders past, present, and emerging and extend the same respect to all Aboriginal and Torres Islander, and First Nations people joining us today on the podcast.

    Robert O’Farrell:

    Leandro currently works as a lead software engineer at Miro where his responsibility is to help engineering and product teams to be more productive through metrics and KPIs with a focus on increasing their operational efficiency. Before moving to Europe, he worked for an Atlassian partner company in Brazil and acted as a head of technical sales with the mission to increase the service offers in Latin America. Welcome, Leandro. It's great to have you here today.

    Leandro Barreto:

    Yeah. Thanks, Rob. Thanks also for the Easy Agile for the invite. It's a pleasure to be here today.

    Robert O’Farrell:

    Fantastic. You're here to talk about Ikigai, objectives and key results or OKRs in Agile, so let's kick it off. Ikigai, what is it? Can you give us a brief or a long explanation of what it is?

    Leandro Barreto:

    Yeah, of course, of course. So, Ikigai I use it to say is a philosophy of life that means like a reason for being or the meaning of life. So, the world Ikigai originates from a village in Southern Japan, where the average life expectancy of people is over 100 years old. So, Ikigai is basically divided in four components. The first, things you love. Second, something that you are good at, then something that pays you well. And finally, something that the worlds need. So, when you put it all together, then you have the Ikigai, but this is not easy. So, let me explain a little bit of each of these companies.

    Leandro Barreto:

    So, the first thing is something that you love, something that makes you be present, something that you must ask yourself what do you really enjoy in doing? What makes you happy? What holds your intention that makes you lose time and forget about time? So, for example, reading, dancing, singing, painting, learning, teaching, et cetera. So, maybe it's a little bit difficult to answer right now, but understanding and seeking what you love must is fundamental so that you can have a healthy balance between learning, putting it in practice, testing, failing, trying again, and keep the circle repeating itself.

    Leandro Barreto:

    So, an example that I can give you is, for example, I had a jujitsu teacher that no matter the day, he was always training. And one day, I remember I got my arm hurt. And in the next day, I had a message from him like 6:00 in the morning, he was asking if I was okay. And I was waking up and he was texting me like, "Hey, are you okay? Are you going to be able to train today?" And I was like, "Whoa, take it easy, man." This is very funny because our class is 6:00 p.m. And he was punctually at the tatami or dojo. I don't know the English word for that.

    Robert O’Farrell:

    Yeah, dojo. We have dojo. Yeah.

    Leandro Barreto:

    Dojo. Awesome. Yeah. And he was always punctual. And after the classes, he always said that he wants to get home earlier after the classes because he has private classes. So, from morning to night, he always keeps training and you can see the passion in his eyes when he talks about jujitsu. "It's a passion for me". A little bit exaggerated.

    Robert O’Farrell:

    Something that definitely got him up in the morning and kept him going throughout the day to the late evening, by the sounds of it.

    Leandro Barreto:

    Exactly. Yes. And then, you have the second component, which is something that you are good at. Something that you can always improve with yourself. So, for example, what you are really good at. It's quite hard to answer, but what the people say is that I'm do... something correct or what they say something positive that what I do. So, for example, I remember the book Outliers by Malcolm Gladwell that says that usually, you have to spend 10,000 hours in something practicing to be good at.

    Leandro Barreto:

    So, don't take it as an obstacle but as a motivation to keep going, and understand this part of what you are good at. It's a good way to improve. And the third part is what pays you well? So, money is what... Some people say that "Hey, money don't bring... It's not... how can I say that?

    Robert O’Farrell:

    Money doesn't bring happiness?

    Leandro Barreto:

    Yeah, exactly. But it puts a roof in your head. It makes you provide a good life for your family. It makes you travel. It makes you have a hobby. So, according to Maslow, for example, one of the bases of human beings is to start thinking about security. So, we have to have this security in order we can improve as a person. So, money helps you to achieve it. Yeah. So, find something that makes your life as comfortable as you desire to, as you wish to. So, otherwise, you'll always be looking for something that you never had. So, for example, time.

    Leandro Barreto:

    So, you will spend so much time thinking how can you have more money? And here's the glitch, you will never be paid because you will be stuck on your daily basis thinking on how to get money instead of how to improve your skills to get money. Right? And then, you have the what the world needs. So, here, the idea is to find a proposal for what do you do and what is value to the society, your proposal. And sometimes it's quite difficult to find precisely because of the plurality of positions and responsibilities that we have nowadays. And even more today with the full expansion of technology that every month we have new positions to be filled by companies that needs different type of skills, soft skills and hard skills.

    Leandro Barreto:

    And here, the keyword is to serve. So, I will give a personal example. For example, one of the things that I missed most when I was a young teenager was having someone who could help me to explore the technology so I can get a job. So, it was in the early 2000 and it was quite hard.

    Robert O’Farrell:

    Yes, very much so.

    Leandro Barreto:

    The internet is starting, everything is new.

    Robert O’Farrell:

    People on dial-up, internet was slow.

    Leandro Barreto:

    Do you remember that sound like prshh?

    Robert O’Farrell:

    Oh, yeah. It comes to me in my dreams I think. I heard it so many times in that era.

    Leandro Barreto:

    My family and my friends, they wasn't in the IT field. So, there is no one to help me that. So, I had to learn it by myself. Seems impossible. But it took me time to learn it and enter in a company with a good position let's say that gives me money and the possibility to learn much more faster. So, since 2013, I dedicate part of my time to teach young people, acting as a mentor to help them enter in this market so they can learn new skills. I can open paths for them, put in contact with the right people, people which is going to be important for them, and all aiming to accelerate their dev development and giving them the opportunity.

    Leandro Barreto:

    And this for me is very meaningful because I'm helping those who don't have any references also, and sometimes don't have a chance. And the more I serve them, the more I earn and I grow with them. So, I came across like when I was introduced to Ikigai for example, another personal example.

    Robert O’Farrell:

    Sorry. Before we get to that, just reiterating. So, the four components, so there's something that you really lose time in doing, something that you get into the flow of doing very easily. And then, the second component is the thing that you are very confident in doing, something that you do quite well. The third one, being something that pays you well, and the fourth one, being something where there's a need for it. So, just reiterating that. That's correct?

    Leandro Barreto:

    Correct. Correct.

    Robert O’Farrell:

    So, I guess getting to that, our second question that like for yourself, you can apply obviously in a business sense, but in a personal sense, what's been your journey there, and do you believe you've achieved Ikigai, I guess, would be my next question?

    Leandro Barreto:

    Yeah. Well, actually personally, I have some things that's very clear in my life. I'm still not there, but let's say that I'm in the process.

    Robert O’Farrell:

    Work in progress

    Leandro Barreto:

    Exactly. Work in progress. So, I have clear goals and I have clear in my mind where I want to go in a few years, so I don't get disencouraged if the weather is cold or warm, if the stock market goes up or down. And the only thing that I focus is to be 1% better than I was yesterday. And this provides me a security that prevents me to wasting time and things that doesn't make any sense or simply doesn't matter for me in the future. So, I take my career very, and also my personal life very serious on that point. So, yeah, let's say that work in progress.

    Robert O’Farrell:

    I love that word security that you use there. It draws a parallel, I think, to a word that we also use when it comes to that plan that we have, which is that focus element, making sure that we do the things that matter. Do you think that it's also given you a sense of focus too on what you take on and what you say yes to and what you say no to with regards to your personal and professional development?

    Leandro Barreto:

    Yeah, absolutely. Absolutely. When you know where you want to go, it's more easy to say yes or no to something that came up to you. Another personal example that I remember was something like 12 years ago, 12 to 13 years ago, my focus was to learn Java, for example, Java programming. Because I know in the midterm, I would like to be a Java architect. So, I have to improve my skills on that programming language.

    Leandro Barreto:

    So, during that time, the company that I was working was making some changes and then they asked me, "Hey, I know you are good at Java. You are learning, but we need you to start learning this another language, Ruby on Rails during that time. But you have to at least for the moment, forget Java." And then, I was like, "Mm-mm. No, no."

    Robert O’Farrell:

    It's not what I want to do.

    Leandro Barreto:

    Exactly. I totally understand that was a company's decision. But during that point, it begins to separate my focus on what I want to achieve from the company's purpose. So, it doesn't make any sense to continue on that company. I asked to leave. And again, best decision ever, because then I entered in another company that I learned so much. And then, in three years I became a Java architect.

    Robert O’Farrell:

    Yeah. That's a fantastic example of that focus. I'm quite curious out of those four components that you mentioned before, what have you found quite easy, I guess, to achieve or to at least get clarity around personally? And what have you found more challenging?

    Leandro Barreto:

    Good question. Good question. Yeah. So, learning something that you don't know, it's always a challenge but when you have a desire or a clear focus where you want to go in a few years, things start to be clarified for you. For example, in 2014, I did extension of my MBA in United States to learn about entrepreneurship and things that for me was really, really important. But totally new field, I have no idea what to expect but it provides me the vision to... I always had the idea to have my own company in other words. So, I know that in short term, not in short term, but in midterm at least five years to four years, during that period of time, I would like to have my company.

    Leandro Barreto:

    So, after I did this MBA, I came back to Brazil, and then I started to put myself in situations that makes me learn these new things. And in 2016, I open up our restaurant in Brazil. So, when you have an objective, things, and it's quite funny because the universe starts to help you.

    Robert O’Farrell:

    You make your own luck in a lot of regards too, I think.

    Leandro Barreto:

    Yeah.

    Robert O’Farrell:

    So, if you had somebody who was looking to learn about Ikigai and came to you for some, for your experience and your advice in how to apply it to their lives, what do you think your advice to someone would be who doesn't know much about it?

    Leandro Barreto:

    Good question. Great question. So, one tip that I, or advice that I can give is, and I think that this is fantastic and I apply it in my daily basis. Don't waste time in small decisions on a daily basis because every day we have thousands of decisions to make and our brain capacity is limited daily, at least daily. So, there are some times that we feel like mentally exhausted after, for example, you have six meetings in a row in a day. In the end of the day, you were totally tired. Right? And I once read that the greatest minds don't waste time thinking on small things, for example, Steve Jobs always wore the same jeans and t-shirt every day. And he didn't need to think to use it. He just took it and reuse it.

    Leandro Barreto:

    So, during that time, what I did in 2018, more or less when I was presented to Ikigai. So, what I did, I lived alone in an apartment in Brazil. So, I decided to change it, my life. What I did, I donated my entire wardrobe of clothes with things that I almost never used. And I was only wear eight t-shirts and two jeans.

    Robert O’Farrell:

    Quite a collection.

    Leandro Barreto:

    So, I avoid making those small decisions, especially in the morning, because in the morning, you have a clear mind and you don't have to spend those in small things, because if you think on small things, probably it'll grow during the day. So, for example, another thing that helped me a lot is plan the week. So, Google Calendar exists to be used, right?

    Robert O’Farrell:

    Yeah. Yes.

    Leandro Barreto:

    So, everything that is very important for you, events or plans that need to be done, put on the calendar. And also, talking about the clothes, separate your clothes a day earlier before you go into bed. So, you wake up more calmly, you drink your coffee calmly, and you focus your efforts on what really matters. And once you have freed your mind from thinking about these small things, you can focus your time and energy on learning new things or getting things done the way it should be. And whether it's learning a new language or a new skill, or you can also read a book in the morning because you have free time, let's say. You can focus on what matters to you exactly.

    Robert O’Farrell:

    Yeah. I'm quite curious about this aspect of finding something that you really get consumed by. And I think in this digital age, we have so many things that distract us. Our phone has a lot of notifications where we have a lot of information at our beck and call and sometimes it can be overwhelming to know what we should focus on, and I guess what we can really get passionate about. I'm curious, do you have any insight into that as to how people can find that thing that they just lose themselves in and that they're super passionate about?

    Leandro Barreto:

    Yeah, absolutely. Absolutely. Another thing that worked very well for me is to turn off all the notifications.

    Robert O’Farrell:

    Get a dumb phone just so you don't have that level of notifications coming through. Yeah.

    Leandro Barreto:

    Yeah. Because I read... I don't remember where exactly, but your brain took something like 15 minutes to focus on something. So, if you don't spend 15 minutes of your time, focus on what needs to be done. You cannot focus at all. So, what I usually do, I turn off all of the notifications from my phone. So, the principal one, I just took it off and I don't care about notifications. Also, one thing that I noticed is that when I, for example, when I had Apple Watch. In the Apple Watch, even if you turn the notifications on or off, the iPhone, it keeps doing on the phone. Oh, my God. So, this is one simple device that I can say, because otherwise, you will enter in a black hole in a community and social media and news, and then you'll lose yourself.

    Robert O’Farrell:

    Yeah. I found that personally with the Apple Watch, having something on your wrist that vibrates is incredibly distracting. And I was always very big champion of technology, but that was one area where I just moved away from it, went back to a mechanical watch, just didn't want that level of interruption when I was trying to focus on things. So, I think it's a really key insight to focus.

    Leandro Barreto:

    Yeah. In addition to that, when you, for example, when you are in a meeting with someone and you are actually expecting a message for, I don't know, maybe your family, and then it pops up on your phone and you are in a meeting, and then you take a look into the watch and the people notice that you are not paying attention because you are looking into watch. No matter why you are looking, if it's a message or et cetera, you do provide a psychology... How can I say that in English? Oh, my God. Psychology interference. Let's say it.

    Robert O’Farrell:

    Yep. Psychological interference.

    Leandro Barreto:

    Interference. Yeah. Thank you. That will provide a negative influence to other people. So, yeah, that's why you made the right choice to move into the-

    Robert O’Farrell:

    Yeah. I've heard some people that will actually ask people to leave their phones outside when they go into meetings or leave their laptop outside so that you're present and that you are engaged in the conversation. Because I think even the mere fact that you have your phone near you is a distraction. Even if there's no notifications, its presence is enough to ensure that you're not 100% present in the conversation, which I think is quite interesting from how we focus and our dependency on that rush that we get or that endorphin rush of getting that ping on the phone or that notification.

    Leandro Barreto:

    Exactly.

    Robert O’Farrell:

    I thought we could move on to talk about objective and key results. Or for those people that may not have come across this term before, OKRs are collaborative goal-setting methodology and used by teams and individuals to set challenging and ambitious goals with measurable results. So, to break that down further, the objective part of the OKR is simply what is to be achieved and the KR part of it, which is key results, benchmark and monitor how we get to the objective. So, getting to the heart of setting successful OKR is establishing it clear and compelling why. Is there a secret formula to creating a powerful why to get everyone on board?

    Leandro Barreto:

    Yeah. Great question. So, OKRs, it's all about action and execution. And I think the secret formula, let's say it's having a well-defined proposal and also everyone engaged in seeking the result as the main objective. So, companies in my opinion are made of living ecosystem called human beings. And every human being has its own desires, proposals, goals. And en suite, unite all of the objectives of both the companies and all the people together. That's when we can achieve best results. And that's why some companies are focused on the cultural fit.

    Leandro Barreto:

    And this is one thing that I see growing a lot in the HR area, companies and persons that must, which the cultural fit must match. It basically means that the person has the same values and desires to achieve results as most of the people in the company or what the company understand as their force that they need to keep growing as a company. And I have seen many technically good people failing in selection, in process selection, simply because they don't adhere to cultural fit. And this is much more than a psychological issue because you don't know how to say like people that cannot work as a group.

    Leandro Barreto:

    So, it's better for the company to hire someone who can play as a team instead of someone who is like the lonely wolf that keeps working alone. And the results is for only him and not for the entire company. So, yeah, this is the classic example that I can see. And also, one thing that is good for that is nowadays, our fault tolerance is quite good because today at least serious companies don't punish failures. So, they even encourage you to learn.

    Leandro Barreto:

    And the Spotify models, I remember they say like, "Fail fast and learn fast." So, that was the fail wall was born. So, where everyone shared their failures and they can learn as a team, as a clan, guild. And this is quite beautiful because you can create such an environment where everyone can learn and grow together because humans can fail. And this is normal.

    Robert O’Farrell:

    Do you think that-

    Leandro Barreto:

    And-

    Robert O’Farrell:

    Sorry, I'm just curious. Do you think that companies are more focused around the why these days, or that why has become more important in their measure of success? And you mentioned cultural fit and I love this idea that more companies are much more sensitive to what is their company culture and how does this person work within, or are they going to fit into this company culture? Because the existing people in that company are aligned around their why. And if someone is coming in and doesn't align with that, they understand the impact on their success. So, do you think that company's becoming more and more aware of this and more sensitive to this?

    Leandro Barreto:

    Yes. I think they are. So, as far as they have the right people in the right environment with the right proposal, no matter the why they will find it blindly, let's say. I think it's like a sense of behavior for the people. Because if you see someone from, as your peer, let's say, that's running to an objective that was defined by the company. And you are aligned with your values and goals. You will follow it.

    Leandro Barreto:

    So, this is good for both persons as human beings and also for the company because they show the proposal, they show what is the why we must be, for example, the first selling company for our product in the market, why, and then people who is working on it, they will take it as a personal objective. And this is when you make the connection between the company's objective and the people's objective because when the company grows with this why, with this north star, the people will grow together with you.

    Robert O’Farrell:

    I completely agree. I'm quite curious too from the opposite point of view. Do you think that employees are becoming more aware of understanding the company's why before they join the company? Because we've seen with the pandemic that a lot of companies are now moving to this remote recruitment. And so, the possibilities for employees to work for a much broader range of companies now have increased. And do you think that employees are now finding better wire alignment when they're looking for new jobs because they do have a broader pool to play in per se?

    Leandro Barreto:

    Absolutely. Absolutely. I think that's why Glassdoor is so popular. So, when you are invited for a meeting or for an interview, you can see everything from the company. Like from salary to feedbacks from the people who works there or is not working anymore. And then, you can see if there's a match. And this is quite funny because like 10 years ago, which is not so popular, we are blindly thinking to work, let's say, in a position like software development. So, I have to be a software developer. I have to be a...

    Leandro Barreto:

    So, it was more focused on the position instead of the purpose. And now we are seeing the opposite. Now, the people are looking for the purpose, what the company can help me achieve. And it's more like a win-win-

    Robert O’Farrell:

    Situation.

    Leandro Barreto:

    ... situation let's say, situation. Exactly.

    Robert O’Farrell:

    Yeah, I couldn't agree more. And I think also a lot of people are really focused on how the company takes care of them as a person. They're very sensitive to the fact that they are committing their time to that company. So, there has to be that alignment around professional goals and personal goals. And I think that it's a great shift to see, to come back to the OKR side of things. I'm curious about what benefits do setting OKRs within an organization give or provide?

    Leandro Barreto:

    Yeah. I think OKRs, they are very, very simple. They do not require a specific knowledge to implement it. So, when you have the people committed and engaged to the goal and the why they want to achieve, then the implementation and using of OKRs became naturally. So, company can benefit because he's straight to the point. He's like, "Objective, it's the direction. And the key results are yes or no." So, keep it simple. That's the main benefit of the companies.

    Robert O’Farrell:

    Yeah. I love that. The fact that there's no gray area. You either succeed or you don't, and there's a lot of clarity around that as well.

    Leandro Barreto:

    Exactly.

    Robert O’Farrell:

    I think that with that aspect of OKRs, in your experience, have you seen OKRs set that tend to stretch the team further than they normally would be stretched in terms of what they attempt to achieve than companies that don't set OKRs from your experience?

    Leandro Barreto:

    Yes, but I think it matters on what the company, what's the culture of the company, because I have seen companies that is setting OKRS in the good way, but I have seen companies that is setting OKRS because it's fancy. When it's fancy, you don't have a clear objective. You don't have a clear vision. You don't have the right people. And then, it's very tricky and you will never achieve what you are proposing.

    Robert O’Farrell:

    I'm curious to dig into that a bit more to get your insight on that. Because as somebody who would come into a company that might be setting OKRs, how would you determine that the OKRs are probably not as clearly defined or that they're implementing a process that don't necessarily have the depth or the belief in doing? So, how would somebody come in and determine that?

    Leandro Barreto:

    Good question. Good question. So, the idea to have a objective is like to have something that can be... How can I say that, can provide you like a, not a fear, but it's going to be like, provides you a direction for, but the people who sees it, they think like, "Hey, this is quite hard to achieve I think." So, one example for Google, for example. So, Google in 2008, they tend to launch the Google Chrome. And as I remember, the first year was like, "Hey, this is the objective." Like, "Hey, we want to launch the best browser in the world." And the key result is the number of users because the users will tell you if the browser is good or not.

    Leandro Barreto:

    In the first year, they didn't achieve the key result. But the second year, they rise at the bar again, like, "Hey, now we are much than double the objective." And the second year, they still didn't achieve it. But it was very, very close to it. And the third year, they pass it. So, keep in mind that the objectives must be something that seems like a challenge, a huge challenge, but at the same time, it's very inspirational.

    Robert O’Farrell:

    Inspirational.

    Leandro Barreto:

    Inspirational. Thank you so much. For those who are working on it. So, I think this is most of the point.

    Robert O’Farrell:

    Yes. And what do you see as some of the pitfalls when setting OKRs for an organization?

    Leandro Barreto:

    Awesome. Awesome. So, the pitfalls from my perspective, there are some common mistakes when implementing OKR. So, for example, as I said, not having a clear vision of the goal, so people cannot engage. And especially when you have senior engineers because they don't want to work in something that don't bring purpose for them. Right? So, this is the first one, for example. The second one could be like a system that supports the monitoring of the results. So, you cannot follow up, which is quite important to keep following it if you are, we are close to achieve it. Yes or no? So, a good point.

    Leandro Barreto:

    And one thing that seems quite strange, but it's very, very common in the market is that your product is not finished yet. One personal example that I faced not quite recently, but do you play video games?

    Robert O’Farrell:

    When I get the time. I have two young boys, so I get very little time to do that these days. But yeah, I do.

    Leandro Barreto:

    Yeah. I love doing, I don't have also time, but when I have a litle bit of time, I can spend. So, this little time I try to spend in the best game that I found in the market. And here is the point because some years ago, there was a game that was released and before released, there was several gaming platforms, new sites, and et cetera, that was telling us that, "Here is the game challen... no, the game changing for the gaming market, because it's going to be very good. The marketing for this game was really, really good. And the game was like highest expectations for that. It was always in the top. "Hey, you have to play this because it's going to be very great. You are going to be having a great experience on that."

    Leandro Barreto:

    And the funny thing is that after they launch it, a few hours later, I notice some YouTubers who start testing the game. They began to post videos about so much bugs that they are facing. And within a week, the game had to stop selling because that was a disaster.

    Robert O’Farrell:

    Yeah.

    Leandro Barreto:

    And... Yeah.

    Robert O’Farrell:

    I was just going to say, I can think of a few games that come to mind that fit that criteria.

    Leandro Barreto:

    Yeah. Probably we are thinking the same, but I can say it, so.

    Robert O’Farrell:

    Yeah. Yeah. Do you find that people get OKRs and KPIs confused within an organization? Or have you ever come across any examples of that, where people misunderstand the purpose of between the two of them?

    Leandro Barreto:

    Yes. One thing that came up to my mind is the key result is a simple measure to understand if you are going in the right direction to your objective or not, but KPIs is it's more a performance index for performing for your team. For example, if they are performing in a good way, if we have the right resources for delivering something. And so, I think this is mainly the difference is the KPI, it's a measure for you to, maybe to bonus, to create a bonus for your team or et cetera. And the KR must be not linked to bonus or salary, et cetera. Must be like a direction. Something that, yes, we are achieving it or not. Or if not, what we have to do to correct the direction.

    Robert O’Farrell:

    Yeah. Fantastic. So, coming around to Agile, I'm curious about this marrying of the two, of OKRs and Agile together. How can we combine Agile and OKRs in your experience and your understanding to achieve results that drive high performance?

    Leandro Barreto:

    Awesome. So, as the Agile manifesto says, "People over process," so I believe whenever you maintain a fail-safe environment along with a good leadership, you can get the most of your team. So, connecting what I said earlier regarding the Ikigai and when you have a good leader, for example, in a safe environment and colleagues or peers who shares the same values and goals as you, then you can extract maximum efficiency because high-efficiency teams are teams that are focused and committed with the company results, and that will achieve great business results. Sorry.

    Robert O’Farrell:

    I also love that aspect with the OKRs, with that clear definition, too, that Agile, that processes is that sprint by sprint activity where you're going back and you're looping around and looking at the results of that sprint and going back to the customer and getting customer feedback and that real alignment around what you're trying to achieve as well, to give you that clarity of focus that when you are going through that sprint process, you're coming back and saying, "Okay, are we acting on the initiatives that have come out of these key results that contribute to that OKR?"

    Leandro Barreto:

    Exactly. And also, adding to that, that's why we have the goal for the sprint, right? So, we have the direction for the sprint. So, every sprint you can measure if you are achieving this goal or not.

    Robert O’Farrell:

    And I love it as a mechanism, too, to link back to that, that why piece to really give a clarity around why, which I think a lot of software development sometimes doesn't focus as much as they can on. So, I'm curious, so how can Ikigai mix into this? So, we've talked about that at the start and we talked about the components of it and it was a great framework about understanding a purpose, but how can we use that to achieve better results and stay motivated as a team?

    Leandro Barreto:

    Great question and also quite difficult. But yeah, I believe there are two thin lines that eventually met in the future. For example, the first one is like the individual as a person. So, how he seems himself in, within the organization and how can benefit, how this relationship can benefit from this win-win relationship. And also, the second one is like the individual as a professional. So, based on the skills that he already has. How can he help the company achieve the results more efficiently?

    Leandro Barreto:

    So, in a given timeline, these two lines will cross and then you will be able to extract excellent results because you will have a person with excellent internal knowledge, internal as a person, and also engaged with the companies is seeking as a greater objective, as a north star, and also helping your peers to grow all together.

    Leandro Barreto:

    And I think this is quite like a smile. When you smile at someone unconsciously, you make the other people smile too. So, when you have someone who is genuinely working with a proposal, that person will contaminate other in a good way. And then, you have a continuous string of people delivering consistent results. And I think this is the most important.

    Robert O’Farrell:

    Have you experienced that yourself where you see someone working with purpose and contaminate or infect how you... infect is again, not a great word, but inspired is probably the best word there, inspired the people around them to work in a similar fashion. Has that something that you've witnessed yourself?

    Leandro Barreto:

    Yes, yes. I remember back in the company that I was working in Brazil, that was my first day. I was like, "Hmm, there's something strange here," because everyone is so passionate on delivering their best results for their customer, that this thought influenced me in a positive way to start being like hungry for good results, not only for the company but for me as an individual, as someone who have to learn and teach others. And nowadays, I see these companies, it's achieving a great results with a great leader because even if we have a good team, we have to get someone who is a servant leader, who you can follow and maybe follow blindly in a good way. But yeah, I experience it.

    Robert O’Farrell:

    That's fantastic. But I'm interested, is there anything that you wanted to talk about personally with regards to either of those three topics or even outside of that, that has been inspirational, I think, in your professional development, in your personal life?

    Leandro Barreto:

    Yeah, absolutely. Absolutely. I think Leandro five years ago was totally different person. And when I started looking, not only by myself inside me, but also outside and the opportunities that the world can give me and how can I serve back this, or how can I provide this back to the world? This is very funny because good things start to happen. For example, I never imagined to be working here in Amsterdam. And now, I'm here in Amsterdam, working in a great company with great people, delivering such great results, which is giving me a lot of knowledge to keep learning and keep the wheel turning on, keep the cycle.

    Leandro Barreto:

    And I think today, like performing the best Leandro's version ever, maybe tomorrow, a little bit more, and I can provide this knowledge to other person and I can also learn from other persons, from other people. And that's very exciting. I think that's what motivates me to wake up in the morning, do my sport things like running and jujitsu, and then let's do the work.

    Robert O’Farrell:

    That's fantastic. I love that, that reflection on the past five years, how far you've come. It sounds like you've had a lot of inspiration from a number of different sources, but is there something in there that you think was key to that? Or was it just a general progression over that time?

    Leandro Barreto:

    Yeah. Yeah. Actually, I tried to focus on people who have positive influence on others. So, I try to be more not equal because if you are equal, so you are the same person, so it doesn't provide value to the others, but try to be quite different in your own way. So, yeah, basically, that's what motivates me to get different sources of references and trying to be the best version of myself.

    Robert O’Farrell:

    That's fantastic. I love this mix of the philosophical, which is for me, the Ikigai, and the concrete, well, not concrete, but the workflow aspect of the Agile side of things coming together. Have you traditionally worked in Agile methodologies or did you transition between that may be starting, because if you're from the 2000s, so you probably touched on Waterfall at some point in the past and then came into Agile. Was that your professional progression over that time?

    Leandro Barreto:

    Yeah. Yeah. Actually, I worked a lot with the Waterfall methodology in 2008, when I was introduced to the Agile methodology with Scrum... no, actually 2009, then I saw. "Hey, this is very, very interesting." Let's learn more about it. And then, during this time, I keep working both with the Waterfall methodology and the Agile methodology. And the more I work it with the Waterfall, the more value I saw in the [inaudible 00:54:24]-

    Robert O’Farrell:

    In Agile. Yeah.

    Leandro Barreto:

    Yeah. And that was quite fantastic because then I also learn about SAFe and how to scale it, and yeah.

    Robert O’Farrell:

    I'm quite curious, like because we had a similar path in that regard and I reflect on where we are with OKRs and Agile, and it's interesting that Agile brought us closer to our customer and we speak to our customer on a more regular basis, which I thought was a massive win over Waterfall where you might have months and months of development, and you've got a requirement that you're trying to put into code, and then suddenly, you have this big delivery and that's when you talk to the customer. And usually, the customer comes back and says, "We want all these things changed." And it's a real pain.

    Robert O’Farrell:

    Agile was instrumental in that, but then going up from there and putting that layer of why on top of that, which I think is, again, one of those big fundamental shifts on how we focus on what we are doing. Do you see anything emerging from your experience, your professional experience that is tackling another key challenge with regards to, I guess, how we work and how we deliver value?

    Leandro Barreto:

    Yes. And for example, the customer, they want to see value on what is going to be delivered. They don't want to spend six months to wait something to be delivered. So, I think that's why cloud start being so popular, like SaaS companies, because when you are working on something that is on cloud, for example, you always have the last version. And no matter the day or the hour of the day, there will come new features. And usually, it's transparent for you. And internally from the engineering perspective, the more you deliver, the more quickly you can correct and the more you can understand the market.

    Leandro Barreto:

    And also, that's why some strategies, some release strategies came up so popular like Canary release. So, you deliver a few things to a particular person, and then you can test it. And if they provides you good or bad feedback, you have time to correct it. So, that's why it became so popular. So, I think during this time from now on, we must see a lot of SaaS companies starting to growing because things are in real life now, real time now, so I think it's natural.

    Leandro Barreto:

    By the way, there's a good strategy that was implemented by Spot 5 if I'm not mistaken that was like, but this is more for engineering perspective. They have some robots that keeps doing bad things to the servers.

    Robert O’Farrell:

    Oh, that's the Chaos Monkey.

    Leandro Barreto:

    The Chaos Monkey.

    Robert O’Farrell:

    That was Netflix. Yeah. Yeah.

    Leandro Barreto:

    Netflix, yeah.

    Robert O’Farrell:

    Netflix. And it would take down bits of their infrastructure and break things. Yeah, yeah.

    Leandro Barreto:

    Exactly. It's quite hard to see in some companies, but I think this has become to be more popular during the next couple of months or years, because it will teach the engineers how to deal with that because no one wants to stay working in the weekend. You stay with your family.

    Robert O’Farrell:

    Yeah. I completely agree. I remember when I first heard about the idea of the Chaos Monkey, that it shocked me that someone would inflict that upon their business and upon, I guess, their systems, but then it only takes a production incident to realize that if you had something like that, that you would've built in some provision should that eventuate. And I think that there's a lot of wisdom to it. And so, I absolutely love the idea. I love this, what you were saying about real-time delivery of value to customers.

    Robert O’Farrell:

    And I think back to how Agile has really been fundamental in pioneering that, well, not pioneering it per se, but with the release cadence that you get from one to two-week sprints, you're putting yourself in a position where you are delivering more often. And you mentioned Canary deploys, I think within that. Is there any other deployment strategies that you've come across that also support, I guess, that immediate delivery of value to customers?

    Leandro Barreto:

    Yes. There is another strategy which is called the Blue-Green release, but the difference between it is like the Canary release, you deliver something in the small portions, but the Blue-Green, you, like a switch that you turn on and off.

    Robert O’Farrell:

    Yes. Yes. Right.

    Leandro Barreto:

    Yeah, you can test it. You can deliver new version of your environment or your tool, and then everyone can use it. And if something goes failed, then you have the plan B, where you can just turn on and off, and then you can rearrange the traffic to your tool. But this is very technical.

    Robert O’Farrell:

    Yeah. Very interesting to me, but we might lose a few of our podcast listeners. One last question from me, just within your current professional engagement, were they implementing OKRs before you joined the company? Or was that something that you've seen introduced over that period of time?

    Leandro Barreto:

    From my current company, they are currently working with OKRs, so I didn't participate and implemented it. So, I'm just more focused on helping the teams in implementing the KRs. There were some companies that I worked in the PEs that I helped to build it, and also to build not only the objective but also the KRs. And the objective, it's you spend so much time because you have to understand where the company wants to be in the future.

    Leandro Barreto:

    So, you have to know inside what we have, what we can improve, where we can improve, and then we can base it on that, base it on the objective. We can build up to four key results to be more precise in achieving this. Yeah. But it's quite challenging, but at the same time, very exciting.

    Robert O’Farrell:

    I think that was going to be my question in your experience in seeing a company go from not doing that to then implementing it, what were the real challenges in doing that? And how long did you see that process take before they really got good at doing that? Because it is not only setting the meaningful objectives and obviously measurable key results but also then getting the alignment from the teams around that. What were the big challenges there and how long did you see that process take?

    Leandro Barreto:

    Yeah. I think it depends from company to company. I remember back in Brazil, I had to work with companies that spent months on deciding, but at the same time, I remember my own company took three months to start implementing it. So, I think it depends on the commitment of the people who is responsible for this objective. So, yeah, depends on the maturity also of the company, the people who is working, and yeah. Because the OKRs are quite old, but at the same time are quite new for people, for the companies. Right? So, this is like very challenging. And how do you balance it?

    Leandro Barreto:

    There are some people who doesn't know how to set the correct objective. And then, we came up with the same thing that we are discussing earlier. Like if you don't know where you're going to go, if the objective is not clear enough, no matter if you have good people or bad people, the people will not see value on that.

    Robert O’Farrell:

    Yeah. And you won't get your alignment because people don't either understand or don't believe in the objective.

    Leandro Barreto:

    Exactly.

    Robert O’Farrell:

    That's fantastic insight, Leandro. And I really appreciate your time today. Again, is there anything that you'd like to chat about before we wrap it up? I'm just conscious that we have been chatting for about an hour now and gone off script a little bit too.

    Leandro Barreto:

    Yeah, absolutely. Absolutely. No, actually I'd like to thank you, Rob. Thank you, Agile team, everyone. I don't want to spend much time talking also. It was a pleasure and thanks for invite again. And I hope we can think good things in the future. Like, "Hey, I hope I can provide good insights on this."

    Robert O’Farrell:

    That's fantastic. You certainly have. I've learned a fair bit today as well. So, I'll be going back to revisit some of the talking points from this chat. So, thank you very much again for your time, Leandro. I really appreciate it. And, yes, have a great day. It's kicking off for you and it's ending for us. So, yeah, really appreciate it, mate.

    Leandro Barreto:

    Thank you. Thank you. I really appreciate it too. Thanks again. See you. Have a great day.

    Robert O’Farrell:

    You too. Cheers.

    Leandro Barreto:

    Cheers.