Easy Agile Podcast Ep.22 The Scaled Agile Framework
"Rebecca is an absolute gold mine of knowledge when it comes to SAFe, can't wait to continue the conversation at SAFe Summit 2022!"" - Tenille Hoppo
In this episode, Rebecca and Jasmin are talking:
📌 The value of the Scaled Agile Framework, who it’s for & who would benefit
📌 The Importance of having a common language for organizations to scale effectively
📌 When to connect the Scaled Agile Framework with your agile transformation
📌 Is there ever really an end state?
+ more!
📲 Subscribe/Listen on your favourite podcasting app.
Thanks, Jasmin and Rebecca!
Transcript
Jasmin Iordandis:
Hello, and welcome to the Easy Agile podcast, where today we're chatting all things Scaled Agile with Rebecca Davis, SAFe Fellow, SPCT, principle consultant and member of the SAFe framework team. Rebecca is passionate about teamwork, integrity, communication, and dedication to quality. And she's coached organizations on building competitive market-changing products at scale while also bringing joy to the work, for what is work without joy. Today, we've chatted all things Scaled Agile implementations, challenges, opportunities, and also the idea around optimizing flow, which Rebecca is hosting a workshop at the SAFe Summit in Denver in August this year. Hope you enjoy the podcast.
Jasmin Iordandis:
Hello everyone, and welcome to the Easy Agile podcast. I'm your host Jasmin Lordandis, product marketing manager here at Easy Agile. And today, we are delighted to welcome Rebecca Davis from the Scaled Agile framework. Welcome, Rebecca, and thanks for joining us.
Rebecca Davis:
Thanks. I appreciate being here. I'm excited.
Jasmin Iordandis:
Me too, especially because we are counting down the days before we get to meet you face to face, in person, at the SAFe Summit over in Denver, Colorado. And before we kick off our conversation, I just want to acknowledge the traditional custodians of the land from which we broadcast our podcast today. The people of the Djadjawurrung speaking country. We pay our respects to elders past, present and emerging, and extend that same respect to all Aboriginal Torres Strait Islanders and First Nations' people joining us today. So before we kick off, Rebecca, can you tell us a little bit about yourself and your role within Scaled Agile?
Rebecca Davis:
Sure. I'm actually relatively new to working for Scaled Agile. So I've been there a little over 90 days now, and I'm a member of the framework team, which means I help actually create the Scaled Agile framework and future versions of it. Prior to that, I led LACE at a company called CVS Health, and I've worked at a bunch of different kind of healthcare organizations across my years implementing or organizing agile transformation and digital transformation. And I think one of the reasons that Scaled Agile was interested in me joining the team is just a lot of different experiences across business agility as a whole outside of technology, in addition to within technology. So marketing transformations and HR transformations, legal transformations. But I love being at Scaled Agile and being part of the framework team. It's really exciting to help more organizations, and just the one I'm at, really understand how to bring joy to their workplace and bring value out to the world.
Jasmin Iordandis:
Yeah, cool. And you've given a little bit of information there around why Scaled Agile was interested in you. What attracted you to Scaled Agile, and did you use the Scaled Agile framework in these previous roles that you've just described?
Rebecca Davis:
Yeah. Those are great questions. I think I'm going to try to answer both of them together. But the reason I have always been drawn to the Scaled Agile framework is I ran a few different organizations, both as owning my own company and then also working in startups and working with larger organizations, where I knew that agility was important. But I was struggling as a change leader to find a way to really bring connectedness across large amounts of people. And to me, that's what Scaled Agile does for us, is after a certain size, it's a lot easier to create this common language and this common way to move forward and produce value with the framework. I also really enjoy it because there's a lot of thought that's already kind of done for you.
Rebecca Davis:
So if you're in an organization and you're trying to create change or change leadership, I'd much rather be leading the conversations and my context and making sure that I have a pulse on my particular cultural environment and pull from all these pieces, from the framework, where the thought's already been done about what are the right words and what do we do next, and what's the next step. So I've just found it an invaluable toolkit as a change leader.
Rebecca Davis:
I joined the framework team for a few reasons. One, I'd led so much change in so many different areas that, it's not that I wasn't challenged anymore, but I was really looking for something larger and different, and I've always had a belief that I really want to be the change that I want to see in the world. And I think being part of the framework team gives me access to things like this and all over the world to really help connect the humanness of people alongside with all the great techniques that we've learned, and hopefully expand it and just create a better place to be in.
Jasmin Iordandis:
Yeah. Cool. And you kind of touched on that in your response, but if we had to say, who is the Scaled Agile framework for and who would it most benefit, what would you say to that?
Rebecca Davis:
Yeah. I guess my opinion on that is I believe the Scaled Agile framework is for people who believe that their organizations have it in them to be better, both internally inside of themselves, as well as have this gigantic potential to go help the customers they serve and may be struggling right now, to really realize that potential. So I don't really see the framework as it's for a specific role necessarily. I think it's for people who believe in betterness. And those people, I found, live across an organization and across multiple different roles, and the framework just really helps you align that.
Jasmin Iordandis:
Yeah. And I think one thing that's evident from SAFe, once you learn how all the different practices and ceremonies work together, is exactly as you've said around connectiveness. And you also touched on having a common language. How important is that, when we're talking really large organizations with multiple different functions who, let's be honest, it's quite common for different functions to fall into different silos and things to break down. So how important is that connectivity and that common language, so that an organization as a whole can scale together?
Rebecca Davis:
Yeah. I don't even know how to state the amount of importance that is. I guess, specifically the organization I just came from, had over 400,000 people that worked there. And the last thing I want to is to debate what the word feature means, because that doesn't actually end up within a conversation where we have an understanding of why we want to feature or why we want this particular outcome, or how this outcome relates to this other outcome, if we're spending so much time just choosing word choice and having a conversation instead about what does the word even mean.
Rebecca Davis:
So I like it mostly because it gives us all this common framework to debate, and we need to be able to do that in really transparent and open ways across all of our different layers. So I don't even know how to quantify how much value it brings just to have this ability to bring stability, and the same language across the board, same word choice, same meaning behind those word choice, so that we can have all those debates that we need to have about what's the best possible thing we could be doing, since everything that we can do is valuable, but some things we have to decide are more valuable than others.
Jasmin Iordandis:
Yeah. And I think that really talks to what you were saying about helping an organization to reach its potential. It sounds like getting bogged down in what you call things or how you discuss things. And to be able to align on a common meaning in the end, you kind of need that common structure or that common language. And you're only going to get in your own way if you don't have it. So it makes total sense that the framework could really enable organizations on that journey. And in your experience, because it's implied in the name, it's about scaling agile. And I guess when we think of the Scaled Agile framework, we think of all those organizations of such a large size as the one you just mentioned, 400,000 employees. In your experience, what's a good time to introduce the Scaled Agile framework? Does it need to be right from the beginning? Does it need to be those organizations that are 400,000 people strong? Where is the right time to intersect the framework with an agile transformation?
Rebecca Davis:
Yeah. I think that's a really fascinating question, and my answer has changed over the years. I originally started researching Scaled Agile, because it was my first big transformation alongside of a large organization, and I knew there had to be some solutions out there to the problems I was seeing, and I discovered SAFe. But thinking back, I started my own startup company right out of high school actually. And I really wish that I would've had something to pull from, that gave me information about lean business cases, and speaking with my customer and getting tests and getting feedback. So I feel like the principles and the practices and the values are something that could be used at any size.
Rebecca Davis:
I think the part about scaling, the part about deciding like, "Hey, I'm going to do PI planning," I don't personally feel like you need to do PI planning if you have four people at your organization, because the point is to get teams across different groups to talk. You should definitely plan things 100%. So I think part of the idea is like, "When do I implement a train," or, "When do I have a solution train," or, "When do I officially call something LPM," versus just having discussions because my company is so small that we can all have discussions about things. I think those are a different part of implementing the Scaled Agile framework than just living and believing in the principles and the values and the mindset from whatever size or get-go you're at. Does that make sense at all?
Jasmin Iordandis:
That does make sense. And I guess then the question becomes, where do you begin and what would the first step be in implementing SAFe? And taking from your own experience, where do you start with this framework?
Rebecca Davis:
Yeah. I love that you asked that, as I've honestly seen this happen to me as well as some other change agents, where Scaled Agile gives us this thing called the implementation roadmap, and it has all the steps that you can start with. And it's proven, and companies use it and it works. And what I've found in my own change leadership is when I skip a step or I don't follow that because I get pressure to launch a train, instead of starting with getting my leaders at the right tipping point or having that executive buy in, it causes me so much pain downstream.
Rebecca Davis:
So if I were to give advice to somebody, it's, "Look, pull that map down the implementation roadmap from the SAFe site and follow it. And keep following it. And if you find that you..." I think that, back when I look back and do my own retrospective, the moments where I've decided to launch a train without training my people or launch or start doing more product management practices without actually training my people, it causes me a world to hurt later on with coaching and with communication, with feedback. So it's there for that reason. Just follow it. It's proven.
Jasmin Iordandis:
Yeah. And that's really good advice. And I think when people look at the roadmap for SAFe, there's a lot on there. But when we are talking agile transformations, necessarily there is going to be a lot that could get you there. So it kind of makes sense when all the thinking is been done for you and all those steps have been done. Just trust the process, I guess, is the message there, and following through on all of that. And I think it's really interesting, because the first step with SAFe is, as you say, getting your leaders on board. And often, we might be attracted to doing the work better. So let's start with those ceremonies. Let's start with all those things that make the day to day work better. How important it starting with the leaders of an organization?
Rebecca Davis:
Yeah. I've run the grassroots SAFe implementations where you start with the bottom and then you kind of move up. And personally, and this is a personal opinion, I'd much rather take the time and the efforts to get the communication right with the leaders and get the full leadership buy-in than be in that place again, where I'm trying to grassroot to move up and I hit the ceiling. The one thing I used to kind of tell the coaches that reported to me, and something I believe in deeply, is what we're trying to do with transformation is a journey. It's not a destination. So because we want to start that journey healthy and with a full pack of food and all those things, we need to take the time to really go and be bold and have conversations with our leaders, get their buy-in to go to Leading SAFe.
Rebecca Davis:
If they're not bought in to coming to a two-day course, then why would we believe that they're going to come to PI plannings and speak the way that we hope they will and create the change that they need to really lead? So I think that's one of the most important things, if not the most important thing from the very beginning, is be bold as that first change leader in your organization, go make those connections.
Rebecca Davis:
It may take a while. I've been in implementations or transformations where it started with just me discovering issues that senior leaders or executives were having, and going and solving some of those, so that there was trust built that I was a problem solver. So I could ask for the one hour executive workshop, which really should be a four to six-hour executive workshop, to get to the point where I could do the four to six-hour executive workshop, to get to the point where I could do PI Leading SAFe. And if that's what it takes to gain you that street cred to go do it, then, man, go do it, because that's where you get full business agility, I think, is getting that really senior buy-in and getting that excitement.
Jasmin Iordandis:
Yeah. That's really interesting. And I think building that level of understanding and building that foundation, we can't go past that. And I guess on that as well, from your experience, you've kind of hinted at one there, but what have been some of the challenges that you've experienced in implementing SAFe or even just in agile transformations more broadly, and as well as some of those opportunities that the framework has helped to unlock? So let's start with the challenges. What's some of the hard things you've experienced about an agile transformation and even implementing the framework?
Rebecca Davis:
Yeah, I'll give some real examples, and this first thing is going to sound a little wishy washy, but I also believe it, is the biggest challenge to transformation is you. So what I've discovered over the years, is I needed to step up. I needed to change. I think it's really easy to be in an organization and say, "My leaders don't get it," or, "Some won't understand," or, "It's been this way and I can't change it." And I think that the first thing you have to decide is that that's not actually acceptable to you as a person. And so you as a person are going to go fight. Not you're going to go try to convince somebody else to fight, but you are going to go fight. So I think that personal accountability is probably the biggest challenge to wake up every single day and say, "I'm going to get back in there."
Rebecca Davis:
I think from an example point of view, I've definitely seen huge challenges when the executive team shifts. So when we've got a set of leaders that we did the tipping point, we've gone through Leading SAFe, we've launched our trains. And then the organization, because every organization is going through a lot of change right now, and people are finding new roles and retiring and all that, there's a whole new set of executive leaders. And I think one of the things to discover there is there are going to be moments where it sucks, but you have to go and restart that implementation roadmap again, and reach that tipping point again, because there are new leaders. And that's hard. It really is, and it drains you a little bit, but you've just got to do it.
Rebecca Davis:
I think other challenges I've run into is there's a point after you've launched the trains and after you have been running for a while, where if you don't pay attention, people will stop learning, because you're not actively saying like, "Here's the next thing to learn. Here's the next new thing to try." So I do think it's the responsibility of a change leader, no matter if you're a LACE leader or not, to pay attention to maintaining excitement, pay attention to the continuous learning culture and really motivate people to get excited about learning and trialing and trying.
Jasmin Iordandis:
Yeah. That's an interesting point. How have you done that?
Rebecca Davis:
Hmm. So I think a few things. One, I had big lessons learned that there's a point inside of a transformation where, as an SPBC or as a change leader, that transformation is not yours anymore. So I had kind of a painful realization at one point that I had in my head the best next thing for the organization, and I was losing pulse of the people who are actually doing the work. So I think what I've discovered after that is, to me, there's a point where your LACE members and your change leaders and your SPCs need to start coming from a lot more areas. And honestly start to be made up of people who are not, at the moment, excited about the SAFe implementation, so you can hear from the pulse of the people.
Rebecca Davis:
And then I think if you can get those people and invite in and say like, "I'm inviting you to share it with me what's frustrating, what's good, what's bad, what's great, as well as I'm inviting you to tell me all the things that you're discovering out there in webcasts or videos that seem you'd like to try them, but we're not trying yet, and start giving back the ability to try new things and try things that you feel are probably going to be anti-patterns, but they need to try them anyway." So kind of a scrum master would do with a team of like, "Yeah, go try and then we'll retrospect." I think you have to do that at scale and let people get excited about owning their own transformation.
Jasmin Iordandis:
And what's the balance there between implementing the framework and taking all the good stuff that the framework says is good to do, and then letting people experiment and try those things, as you say, that may be anti-patents? Where's that sweet spot to allow that autonomy and that flexibility and that experimentation with still maintaining the integrity of the framework?
Rebecca Davis:
So I think the interesting thing is they are not actually different. So in the framework, we say hypothesis first, test first. So what I found is a layered kind of brain path where there're the steps in the framework and make sure we have teams and balance trains and all the principles and the values, and if you can live those principles and values all the time, while you're testing new things. So you test first like, "Hey, I want to try having my train off cadence from the other trains. I think it would be helpful for us." "Cool. Test that." And what we have to test it against is are we still living our principles? Are we still applying our values? Are we still applying the core fundamentals of agility and lean throughout that test and also as proof points?
Rebecca Davis:
So do we have an outcome where," Hey, I just made my train into a silo," or do we have an outcome where, "Well, now we have two different PI plannings within the overall PI cadence that one of them we merge with all the other trains and the other one is shorter because our market cadence is faster." Well, that's a beautiful win. So I think the key is it's not different, but one of the test points is make sure to check in on those principles and values.
Jasmin Iordandis:
Yeah. Have you ever seen that work well? The example that you just provided with the PI cadence, that makes complete sense, and it doesn't seem like it's going against the grain with anything that SAFe is there to help you achieve.
Rebecca Davis:
Yeah, I think that. This was kind of a little bit of what my summit talk was on last year, is during COVID, there were some trains. We had, I don't know, 30 trains. Two of them were having daily new requirements emerging from all the different states across the United States and emerging from the government and emerging from everything. Those trains were making sure everybody could get vaccinated across the United States. That's really darn important. And they needed to re-plan sometimes daily. It just didn't make sense to say, "Now we're just going to stop and go into PI planning for three days," when there wasn't any way that they could even think about what the next day's requirements could be. Since then, they still have a faster market rhythm. Then there are other trains that are working on, have a set unknown. There are trains that know that these holidays are when we need to release something or end of year is when we need to make sure that we've got something ready.
Rebecca Davis:
COVID is still in a reactive state. So what they've emerged into this year is those trains are still doing PI planning from my knowledge, I'm not there anymore, but from my knowledge. But they do eight a year instead of four a year. And four a year are on the same cadence and the other four are not, and it meets both needs. So I do think that key is test, and don't test just for the sake of it just because something feels dry or you get a new leader, and they haven't gone through Leading SAFe, but test because something actually doesn't feel right about, "We're not meeting our principles or values right now. We think that we could meet them better in this way. We think we could accelerate the flow of value in this way. Let's try it."
Jasmin Iordandis:
Yeah, cool. And on that, what are some of the red flags that you've seen in practice where those values aren't being met to be able to say, "Hang on a sec. This isn't working. We need to switch course"?
Rebecca Davis:
Yeah. Some of the things I've seen are the whole fun around when people are prioritizing their hierarchy or their piece of the organization over the enterprise value. So I've definitely seen people come to me and say, "Hey, I'd like to do his test." And when I ask the reasons why, a lot of the reasons are like a thinly veiled, "Because I would like more control."
Rebecca Davis:
So I think back to the values piece is that, "Okay, what's your why? Let's start with why. Why would you like to try something? What does that trial outcome achieve?" And, A, if it's really hard to articulate, probably there might be a bad thing going on, or if it is articulated and it actually goes against agility or lean practice and or diminishes flow or creates a silo, that's an initial gut. I think throughout testing, it's important to, the same way that we would do with iterations, have check-ins and demos, not just of what's the product being produced, but what is the change producing? So figuring out what those leading indicators would be and treat it the same way as we would treat a feature hypothesis or an epic hypothesis. We have some outcome we believe we could achieve. We're 100% open to being proven wrong. These are the things that we want to see as leading indicators as success and be really open with each other.
Jasmin Iordandis:
Yeah, cool. And it sounds like what's key to that though is having some concept of what that intended outcome is as a result of that experiment. It's not just going in for, as you say, the sake of doing an experiment. You want to have an idea of where you want to end up, so you can see if we're actually getting there or not.
Rebecca Davis:
Yeah.
Jasmin Iordandis:
That's really fascinating. And I think experimentation and iterative improvement, it kind of goes together. It's not just blindly following something because that's what you are supposed to do. It's preserving the values. That's a really interesting concept. And I think in that, would also come enormous opportunity. So in your experience as well, going back to the times where you've brought SAFe to an organization, or you've been going through an agile transformation, what are some of those opportunities that you've seen the framework unlock for enterprises or organizations that you've been leading those transformations within?
Rebecca Davis:
Yeah. I always was drawn to this idea of true value flow and business agility. So for me, what Scaled Agile helped unlock in a few of my organizations is, I always targeted that, like I'm not trying to make my thing better, I'm trying to make everything better. And with that mindset, really pushing for anybody should be able to take a class. Anybody should be able to take any of the classes. And these days, the enterprise subscription helps with that a lot. When I first started, we didn't have that. So it was also like anybody can take a class, and there should be creative ways of getting it paid for it.
Rebecca Davis:
But through that kind of invite model of really anybody, I had a nurse come take one of my SAFer teams classes, just because she was curious and she saw something about it on my blog, which ended up with her being more excited and getting to do agile team coaching for a set of nurses who were highly frustrated because their work on an individual basis was ebbing and flowing so much, and they felt like they weren't giving good patient care to coaching them on Kanban and having them all get really excited because they got to nurse as a team and whoever was available took the next patient case, and the patients were happier, and just being able to invite in and then say yes to coaching all of these roles that are so meaningful and they're so excited and they're something different.
Rebecca Davis:
And that same model ended up going from nothing to having a marketing person randomly take one of my Leading SAFe classes, which then turned into them talking to the VPs of marketing, which then turned into an 800-person marketing implementation. So I think the key is be open and spend time with the curious. And it doesn't matter if they're in your org. It's not like that's what I was paid to do, it's just really fun. So why not? If somebody wants to talk to you about agile, talk to them about agile. It's really cool.
Jasmin Iordandis:
Yeah, cool. And I think what I love about that is often agile may be associated just as software development teams. But as someone who's in marketing myself, I love the benefit and the way of thinking that it can provide to very traditional challenges, but the way that it can unlock those challenges in ways that not have not been approached before. And I think that there's something to be said in that too, around what you were saying earlier around maintaining excitement. And I feel like this question's already been answered, because often it's discussed, "Okay, we are scaling agile, we're going through a transformation." And it implies that there's this end state where it's done. It's transformed or we've scaled agile, but it doesn't sound like that's the case at all.
Rebecca Davis:
No, I don't think at all. I think mostly the opposite of... If you look at even yourself as a human, your whole life, you're transforming in different ways. Everything's impacting you. The environment's impacting you, whatever happens in your life is just this whole backpack that you carry around and you're transforming all the time. And the exact same thing, I think, for an organization and company. Today's age is nuts. There're updates all the time, there's new technology all the time. You and I are doing a talk from completely different countries, and there's change literally everywhere.
Rebecca Davis:
So yeah, I think part of transformation is helping your organization feel comfortable or as comfortable as possible with the rate of change happening and all the people within it, and not see change as a bad word, but as a positive thing where we can make betterness out there. And it's forever. It's a journey. It's not done. I really like Simon Sinek when he talks about that infinite game. I just feel really close to that of, we're not in it to win this moment or this year, we're in it to make a better future for ourselves and our children, and that's going to take forever. The people are in it right now and they've got to be excited about that.
Jasmin Iordandis:
Yeah. And I think that's that balance of delayed gratification, but constant improvement. So you'll feel and experience the improvement along the way. It's not like it'll be way out in the future where you won't feel the benefit of what you're doing, but it's something that's going to be built up and happen over time.
Rebecca Davis:
Yeah. And I think you reminded me just from saying that. I did that marketing transformation, and I just deeply remember a call with one of the marketing VPs who, after four or five iterations, I did a check in with her. And she's like, "My team is so happy. Is this because of agile? Is this what agile is, is happy with [inaudible 00:32:17]?" "Yes."
Jasmin Iordandis:
Yeah, joy at work, right?
Rebecca Davis:
Yeah.
Jasmin Iordandis:
Isn't that what it's all about? That is so cool. And yet the goal initially is never to go out and make people happy. It's just one of those bonus kind of side effects, a happy side effect.
Rebecca Davis:
Yeah.
Jasmin Iordandis:
Awesome. And I think I really want to talk about this idea, because you've mentioned it a couple times, you've even just mentioned then marketing, nursing. But then when you're in these larger organizations, you've got all these different functions. And I think it raises this idea around organizing around value. So I want to make sure we talk a bit about that, because value doesn't just happen from one function, or it's not delivered from just one function or one team. It's something that many people across an organization may have a hand in delivering. But I really want to get your take around this concept of organizing around value. What does that mean and what does that look like?
Rebecca Davis:
Yeah. I think there's a base concept that is also in that implementation roadmap around what happens first. So how do we first organize around value, because organizations tend to be organized around hierarchy. I am a VP of marketing and I have marketing all the way down. And so there's that first step of identifying what the value is that you produce as an organization. So being able to articulate it to begin with, which is not always an easy conversation. Sometimes it takes a bit of time, and then organizing all the different types of roles around what that value is. So I think that's your first thing in what most organizations implementing scaled agile start with, is just identifying it, forming around it, which ends up being what your trains end up being.
Rebecca Davis:
My experience is, because of that same rapid market change, the world changing so far, it's really important to re-evaluate how you've organized around value over time. So in my experience, one of the really healthy things that we used to do is, at the end of each year, give a chance to look at the different train structures and look at how we've organized and say, "Is this still right? And what's our strategy for next year? Where are we trying to head for our consumers and our users? And is there a different way to organize, that helps us with that?" And I say give a chance because in some years, we'd be like, "No. 80% of our portfolio is actually good to go. Things are flowing. We're doing okay." 20% of it has an entirely new strategic shift that's going to hit them, or, "Last year felt not good. We had too many dependencies. We didn't have the right people on the right trains," all those things.
Rebecca Davis:
And so at least take a pause and look at it, and see if our value still mean the same thing as it did a year ago or two years ago. Do we need to reorganize? What does that mean? What does the change leadership around it if we do need to, so that we're always focused on value, and it's not a definition that we gave ourselves five years ago and just stopped realizing that the world has changed.
Jasmin Iordandis:
Yeah. A living definition because it changes depending on what's going on in the world, but also what's going on within the organization and coming back to that idea of experimenting as well, like if you've tried out a new way of working, and that's gotten in the way. But even something that you said there really stood out is, "Okay, it didn't feel good. We might have had too many dependencies." And that brings up the idea of, "Well, how does that flow of value happen?" Oh, that sounds like there's a stifle to the delivery of value. So how do you optimize that flow particularly when there may be multiple people delivering that value?
Rebecca Davis:
Yeah. And I think Scaled Agile gives us some tools for that. So I think one of them is that first session I talked about, value stream and down vacation, so that you can really do a process for talking and discussing with the right blend of people. What is the value and how can we organize around that? I think past that point, there's another tool that I see used far less than I would think it would be, which is value stream mapping. So after we've identified it, now can we actually map what's happening? From concept to cash, which teams are doing pass offs? How long does it take to get an answer on an email? How long is it taking from testing to all the way to release?
Rebecca Davis:
So doing a lot of intentional measurement. Not measurement because we're judging people, but intentional measurement of, we organize this way, this is where all the pieces are connecting, and how long things are taking, as well as how people feel inside of their steps, like does it feel silo? Does it have an outcome? Did we put all of the designers and HR people and engineers on a train, but we made them separate teams, and so it still doesn't feel connected? That's what mapping's for. And those maps and also the program boards that actually visualize like, "Here's the dependencies," versus, "At the end of the PI, this is what those dependencies actually ended up being."
Rebecca Davis:
It's not that dependencies are bad, but they should be adding value, not restricting flow. So I think those connected stories as well as things like employee survey scores and just employee happiness are really good inputs, to, are we delivering flow. And it is a blended view. Some of it's qualitative and some of it's quantitative. But are our own internal things showing us good, bad and different, as well as how are our customers. So do they feel like they're receiving value or that they're receiving bits and pieces and they're unsure about the connected value? I think all of those are indicators.
Jasmin Iordandis:
Yeah. And would you say you'd need to have an idea of what those indicators are beforehand, so you can keep an eye on them as the PI progresses? So for example, you've done your value stream mapping, you've built your art. At that point, do you identify what those measurements of flow ought to be and keep an eye on them, or is it more retrospectively where you see these kind of things getting a little bit stuck?
Rebecca Davis:
I think there's both. So definitely those metrics that we indicate inside of the framework are healthy, good for teams and trains and solution trains and portfolio. So I think there is a set of metrics that you should and can utilize. Retrospectives are key, because retrospectives create action. So while we measure, then what's the conversation we have about them? Because what we don't want is vanity metrics. And my personal way of defining vanity metrics is any metric that you do nothing with.
Rebecca Davis:
So I think a key is use them to hold conversations and create outcomes, and create actions and make sure that you're prioritizing those actions. I think there's another piece of just understanding that this is not just about team and train. So teams and trains definitely do need to improve and measure themselves, but so does the portfolio, so does the enterprise, so do the pieces that connect to each other across different trains. So I do think if you over focus on, "Let's just make our teams go faster," you may be missing the whole point of how do we make our organization flow better, which may or may not equate to moving faster right away.
Jasmin Iordandis:
Yeah. Yeah. And team and train don't exist in a vacuuming within that organization like whole bunch of-
Rebecca Davis:
No, [inaudible 00:40:43].
Jasmin Iordandis:
Yeah. Well, I think we've touched on some really, really interesting concepts, and just I can't wait to hit the SAFe Summit, which is a really good segue to the fact that the next time we meet, Rebecca, it will be in person. And you're hosting a workshop at SAFe. Can you give us any sneak peek of what we can expect to be excited about at the summit?
Rebecca Davis:
Yeah. First of all, when we meet each other in person, I'm very short. So I think I'm maybe five foot. So that'll be exciting. So Harry, on the framework team and I, are running a workshop about flow. So we'll be doing a flow workshop. I can't talk about all of it yet, because some of it we're going to announce inside the summit, but I'm really excited. So I think if you do sign up for our workshop, you're going to get active advice, and be able to work also alongside other organizations and other people, really understanding flow, and how to apply improvements to flow and how to identify blockers to flow and what to do about it. So we're really focusing on why do certain things matter and what can you specifically do about it, whether you're at the team level or the train level or solution level or the portfolio level.
Jasmin Iordandis:
Cool. That sounds exciting.
Rebecca Davis:
And we [inaudible 00:42:08] a lot of other workshops, but definitely come to ours.
Jasmin Iordandis:
Well, we've just spoken about the importance of flow, so it makes sense. Right?
Rebecca Davis:
Yeah.
Jasmin Iordandis:
Awesome. Well, I personally am really looking forward to coming to SAFe and coming to Colorado and to get to chat with you a little bit more. But thank you so much for your time and joining us and sharing your expertise and experience on agile transformations, scaling agile and the SAFe framework itself. Thank you so much for your time, Rebecca.
Rebecca Davis:
Yeah, I appreciate it. And I look forward to maybe one day being able to do this in person with you in your own country. So that'll be really awesome.
Jasmin Iordandis:
Yeah. Cool. That would definitely be awesome. Thanks a lot.
Rebecca Davis:
Yeah. Thanks.
Related Episodes
- 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.
- Podcast
Easy Agile Podcast Ep.23: How to navigate your cloud migration journey
"Having gone through a cloud migration at Splunk, Greg share's some insightful key learnings, challenges and opportunities" - Chloe Hall
Greg Warner has been involved with the Atlassian ecosystem since 2006 and is a frequent speaker at Atlassian events. Greg has worked as a senior consultant for a solution partner, supported Jira and Confluence at Amazon, and in his current role at Splunk, executed a cloud migration to Atlassian Enterprise Cloud for over 10,000 of his colleagues.
In this episode, Greg and Chloe discuss the cloud migration journey:
📌 The mental shift to cloud migration and how to think beyond the technical side
📌 How to navigate the journey without a roadmap to follow
📌 The four pillars to success for your cloud migration journey
📌 Finding the right time to migrate & thinking about future opportunities beyond your migration
📌 The unexpected value that can come from a cloud migration
+ more!
📲 Subscribe/Listen on your favourite podcasting app.
Thanks, Greg and Chloe!
Transcript
Chloe Hall:
Hey everyone and welcome back to the Easy Agile Podcast. So I'm Chloe, Marketing Coordinator at Easy Agile, and I'll be your host for today's episode. So before we begin, we'd like to acknowledge the traditional custodians of the land from which I am recording today, the Wodiwodi 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 Australia Islander peoples who are tuning in today.
Chloe Hall:
So we have a very exciting guest on the podcast today. This guest has been involved with the Atlassian ecosystem since 2006 and is a frequent speaker at Atlassian events. He has worked as a senior consultant for a solution partner, supported Jira and Confluence at Amazon and at his current role at Splunk, executed a cloud migration to Atlassian Enterprise Cloud for over 10,000 colleagues. So welcome to the Easy Agile podcast, Greg Warner.
Chloe Hall:
How are you?
Greg Warner:
Good, and thank you for having me.
Chloe Hall:
No worries. It's great to have you here today.
Greg Warner:
This is one of my favorite topics. We talk about cloud migration and yeah, I hope I can explain why.
Chloe Hall:
Yes, that's exactly what we want for you because I remember when we met at Team 22, you were just so passionate about cloud migration and had so many insights to share and I was very intrigued as well.
Greg Warner:
To give it a bit background about myself.
Chloe Hall:
Yeah.
Greg Warner:
I haven't always been a cloud person. So you mentioned before about being involved since 2006. I was involved early days with when Jira had the several different flavors of standard and professional, when you'd order an enterprise license for Atlassian and they'd send you a shirt. That was one of the difference between one of the licenses. So based a lot in the server versions, over many years. I looked at the cloud as being the poorer cousin, if you like.
Greg Warner:
I'd been to several Atlassian summits and later Team events where there was always things of what was happening in cloud but not necessarily server. I participated in writing exam questions for Atlassian certification program for both server and DC. For me, in the last 18 months, two years now, to make this fundamental shift from being certainly a proponent of what we do doing on server in DC to now absolutely cloud first and that is the definite direction that we as a company have chosen and certainly why I'm so passionate about speaking to other enterprise customers about their cloud migration journey.
Chloe Hall:
Wow. So what do you think it was that you were like, okay, let's migrate to the cloud, as you were so involved in the server DC part of it? What was it that grabbed your attention?
Greg Warner:
I joined Splunk in 2019 and it wasn't all roses in regards to how we maintained Jira and Confluence. It wasn't uncommon to have outages that would last hours. For two systems that were just so critical to our business operations to have that, I was kind of dumbfounded but I thought, hey, I've been here before. I have seen this. And so it was a slow methodical approach to root cause our problems, get us to a version that was in long-term support, and then take a breather.
Greg Warner:
Once we got to that point where we didn't have outages, we kind of think of what the future would be. And for me, that future was exactly what I'd done before, what I'd done at Amazon, which is where we would move all of our on-prem infrastructure, Jira, Confluence, and Crowd to public cloud, whether it would be a AWS or GCP, something of that flavor. I'd done that before. I knew how we were going to do that to the extent that I'd even held meetings in my team about how we were going to stand up the infrastructure, what the design was going to be.
Greg Warner:
But there was probably one pivotal conversation that was with our CIO and it was in one of those, just passing by, and he's like, "Greg, I've seen the plans and the funding requests." He's like, "But have you considered Atlassian Cloud?" Now, the immediate personal reaction to me was like, we are not going to do that because I'd seen the iterations. I'd seen it over time. I'd worked for a solution partner. I'd worked with customers in cloud, never really thought we could be enterprise-ready. So my immediate reaction was not going to do that. I said, "I'm not going to answer that question right now." I said, "I don't know enough to give you an answer."
Greg Warner:
And I'm absolutely glad I did that because I would've put a foot in mu mouth had I given the immediate response that was... So yeah, I took that question, went and did some analysis, spoke to our technical account manager at the time, and really looked at what had been going on and where was cloud today? Where was it in its maturity? And the actual monumental thing for me was that I think it's actually ready. People make excuses for why they can't do it, but there are a bunch of reasons why you should. And if we look at us as a company, with our own products that we are moving our own customers to cloud, and we are using cloud services, like Google Workspace and Zoom and a variety of SaaS applications. What was so different about what we did in engineering that couldn't go to cloud? And that was like, okay, I think the CIO was actually asking me a much bigger question here.
Greg Warner:
So the result of that was yes, we decided that it was the right time for Splunk to move. And that is a monumental shift. And I know there's a lot of Jira admins out there that are like, if you do this, you're putting your own jobs at risk. The answer is no, you're not. And even within my team, when we had we'd discussed this, there was emotional connection to maintaining on-premise infrastructure and were we giving our own jobs away if we do this? There's all those... No.
Greg Warner:
And there have actually been two people in my team that got actually promoted through the work of our cloud migration that otherwise wouldn't have because they could demonstrate the skills. But that's kind of like the backstory about how we decided to go to cloud. And I think as we are thinking about it, there is a mental shift first. Before you even go down the technical path about how you would do it, change your own mind so that it's open so that you're ready for it as well.
Chloe Hall:
Yeah, I love that. It's so good. And I think just the fact that you didn't respond to your CIO, did you say that?
Greg Warner:
Yep.
Chloe Hall:
That you didn't respond to your CIO straight away and you weren't like, "No, I don't want to do that." You actually stepped away, took that time to do your research, and think maybe cloud is the better option for Splunk, which is just so great and really created that mental shift in yourself. So when you say that your employees, like everyone kind of has that beef that, oh, we're going to lose our job if we move from on-prem to cloud and those employees ended up getting promoted. How did their roles change?
Greg Warner:
When we moved from on-prem to cloud, you no longer have to maintain the plumbing, right?
Chloe Hall:
Yeah.
Greg Warner:
You no longer have to maintain all the plumbing that's supporting Jira, Confluence, BitBucket, whatever is going to move. Now we thought that was the piece that's actually providing value to the organization. And it wasn't until we went to cloud, we actually realized it wasn't. Like what we can do now is different. And that's what my team has done. They've up-leveled.
Greg Warner:
So in the times since we moved from Jira, Confluence on-prem to cloud, we now get involved a lot more with the business analysis and understanding what our project teams want. So when someone from engineering is requesting something that has an integration or a workflow, we've got more time to spend on that than are we going to upgrade? Are we on the current feature release? Is there a bug we have to close? Log for J as a prime example where the extent of where we covered was logging a call with the Atlassian enterprise support and then telling us, "Yep, it's done."
Greg Warner:
Whereas other colleagues within the ecosystem that I spoke to spent a week dealing with that, right? Dealing with patching and upgrades. So the value for our team in the work we do has shifted up. We've also done Jira advanced roadmaps in that time. So we've been able to provide things we would've never got to because we're too busy to the plumbing, to the extent now that we have a very small footprint of on-prem that remains and that's primarily FedRAMP and IO5. It's not quite certified yet. It's going to get there. So we have a very small footprint and I'm the one who has to do the upgrades and now you look at it like, oh my god, that's going to be this couple-week tasks we going to do where I could do all this other better work that's waiting for us in cloud. You don't realize it until you have it removed how much you used to do.
Greg Warner:
And so we used to do two upgrades of Jira year and two upgrades of Confluence a year. We put that down to about a month's work of each. By the time you do all of your testing and you're staging and then do that. So you're really looking at four months of the year you were spending doing upgrades. We don't have that anymore. It's completely gone. And so now we make sure that we do things cloud first. We don't bring across behaviors that we were doing on-prem into cloud. So that's probably one thing we learned was that don't implement server DC in cloud.
Chloe Hall:
Yeah, that's so great. It seems like it's opened up a lot more opportunity for you as well. So I think something that I kind of want to look into and understand a bit more is that people focus a lot on the technical aspect of the cloud migration. What other aspects do you think need to be considered?
Greg Warner:
Certainly people. I mentioned at the very front here the mental mindset and that really started with my team, to get their mind around how we're going to do this cloud migration. There isn't necessarily yet a roadmap that says these are all the steps need to take to get ready for your cloud migration. So we had to invent some of those and one of those two was, what did we want to get out of the cloud migration?
Greg Warner:
I speak to other Atlassian customers. You talk about they're running a project, the project is the cloud migration, the start and the end is the cloud migration day. No, completely wrong. The cloud migration actually has a beginning, a middle, and an end. What you're talking about here, about this first changes is in the beginning, and that should be we're moving to cloud because it should be fundamentally better than what we have today.
Greg Warner:
If it's not better, there's no value in doing the activity. So we started with a vision and that vision was that all of the core things had to work from day one and they had to work better. So create issue, edit issue, up to issue, that just needs to work. There should be no argument whether it does or does not. That needs to work and work better. Create a page, edit a page, share a page. That stuff needs to work in Confluence without any problems. We also need to make sure that there are people in the organization who this could be a fundamental change of how they work, depending on how much they work with Jira and Confluence. So appreciating that there is some change management and some communications that needs to be ready as you do your cloud migration to ensure that your vision is going to work, but also acknowledging you will break some things. You're not going to be able to do a cloud migration and shift you from A to B without nothing.
Greg Warner:
It will go wrong. So we were aware of that and for that, what I would always tell people was that we're really fixed on the vision of making it sure it's better than it was today, but flexible on the details, how we get there. We will probably find different ways as we go along because things will change. Cloud changes itself. You'll discover things you didn't know before. There was a Jira admin that made a decision 10 years ago, you now found that. So yeah, very, very fixed on that vision that day one that we had to have this unboxing experience that when people got to use Jira and Conference Cloud for the first time, they could see why we'd spent so much effort to make sure it was polished and things just worked. And as you went a bit further out, there might be things to do with apps that might not be quite the same.
Greg Warner:
That's okay. And then further out, things you just ultimately can't control. And for that, we had 76 integrations of teams that had written automations from all over the company. We're never going to get to find out what they do, but we knew that some of those would probably break. And so just dealing with some change control and allowing those people to know this is coming, what the rest endpoints will be, how to set up their API keys. We did a lot of that, but we did have one integration that broke and that integration broke because the entire team was on PTO or leave that week. We can't avoid that one. But it was good to see other teams actually jumped in because they'd been involved in updating theirs to go help fix that. So that was okay. We had one integration that we really gave the white glove support to and that was for... We have a Salesforce to Jira integration that's a revenue-generating integration.
Greg Warner:
We gave that a lot of attention to make sure that just worked. But the 76 others, we provided a runbook. The runbook was essentially teams, you do things like this. So they knew how to change and update to the new system. But yeah, certainly the beginning, middle and end. The beginning is all those shifts that you're going to have to change and probably some history about design decisions. The middle is in fact your cloud migration and the end, middle to the end is everything you do with it afterwards. So that's where the real value comes from in your cloud migration. It's once you're in, what can we do with it?
Greg Warner:
And we are towards the end of that now. There have been things that I couldn't have planned for that people have done. So we did your advanced roadmaps, saving the forest there, but also we're encouraging our staff to extend the platform. That used to be really difficult and we've worked with Atlassian to understand what should that look like? And we've settled on using it Atlassian Forge. And so now we have our first app this week, in UAT, in Atlassian Cloud to solve business problems that we have. That's a custom Atlassian Forge app. And we're encouraging our engineers to build those and so they can extend and get that real value through the cloud migration.
Chloe Hall:
Yeah, wow. You've come so far and it's nice to hear that you're towards the end of it and all the opportunities are coming with it and you're seeing all the value. It's all paying off as well. I think I just want to go back to that moment where you talk about there isn't essentially a roadmap outlay. There isn't someone or something to follow where it says this is where you need to start. These are the steps to cloud migration. And I think a lot of people, that's what they fear. They're like, we're not sure exactly where to start. We're not sure what roadmap we'll follow. How do you navigate that in a way?
Greg Warner:
So I get back to that when I talked about the vision. We said we're fixing the vision flexible details. Early on when we signed for cloud migration, it was in the first week after we'd signed for it, that same CIO asked me, "Greg, what's our date? When are we moving? Because you've sold me that this is so much better. Where's the action? When are we get this?" And we took a good six weeks after we signed to actually understand the tooling that's available. So for Jira, there's really two options. There's the Jira site import and the Jira cloud migration assistant. And on Confluence side, there's one that's called the Confluence cloud migration assistant. Better kind of understand how those technologies work. And for a couple weeks there, my team actually considered if we did the migration ourself, we could probably save the company a bunch of money and we would own it.
Greg Warner:
We would know how this thing worked. We got about four weeks in and decided that was a terrible idea. Do not do that. Any enterprise customers I talk about that say we're going to do it ourselves, do not do that. Do not do that. And part of the reason is that there's really four pillars to success for your cloud migration. Jira migration, Confluence migration, apps, and users. And we did not know how to do apps and users and we probably could have gotten away with Confluence and Jira. But we said, look, this is something that we actually need to have a partner involved. And so we did ask for partners to provide their way of doing it, knowing what they knew about us. And we did provide as much detail as we can. We had two partners actually provided completely different methodologies how to get there.
Greg Warner:
So this is that flexible on the details, but we really had to make a decision on what worked for us. So when it really came down to Jira, would we do a big bang approach and just switch it over in the course of a weekend or did we want to do cohort by cohort over time? And we decided for us, because we are a 24/7 organization that's supporting our customers, doing the big bang switchover, that was the best way to do it. So that's one of the reasons we chose the partner we did. But that partner didn't necessarily have a roadmap of where they want to go. But we did then explain what we want to get out of this. That was the first thing, was about it needs to happen on a weekend. So that then filters down what your choices are. The ecosystem apps part is really important to make sure that one, there may have been apps installed in your system that have been there for 10 years and you're not sure why they're there anymore because it was four Jira admins ago.
Greg Warner:
Nobody knows what's there. But if they don't have a cloud migration pathway, you really should consider they're probably going to hit their end because there is no equivalent. So you can rule them out. Identify the ones that do have a business process with them. And for that, Salesforce for us, we had to find a cloud-first connect that would work. So that meant that we knew that was going forward. But really, I think the key thing that we invented that we didn't know about was that we created this thing called an App Burn Down. And that's where we looked at all the apps we had. We had about 40 apps. We said, okay, which ones are not going to go to cloud? Which ones don't have a migration pathway? Which ones are going to replace something else? And so we started to remove apps over the course of about three months.
Greg Warner:
So people would see that we're starting to get away from on-prem design decisions and old ways of doing things. But we also said, but once we get to cloud, this is the pathway out of it. So that we said, look, we're going to turn this app off but you're going to get this one instead, which is the cloud-first app. So people could see how we're going to make the jump over the river to get there. But it meant that we would, over time, identify apps that weren't used. If we turned them off and nothing happened, it's fine. But also we did come across some where they were critical to a business use. And so if we didn't have an answer for those yet, it gave us time to find one. And with your user base, typically it's your colleagues, that's going to be your most critical customers. They're going to ask, okay, you're turning it off. When do I get the functionality back?
Greg Warner:
And by doing that App Burn Down over time, that does buy you time to then have that answer. So it's a much easier conversation than I'm simply turning off functionality, I don't have an answer for you yet. There are things like that. It wasn't necessarily a roadmap, but working with a solution partner is absolutely the right way to go. Don't try and do it yourself. They also work with Atlassian and they have far better reach into getting some of these answers than you can possibly ever have. And I have on at least three different occasions where our solution partner did go and speak directly with an ecosystem partner to find out what's the path forward. How can we make this work? So it is good. The migration is really a three-way collaboration between yourself, your solution partner, and Atlassian. And you all have the same goals. You want to get to cloud and it does work really well.
Chloe Hall:
Wow. Yeah. So sounds like hope everyone got that advice. Definitely don't take this on your own. Reach out to solution partner. And I really like how you said you went to two different solution partners and you found out what their ideas were, which ways they wanted to take you, so you could kind of explore your options, work out what was the best route for Splunk. And it's worked very well for you as well. Having that support I think as well. Yeah. Sorry, you go.
Greg Warner:
The choice of the partner is really important and it's probably one of the earliest decisions that we made to get that one right. And I remember several times thinking about, have we got the right people on board? Did we speak to... And it was an interview process to the extent that when we had our final day after we'd been working with Atlassian and with our partner for six months, one month after our migration was completed and we're all done, we had one final Zoom call with all of us and took a photo and did that. But it kind of felt like a breakup, to be honest, because we'd been in each other's faces for six months and working. We're now all saying goodbye. We might not see each other. It was like the weirdest feeling. But it did work. And so yeah, it is a real fundamental choice.
Greg Warner:
Just take the time, make sure they understand what we want to do, make sure you understand how they're going to do it. But yeah, if we have done it ourselves, we would've got ourselves all caught up in knots, wouldn't have been a successful migration or so. I'm a technical guy. I want to solve it. I want to be like... But I think the actual right answer was no, you don't need to know how this works 100% because you're going to do this hopefully just once. And so focus on the real business value things about dealing with stakeholders and the change and making design decisions that are really important for you because you're going to own those probably the next decade rather than worrying about how do I get my data from A to Z?
Chloe Hall:
Yeah. It definitely would've felt like a breakup for you because you would've been working side by side for so long, dealing with so much. Are you still in contact with them or...
Greg Warner:
Yeah, we had this fundamental thing we always said is we're always, if there's a problem, we're always cautiously optimistic, we're going to solve it. We did engineering challenges that we went through, but I did say right early on is, the ecosystem is only big and we're all going to bump into each other at some point. So yeah, let's make sure that we're still friends at the end of this. And I didn't realize how important that was until later when I was in New York for Christmas and I arranged to meet the project manager that worked for us. She lives in New York, so how about I meet you so... So we met each other at the hotel and she's like, "I have never met a customer outside of work to do this." Yeah, I gave the story about it felt like a breakup, but she did say that at the beginning you said we'll be friends after.
Greg Warner:
Yeah it is because it can be really hard. I've been on the consultant side where you kind of have to have some hard conversations and sometimes... You want to make sure that everyone understands the problem. You're trying to make it better so that at the end of it, you can still be friends like that. That is the thing. There probably will be engagements later on that you might need them again. So you want to make sure that you have your choice of best in breed partner to choose from. You have those relationships. They understand what you want to choose. So yeah, it is really important to choose the right partner. Don't necessarily based on price but choose the partner that's going to work for you, understands what you're trying to get out of your cloud migration and they'll be there in the future when you need them for another cloud migration or a much more gnarly project. Try and be friends at the end of it.
Chloe Hall:
And definitely it's good that you have that friendship now because they have that understanding about your business and what you want and the value of it. So if you do need help again, it's a lot easier to bring them on board straight away. So now that you've performed a cloud migration and you're coming towards the end of it, do you look at the process any differently to when you were at the very beginning?
Greg Warner:
Yeah, I thought we were just executing a data migration just yeah, on-prem to cloud.
Chloe Hall:
Yeah.
Greg Warner:
Pretty straightforward, nothing big. I was pleasantly surprised as we're making some of these decisions as we went along, that it was more than that. There were business processes that we could improve. There was the beginning, the middle, and end. I didn't realize that until actually after the end. So when we did our cloud migration, it was actually the week before Thanksgiving in the US. It was November 19. And even that decision was made in just going for a walk at lunchtime. When should we really do this? And I kind of came down again, spoke to my project manager and said, "How about we do this in the cloud migration the week before Thanksgiving?" Because 50% of our workforce is located in the US and a large proportion of that will be on leave or PTO before.
Greg Warner:
So by doing it over a weekend before then we're ensuring that... Like when you open a new restaurant. You don't want to have all of your tables full on the first night. We knew that we were going to have everybody using Jira and Confluence day one after a migration because we're going to break some stuff. They actually turned out to be really exceptionally good idea. And I encouraged people to find... Look at your data and work out when is low time to do this? I've been involved in Jira and Confluence for a long time and just thought it's task tracker and it's a wiki. There's nothing there that I don't really know about. But one of the decisions we made was actually that when we completed the data migration and it was ready to go, I always said if we waited, do we get a better result? And the answer was no.
Greg Warner:
We should make this available to people now. And so we opened it up on a Sunday morning in the US, which was starting to be business hours in Australia. We started making teams aware that they can now go ahead and use Jira and Confluence. And it was the feedback that we immediately got from those teams that were starting to use Jira service management in cloud for the first time, about, "Wow, this is so much better than it was on-prem." And people said, "I can actually see the attention to detail you've made on fields and descriptions and the changes you've made." And it started to impact people's workday that this was better than it was. I didn't expect that to come back. And so I have a montage that we share with the team of all these Slack messages from people saying, "This is really good. This is much better than we had before."
Greg Warner:
What I didn't also realize is that when we moved from on-prem to cloud is the data that we had became more usable and accessible. Hadn't planned that. It seems obvious now, but when we put it in cloud and it has all the security controls around it and now no longer has the requirements of things like VPN to get access to it, people could build new things to use it to be able to interact with your issues, to interact with pages. And so we started with 76 integrations and over space of three months now we had this big jump in the first three months up to about a hundred something and now we're going to Forge And what it means is people who have had this need to be able to get to the data can now get to it. I didn't see that coming. I just thought we were just server cloud. But yeah, having a more accessible has led to improvements in the way that our teams are working but also how they use it in other applications that just simply wasn't available before.
Chloe Hall:
Yeah. Wow. That's great. And it's good that you were able to receive that feedback straight away from the teams that you had in Australia. I think that's really good and it sounds like it's created such a good opportunity for you at Splunk as well now that you're on cloud.
Greg Warner:
Yeah, it's certainly a business leader that can propel you forward and I eagerly come in now and look at what are other teams going to do with it. And so when we had the first team that said they want to build a Forge app, I'm like, Sure. We should not discourage that at all. Extend the platform. That's why we spent the money and time to do it. What can you do with it now? And we did certainly make Atlassian aware on the product side, like how we're using it and where we'd like to see improvements. If you look at the server DC comparison, I used to be that person that would look at the new features in cloud and ask that question about, when is that new feature coming to on-prem? To going to being that customer who's now, I have that feature today, right? And I'm using it because we don't wait for it.
Greg Warner:
So you mentioned about things you didn't plan from the roadmap. There are design decisions that I talk to enterprise customers that I need to make aware of about. One of them is to do with release tracks. In enterprise cloud, you can choose to bunch up the change to cloud and then they get released periodically every two weeks, every month. When I looked at that, came back to one of our principles about don't implement server in cloud, why would we do that? Atlassian has far more data points on whether this works for customers at scale than we do. So why would we hold back functionality? So as a result we don't do release tracks. We let all of the new functionality get delivered to us as Atlassian sees fit. And the result of that is our own engineering staff, our own support staff who use Jira, get the notifications about new products and features and this is fantastic.
Greg Warner:
Again, why would we implement server, which is where you would bunch up all your changes and then go forward? The other thing too about our cloud migration journey is don't be blinked that you're just doing a cloud migration today and then the project ends. There are things you need to be thinking about as you go along, but what's the impact in the future? So for us, we have multiple sites. Enterprise customer have multiple sites. So there are design decisions that we've made so that we can, in the future, do cloud to cloud migration. You will move sites. Your organization could be bought or could be buying companies. So you do mergers and acquisitions. And so as part of that, we have some runbooks now that talk about using the cloud-to-cloud tooling so we can move a Jira project from a site here to a site there, how we'd move users here and users there.
Greg Warner:
And that actually came about through the assistance with our TAM, not focusing just always on the cloud migration date but also what's that look like six months later? What's it look 12 months later? So that you don't perform your cloud migration and then lock yourself in a corner that later on now I have to unwind something. I had the opportunity to fix it. So yeah, I do encourage migration customers to also think six months, 12 months beyond their cloud migration. But what could also happen and then speak to your solution partner about design decisions today that could affect you in the future.
Chloe Hall:
Yeah. So you definitely need to be thinking future-focus when you're doing this cloud migration. I know you've addressed a lot of the opportunities that came out of the cloud migration. Was there anything else that was an unexpected value that came from it that you wanted to share?
Greg Warner:
The other value is make it more accessible. We have seen people use it in different places that we hadn't thought about. So some of the things that we were doing before, we had to have a company-owned asset to get on the VPN and just things like that. That actually restricted people in where they could do work. Whereas now we've, as long as you've got a computer or mobile device connected to the Internet, absolutely you can use a mobile device support, you can get access to it. Approvals that used to be done on a computer are now done on a mobile device. Those things. But I think the integrations has been probably been the one thing I'm most... We're not the catalyst. We kind of pushed it along but seeing people get real use out of it and using the data for other purposes. We have seen people build some microservices that use the data from Jira that we couldn't do before. Again, you're just unlocking that potential by making it more usable and accessible.
Chloe Hall:
After going through the whole migration journey and, like you said, you're coming towards the end of it, what were the things that stood out to you that you're like, okay, they didn't go so well? Maybe if I was to do this again, how would I do this better next time?
Greg Warner:
So I get back to that day one unboxing experience. You know you want to give it that best experience. And we delivered that for people in Australia and APAC as we opened it and they got to use Jira for the first time and it worked fine. And that is mainly the result of a lot of emphasis on the Jira piece because we said, we know this is going to be hard. It's got workflows, issue schemes, notifications schemes. This is going to be hard.
Greg Warner:
So we started that one really early and then probably about 60% down through our migration journey, we started on Confluence. We thought how hard can Confluence be. It's a bunch of spaces and pages. It can't be that hard. We actually hit some migration challenges with the engineering tooling with Confluence, which meant that the Confluence UAT was delayed. The Jira UAT was fantastic. Ran for a month. We found some problems, got fixed, got answers. We were really confident that was going to be fine.
Greg Warner:
And then we hit this Confluence piece. We're like, wow, this is going to be a challenge. And there was at least one time I could think of. It was a Saturday morning at breakfast where our solution partner sent me a Slack message about, I think we've got a problem here with some tooling. What are we going to do? Towards the middle of the day, I was kind of scratching my head. This could be a real blocker. We actually worked with Atlassian, came up with the engineering solution, cleared that out. That was good to see, like in the space of 12 to 24 hours, there was a solution. But what it meant was that it delayed the Confluence UAT and it made a week. And there was something we found to do with the new Confluence editor and third-party apps right at the end of that week. And we had to really negotiate with our stakeholders to make this go ahead.
Greg Warner:
Because again, if we'd waited, we'd get a better result. No, we really should go. We know that there's this problem. It's not system-wide but it affects a small group people. So we did it. But for about a hundred people they have this really bad Confluence experience because of this thing. And so for me, I couldn't deliver on that thing I promised, which was a day one experience that was going to be better than what it had before.
Greg Warner:
Now we did work with Atlassian and app vendors to get some mitigation so it wasn't as bad on day five. It wasn't day one but it wasn't perfect. But I would certainly encourage people to make sure that you do treat Jira and Confluence with as much importance as each other. They do go together. When I did our cloud migration, we did it on a weekend and I remember coming back after dropping my kids at school on Tuesday and sitting in the car park. I was like, wow, we actually pulled that off.
Greg Warner:
If we'd propose to the company to move your company email system and your finance system on a weekend, the answer would be no because it's too big a hat. But what we'd said is we're going to move all of our Atlassian stack in a weekend, which really is two big systems, Jira and Confluence. So if I had the time again, we would've started Confluence much, much earlier and then we wouldn't have the need to rush it at the end. And that really did result in a bad day one experience for those people. We have worked with Atlassian since then. We're getting that resolved. We know other Atlassian guys have the same problem. I would start early and don't underestimate the complexity that could happen. There will be some things outside of your control.
Greg Warner:
I talk about this Confluence problem and the migration tooling, which is actually do at scale. Not every customer will see it. We saw it, I conducted customer interviews when we were doing our solution partner decision and the customer actually told me this. Like I should have started Confluence because we had this problem, we wasted some time, and we did it. I even have my notes. But it wasn't until later, same problem, you even had the answer and they told you and you still waited. So I'm spending a few minutes on this podcast talking about it because it happened to me. It's probably going to happen to the next person. So if I could do one thing and that is just encourage you to start it earlier. You're going to end up with a much, much better migration and hopefully can deliver on that day one experience that I couldn't do.
Chloe Hall:
Yeah, no I'm so glad that you've shared that with the Easy Agile audience as well because now they know and hopefully the same mistake won't keep getting repeated. Well, Greg, my final question for you today, and I don't know if you want that to be your answer, but I think it's really good just for the audience, if there's one key takeaway that they can go away with them today from the podcast, what would be that one piece of advice for everyone listening to start their migration journey?
Greg Warner:
The first thing to do is to prioritize it. So if you're an Atlassian customer that's using on-prem Jira or Confluence and you don't have a timeline and you don't have a priority to your cloud migration, start there. Open up the task, which is start to investigate Atlassian Cloud and choose a date. Because yeah, there will come a situation down the track where you might be asked by your CIO and so it's better to have an answer prepared already. I would encourage people to start to look at it because it is the future. If you look across the industry, people are moving to SaaS. It's really a question. Do you want to maintain and be that customer wondering when that feature's coming to cloud or do you want to be that customer in cloud who has it today? We have seen a monumental shift to when we moved to cloud in functionality, availability, all the good things that cloud delivers. And it's one of the biggest promoter... The person that used to write exam questions for servers now saying go to cloud.
Greg Warner:
Absolutely. So when I've spoken to other enterprise customers, particularly at Team, I said like, when do you plan your cloud migration? I was like, wow, we're going to start it in three years. I'm like, three years? You need to go back to the office next week and start like 12 months because yeah you will... There is absolutely a competitive advantage to doing it. And it's not just me being now as biggest cloud opponents. We see it, we see it every day and for me, this is one of the most influential projects I've been involved in with Atlassian since 2006. This one here is going to have a long-lasting effect at Splunk for a long time and I'm happy to speak to yourself at Easy Agile and others about it and here at their cloud journey because I want to go to Team next year. I want to make sure we have these conversations in the whole way about, I got that one thing. It's either I started my Confluence migration earlier or I actually put in a timeline of when we should start our cloud migrations.
Chloe Hall:
Yeah, beautiful. That is some great advice to take away, Greg. And so honestly, thank you so much for coming on the podcast today. You have provided some brilliant insights, takeaways, and also because there is no roadmap, I feel like your guidance is so good for those who are looking to start their cloud migration. Yeah. We really appreciate you sharing your knowledge.
Greg Warner:
All right. Thanks for having me on. Thank you for listening.
Chloe Hall:
No worries.
- Podcast
Easy Agile Podcast Ep.2 John Turley, Digital Transformation Consultant, Adaptavist
Transcript:
Sean Blake:
Hello, everybody. I'm Sean Blake, the host of this episode of the Easy Agile podcast. I'm also Head of Marketing at Easy Agile, where our mission is to help teams around the world work better together. We have a fascinating guest with us today. It's John Turley from Adaptavist. John is a pragmatic Agile leader with 25 years experience working in companies at all levels, from teams to C suite, always bringing real value, adding change to the way organizations work. Dissatisfied with the standard discourse around transformation and agility, he is passionate about applying cutting edge knowledge from fields as diverse as sociology and psychology. We're really excited to have John on the podcast today. So John, thanks so much for being on the Easy Agile podcast.
John Turley:
You're welcome, Sean. Pleasure to be here.
Sean Blake:
Thank you so much. So John, you've got a lot of experience in the Agile space, in the tech space. And I'm not trying to call you old. But I'd love to get a sense of what's changed over 25 years. It must just be night and day from where you started to what you see now.
John Turley:
There's a lot of change. And I'm pretty comfortable with old. I'm 48 now, and it's closest to 30 years now. That tells you when I first wrote that bit in the bio. So the technology has changed. That's mind blowing. I started off in ops, and then infrastructure and project management and stuff and 1999, 2000, it would take us three months and 50,000 quid to build a couple of web servers with a pair of load balancers and firewalls and a database at the back. And now we spin them up in seconds.
John Turley:
This is profound. Platform technology is profound slack or I mean platform technologies, that makes a massive difference to the way we interact. Scale is a massive issue. I would say that the world is sort of dichotomized into very large and quite small organizations. There seem to be less in the middle. It's just a gut feeling. We see, I think trust is collapsed. We see that in Edelman Trust Barometer. We see the complexity has increased. That's deeply problematic for us. [inaudible 00:02:23] has been measuring that one.
John Turley:
And we see that workforce engagement is at all time lows through the Gallup World Poll. Those things are big, big changes. What's the same though is the people, the way the people think, the way we construct our reality, our mindset, if you like, the way we make sense of the world around us is very, very similar. So although we now talk a lot more about Agile, the waterfall and waterfall for many is a bit of a dirty word, not for me and same with command and control. People are taking the same mindsets. This is measurable and provable. People are taking the same mindset that they had around waterfall and command and control using different language of Agile and behaving in the same way. That hasn't changed.
Sean Blake:
Very interesting. So you touched on trust, and how basically we've seen this breakdown of trust across the board. And I've just watched a documentary that's come out on Netflix around the Social Dilemma, and how the trust that we have in these big social media platforms is eroding. And we're getting a little bit skeptical around what these big companies are doing to us as the customer. Do you find that that's a hard balance with the people that you work with around being customer focused, but still building a profitable and growing business?
John Turley:
Yeah, I do. Yes, and the way I think it manifests itself, which again maybe we'll get into the sort of the psychology and the sociology as well as the complexity science, I'm into it later. But there's a very clear way that that lack of trust manifests itself. I'm not sure it's the lack of trust that manifests itself. But there's a very clear thing that's happening is people, there's repeated patterns of behavior I see all over the place in a lot of the work I do, which is one on one and with groups, that people hold on to this idea that their view is right and anything that doesn't comply with that is wrong.
John Turley:
This is a view that comes from the predominant mindset from what [inaudible 00:04:33] call the sort of expert or the achiever mindset, and it becomes a barrier to us collaborating and learning together and innovating. If somebody with a different point of view is dismissed as wrong, then there's no common ground to start to build trust. Trust is eroded from the outset, and that means that we can't collaborate, and in a complex world where we need to collaborate ever more closely and learn together and innovate, that's a deep, deep problem.
John Turley:
And the response seems to be that people actually withdraw, they withdraw into groups, we might call them cliques or echo chambers. The sociologists call this process homophily. This is a function like many say of platforms like Twitter, we retreat into groups that echo the opinions that we already hold that then reinforce those opinions, and separate us from the opinions of others and reinforce the opinions we have. So the gaps between the cliques grow wider, and particularly in times of COVID and the lockdown that we've had here, and that we seem to be maybe heading back into the isolation perhaps adds to that, and we see it more and more. So at a time where we need to be getting our act cliques and talking with understanding with others with different views, we're actually psychologically in a difficult position to be able to do that. And so that's what we might generically call the lack of trust manifests itself in the work that I'm doing. And that's how I see it with almost everybody that I work with, including myself, by the way. It's not an easy thing to conquer.
Sean Blake:
So what does your day to day look like, John? I think your official job title is Digital Transformation Consultant. You work for Adaptivist as one of the most well known Agile consulting practices in the world, I would say. What does that mean for you day to day? What does your nine to five look like?
John Turley:
So we're really involved in three things. I'm really involved in three things. And it's all about learning, collective learning, organization learning. So we're involved in a lot of original research. We do that original research with a number of academic partners in a program that we're putting together. We've been doing a lot of the research on our own. But as it gets bigger and more credible, other partners are coming to join us and they're very credible partners.
John Turley:
And the research is uncovering new learning. And that new learning points us to new consulting practices where we can take that learning and embed it into a workshop, say or how we might use the research instruments that we've borrowed from academia in the real world to measure social networks or psychological complexity or the amount of autonomy in the environment. So we can then use that to work with teams to help them shift from a sort of functionally oriented way of working to a cross functional way of working, which whether we're talking about safe and Agile release chains, or whether we're talking about Lean software management and value streams, whether we're talking at a team level or an organizational level, the challenge is essentially the same. We need to orientate ourselves around the creation of customer value in cross functional teams that are focused on delivering that value, not just delivering on their function. And that switch brings with it some deep, complex, deep psychological challenges that we're just not really equipped to meet. So we bring sort of the people and culture element, the tools and the Agile methodology simultaneously to bear in teams to help them make that shift. So that's really what my day to day work looks like, so the research and the practice.
Sean Blake:
Okay, research and practice. And when it comes to the practice side and encouraging that cross functional collaboration, how hard is it for people to get on board with that recommendation or get on board with what the company is trying to do?
John Turley:
For most people, it's really hard. So my experience before doing the research that I guess we started a couple of years ago I was just referring to, was something like this recently. We'd often get, so I've worked in the Agile space for a long time, I don't quite know when I started working in that space, in other words, full space, but a decade or two, let's say, and now bumped into a repeated problem, we get our, let's say, thinking of a specific example with a specific client about three years ago, very functionally orientated, trying to make that shift into cross functional teams. So we got a group of five people together from different functions, so designers, testers, developers, a couple of ops people, and between them, they should be able to obviously, launch some working code within 10 days or whatever. We were probably trying to spring into the real world.
John Turley:
And they were all great people. I knew them all personally. I spent time working with them all. They were very sort of Agile in the way they approached the development of the software that they did, and we put them in a room virtually to begin with and we asked them to produce a piece of code that works across functions, produce a piece of code and release it at the end of the week. And they didn't. And we thought what on earth happened there? We didn't really understand this, so we tried it again. But we assumed that the problem is because we'd done it virtually.
John Turley:
So this time, we got everybody together in Poland, as it happened in a room, we set it all up, we talked to them at the beginning, then people like me sort of left the room and let them get on with it, got to the end of the week, same outcome, nothing has happened. And if you talk to them, while they say, "Yeah, my phone pinged and there was a support incident, and you just couldn't.", and they had lots of very plausible reasons why they couldn't come together as a cross functional team. But the fact remains twice in a row, the most capable people haven't done it.
John Turley:
So we had a really long think about it, one of the senior leader in the business and myself. And we realized that the only thing that could be happening, the only thing that could be going wrong here is that there must be some sort of breakdown in the dialogue between the group in the room. So we ran it, we ran the workshop, let's call it for a third time. And this time, we had somebody else in the room just watching what was going on.
John Turley:
And they spotted something happened really early on. One of the people from the UK said to one of the Polish developers, they said, "Look, think of us like consultants. We're here to help you, to transfer knowledge to you so that you develop a capability so that you can do this on your own." And at that moment, the person who was in the room said that the dynamic in the room seemed to change. People glazed over. And I think what it was is that that word consultant that the English person had used had a different meaning for a colleague in Krakow. I think that meaning, the meaning of consultant meant, we're just here to tell you what to do and not actually do anything and put ourselves on the hook for any work, just kind of watch you do it.
John Turley:
And I think at that point, they kind of went, "Okay, well, all right, I get it, same old, same old. We'll do the work you English guys talk about it, because it's an English company.", and that breakdown started to occur. So the question we started is, I've seen that all over the place. So the question we started to wrestle with in our research is what's happening in those moments when that dialogue breaks down what's happening?
John Turley:
And what we've discovered is that there is a number of research studies, the biggest is about 10,000 people, that shows that around about 50% of people are at a level, and this is 50% of leaders in a study of 10,000, so for middle management, senior management, so it's a skewed number. So in reality, in software teams, it's probably more than 50% of people have reached a level of psychological complexity that suits the environment as it was, but has some limitations in cross functional working.
John Turley:
So they have a mindset, a way of making their reality that works well in a functional environment, but it's challenged in a cross functional environment. And that mindset, this way of thinking, which is very prevalent, is a way of thinking where individuals draw their self esteem from their expertise, just to put it very short, simple as an oversimplification. And the thing is, if you're drawing your self esteem from your expertise, when your expertise is challenged, it feels personal.
John Turley:
If it feels personal, people are likely to get defensive. And it's not because they're stupid, or they're not interested or they don't want to, the psychologists can show it's a level of psychological complexity, where that's just how our minds work. That's just how our meaning making works. Now, if that's the stage you're at, if we imagine me as a developer sitting down with a tester, and the tester's saying to me, "Look, the way you've written the code isn't the best way to do it for me, because I can't test it."
John Turley:
If I'm drawing my self esteem from my expertise as a developer, I'm likely to reject that, and might even start to think thoughts like, "Well, I think what really needs to happen here is that you need to be a better tester." I think that's the problem. And then we get this separation. Now at the next stage is psychological complexity. And these stages are in a framework that we do move through these stages. Again, it's an oversimplification, but it's observable and measurable. At slightly later stage of psychological complexity, things start to change. People start to recognize that the world is much more complex, that it's not black and white. And actually, there are multiple ways of doing things.
John Turley:
So to go back to my example as a developer, the tester might say to me, "This isn't the best way to write the code as far as I'm concerned." And what I'll hear is the, "Oh, as far as I'm concerned." It might be as far as I'm concerned, it's not fair enough. How can we change the way I'm writing the code to make it easier to test? But I can't do that if I respond like it's a personal criticism, you know what I mean? So what we started to uncover in the research is a correlation between how successful cross functional teams can be, and the level of psychological complexity in the leaders and the individuals in that team.
Sean Blake:
Interesting. So there's a book that we've been reading at Easy Agile recently called Radical Candor. And really, it comes down to giving constructive feedback to each other, not in a way where you're attacking them personally but you're trying to be honest around how we can work more collaboratively. And like you said with that example, how can a developer write code in a way that the QA tester can actually perform the tests on it? For someone who's new to cross functional ways of working, what advice does the research have around preparing that mindset to receive some of that radical candor, to receive that feedback in a way that you don't take it personally?
John Turley:
Well, so it's a great question, you put it really well, because radical candor is fine. We have, I work in a team that is very candid. We have some difficult conversations, and we don't even really dress our words up. And nobody gets offended. We just know that it's a shortcut. We might get our words wrong, but it's a shortcut to unlocking value to finding out how to work together. But it's not about the words that each of us picks to express. It's about how the other chooses to react to the words landing, as much as now that's a dialogue, it's a two way thing, it takes two to tango.
John Turley:
And the way we can develop a mindset that's more suitable to cross functional work is interesting. First of all, we've got to get out of comfort zone. We've got to be prepared to get out of our comfort zone, not far necessarily, and not for very long necessarily, and not without support and understanding from the colleagues around us. But we do need to get out our comfort zone. Otherwise, psychological growth can't occur. This is what I'm talking to about now is the work really of Robert Kegan and Lisa Lahey, who do a lot of work in dialogue on radical candor.
John Turley:
So we've got to get out of our comfort zone. But we've also got to be addressing a complex problem with a group of people when we're outside of our comfort zone. And that complex problem has to be meaningful, and it has to be salient, it has to be something that we care about, it has to be something relevant to our day to day work. And if we've got those characteristics in the environment that we working in, then there is an opportunity for individuals to choose to develop their own psychological complexity.
John Turley:
So that environment that has those characteristics, we would call in Kegan's word a deliberately developmental environment, because we can't separate the development of individual mindsets from the environment that that mindset functions in. The reason most of us have got the mindset that draws self esteem from expertise is because that's actually what most environments that we work in or not. That works in a functional environment. It's where you get promoted, it's where you get hired. It's where you get your Scrum Master badge and all that other stuff that gives you status and makes you feel good.
John Turley:
The world that we work in for many of us honors that expert way of making meaning. It doesn't honor learning and admission that yours might not be the best way to do things in the same way. So we have to shift the environment to support the individual to choose to take that developmental step because it can't be something that's done to them. You can't make people develop a more complex psychology. You can't train them to do it. You can only give them an environment that supports that step if they want to take it and if they don't, fair enough, that's okay. But maybe cross functional teams for them, if they don't want to because the hard place is to work.
Sean Blake:
Is it a problem that people find their expertise or find their self esteem from expertise? Is part of it encouraging men to find their confidence in things outside of their work or is expertise an honorable pursuit?
John Turley:
I wouldn't say it's a problem at all. Expertise, and the development of expertise is an honorable pursuit. Drawing your self esteem from your expertise is a very necessary part of our psychological development is a stage that can't be skipped really. I said to you before that I don't like to say things like that without the research base, but the psychology certainly imply that it's a stage that can't be skipped. So we've got to do it. We've got to go through this stage. The stage before we're drawing our self esteem from our expertise is where we draw our self esteem from our membership of the group.
John Turley:
And that's very important too, if you think of us as children or being part of a group is essential for our survival, so ingratiating yourself into that group, not rocking the boat, so we don't jeopardize our group membership is critical. But at some point, people start to realize, well, actually, I have to rock the boat a little bit if we want some direction. So separating your meaning making from drawing your self esteem from the group to drawing your self esteem from your expertise is a development in that sense. Drawing your self esteem from your expertise means the best way to write this code is let me train somebody to do it.
John Turley:
It's critical. But like all developmental stages, it has its limitations. So it's not problematic in any way, unless the individual is in a complex environment in which that expert way of making meaning isn't well suited. And then you got a mismatch between psychological complexity and environmental complexity. And when you've got a mismatch like that, the individual's anxiety will go up probably, employee engagement goes down, certainly wellbeing goes down, people revert to an earlier way of making their meaning that's more embedded in their expertise or the group, just to the point, they need to get more sophisticated.
John Turley:
So the problem is the mismatch between psychological complexity and environmental complexity. That's why we need to support, as the world gets more complex, that's why we need to get all get better at supporting the development of individuals into a level of psychological complexity that suits the more complex environment. That's kind of the nub of the problem. Nothing wrong with being an expert in drawing your self esteem from your expertise. People have done it forever, and will continue to do so. Every time you get in a flash car and you feel good, because you're in a car, you're drawing your self esteem from the status symbol, which is very similar to your expertise. As a young man, I put on my sharp suit and I feel a million dollars. Nothing wrong with that at all, but it's limited. That's the problem.
Sean Blake:
Understood, understood. So you've spoken about research and measurement and having an evidence based way of making decisions. When it comes to this cross functional way of working or digital transformation or teams moving from the old way of working to an Agile way of working, do we have evidence to say one way of working is superior to another way of working? And when you're talking to these clients or these customers, can you guarantee that if they work in this way, it's going to lead to better outcomes for the business? How do you approach that conversation?
John Turley:
No, I can't do either of those things. So I would never go anywhere near nor would I research saying that one way of working is better than another way of working or we can say like the mindset and the environment that there are ways of working that will work better depending on the problem that you're trying to solve. But it's very unlikely that one could be considered right and the other wrong in all sorts of circumstances, but more than that, I would say that doesn't matter what your way of working is or a team's way of working is. If the mindset is the way of making sense, if the reality doesn't also shift, then you're just following a new process, a new way of working with the old way of thinking, and you're going to get the same results just with different words.
John Turley:
So for me, that isn't entirely true, I'm quite biased. I guess in the work I do, I've got quite a perspective. If you shift mindset, then everything else will drop into place. If you change everything else, but don't shift mindset, nothing else will drop into place. What we can say however, is that there are three things, let's call them the three elements of a cross functional team that are hidden to people in organizations at the moment.
John Turley:
So generally, we think if we've got people with the right experience and skills working suitably hard, then they're going to work as a successful cross functional team. And if they're not, they're either not working hard, they're not the right type of person, or they haven't got the right set of skills, so fire them and hire somebody else or give them or put them on a training course, and that solves the problem, which of course it doesn't.
John Turley:
We would say that there are three other elements that remain hidden parts of the cross functional team that are more critical than that, and we're beginning to be able to demonstrate that there is a correlation between these three things that I'm going to tell you about on both employee engagement and team performance.
John Turley:
And these three hidden elements are the structure of the social networks that underpin the way people work. So if we think about how we as groups of human beings organize ourselves, we might think about hierarchies and hierarchy diagrams and old charts and bosses and stuff. That's not really very important for a cross functional team. What's much more important is the social network that develops across that team, who works with whom and when and how, right? Do the developers and the testers and the testers and the ops guys and the designers and the technical architects, do they all work together in a cross functional team?
John Turley:
Now that's a social network. That's a network that's formed through individual autonomy because they want to get the job done not because the boss says you've got to go and do it. In fact, it can't be done because the boss says go and do it. So we have worked with some friends in academia with actually an Australian company called Polinode to measure their various ways we can get the data, what those social networks look like. And the structure of those social networks is key.
John Turley:
As we look at the structure of social networks, we can see whether those teams look like their function, sorry, organized hierarchically, or were they organized for cross functional working because of the network structure. So network structure is one element. The other is psychological complexity. So we've worked with a gentleman called David Rook, who did the original research and developed a psychometric instrument that can measure an individual's stage of psychological complexity, both the structure and the substructure. And that mindset complexity is also linked along with network structure to where the teams can function cross functionally.
John Turley:
The third thing that was the hardest bit, the last bit of the jigsaw that we sort of put into our hypothesis is we need to have adequate degrees of autonomy. We needed to develop a much better understanding of what it means for teams to be autonomous than we had, and how that autonomy relates to control and how control undermines autonomy and how we all tend to be orientated, to taking the cues in the environment either as instructions, which we must comply with or invitations to be autonomous. And we now have another psychometric instrument. So the third instrument that we use, we call the motivation orientation scale, excuse me, that can measure an individual's likelihood to interpret inbound information as an instruction or an invitation to be autonomous.
John Turley:
And once we know that, we can start to challenge this common perception within product teams, software teams that the team is autonomous, because everybody thinks they are autonomous. And in fact, everybody is, research shows mostly autonomous, but we might be almost entirely autonomous, or we might be 60% autonomous. We can measure this. And then we can say to teams, "Look, you are autonomous as a bunch of individuals. But you also have this control thing going on where you're responding to inbound requests."
John Turley:
And we need to be more autonomous. So once we can start to measure it, we can start to challenge their ideas of how autonomous they are. And we can start to examine where the teams are choosing to respond from that control orientation or their autonomy. So they're the three things, autonomy and control, complexity of mindset and network structure, equal employee engagement and team performance. That's what our research says. So what we can say is, to your question in the beginning, there is a network structure, a level of psychological complexity and the amount of autonomy that correlates to successfully working as a cross functional team. And in that sense, we might think that those levels are right, in some sense.
Sean Blake:
Okay. So what does a 100% autonomous team look like? And do they still have interaction with, say the executive team on a day to day basis? Or are they at odds, those two concepts?
John Turley:
No, they're not at odds. They do have, they might have day to day, I suppose they would, they will have either directly or indirectly interactions with the executive team. So the first thing we need to bear in mind here is that the research that we're leaning on is something called self determination theory, which is a theory of motivation. And it has quite a specific definition of autonomy, which is not what we might normally think. Often autonomy is taken to mean as sort of the general use of independence. So if we buy a company, we might leave it to run autonomously, which would mean we just left it alone for a while. And autonomy in this context doesn't mean that. It means individuals acting of their own volition, individuals deciding how to act towards a common purpose. So the team has to have the vision which they can self organize around. You can't self organize without autonomy. If you don't got autonomy, you have to wait to be told what to do. And then it's not self organization.
John Turley:
So autonomy leads to self organization, and self organization can be around a common vision or a set of goals or an OKR is quite a sophisticated way to do instead of management by objective, then we can self organize in a way that sort of honors the need to be part of an organization, doing some coordinated work, but that doesn't rely on a manager telling the individual what to do.
John Turley:
That's what an autonomous team looks like. An autonomous team, you need the autonomy is really a self organizing team. And the self organizing team is deciding what the team ought to do in order to achieve a wider objective, which could be integrating with other self organizing teams. And obviously, the direction is set often by the executive. So all these things sort of come into play. It's not a question of control on the one hand or autonomy on the other or Agile on one hand or waterfall on the other.
John Turley:
So we're going to blend the two. We're going to balance them. And that balance needs to shift not only across teams, but also depending on the level that the organization is, that the team is working in the organization. And what I mean by that is the need for control and measurement increases in many ways as you go higher up the organization. So we want high degrees of autonomy at a team level where we're creating customer value. But we need to recognize that that self organizing team has a legitimate requirement to integrate with some elements of controlling the organization, because if we have some elements of control, then we can't do the accounting and be accountable for where we spend investors' or shareholders' money, you know what I mean? So it's much more complex in the sort of the dichotomized world that people tend to look at, which is very black and white. Is it Agile or is it waterfall? Are we autonomous or are we control orientated where you're both and the blend of which needs to shift depending on the environment here.
Sean Blake:
Okay, okay. So there's always a need for a bit of control on top of the autonomy.
John Turley:
It's a balance, right? We're all comfortable with control, aren't we? We all comply with speed limits, for example. We're perfectly okay with that. Control is not a dirty word. Some will do things that we're told to do sometimes, and we're happy to do it. Sometimes we do it begrudgingly. We're not happy to do it. Sometimes we reject it. There's nothing wrong with control in itself. It's the overuse of control to coerce people to do things that they don't want to do. That's when it becomes problematic because it undermines an individual's autonomy, which is a basic, universal psychological need. We all need to have a sufficient degree of autonomy to feel well.
Sean Blake:
Okay. Okay. So we know that Agile's had a good run, it's been decades now. So do you still find that you come across the same objections when you're speaking to these executive teams or these companies perhaps from more traditional industries? Do they still have the same objections to change as they did in the past? And how do you try and overcome them?
John Turley:
Yes, they do. So one of my strange experiences as a young project or program manager, whatever I was, is that when I would end up in a room full of software developers who were Agile, probably the language they would have used at the time and a bunch of infrastructure engineers who followed waterfall, and the distaste for one group for the other, it was almost visceral, and you could see it in them. There would be a bunch in, I don't know, Linux t-shirts and jeans, and then the infrastructure waterfall people would probably be wearing suits.
John Turley:
I mean, it was really obvious, and it was hard to bring these groups together. That was my experience in let's say, around about 2000, I sat with a client yesterday, who said exactly the same thing. They said that in their organization, which is going through a very large, Agile transformation at the moment, they said, "These are their ways. We kind of got people at the two extremes. We can sort of bookend it. We've got the waterfall people who think their way is best and we got the Agile people who are totally on board with Agile transformation."
John Turley:
And what I heard when the individual said that is quite senior leaders, the Agile people are on board with the Agile transformation brackets because they think their way of working is best. And what I tried to point out to that senior manager was that that was one group, there were perceptions anyway, that one group was into Agile and got cross functional working, all that got cross functional working and the other group didn't, actually the two groups were operating in the same way.
John Turley:
They both thought their way of working was right, and one was espousing the virtues of waterfall and the other Agile, but the fact was they both thought that they were right, and the other was wrong. And they were both wrong in that. Waterfall works really, really well in a lot of scenarios. And full on Agile works really, really well in some environments. In some environments, it's quite limited by the way, in my opinion.
John Turley:
My friend and colleague, John Kern, who was a co author of the Agile Manifesto in 2001 or 2004, whatever it was, I can't remember. He says, "I love waterfall. I do loads of waterfall, I just do it in very small chunks." And because the fact is we've got to do work sequentially in some manner. I can't work on an infinite number of things in parallel. There has to be a sequence.
John Turley:
And that really, when I heard him say that, it sort of filled my heart with joy in a way because for somebody with a waterfall background, I used to say, "Look, I don't get this. In waterfall project management, we're talking about stages. And in Agile, we're talking about sprints." And they've both got an end. One's got a definition of done. And one's got some acceptance criteria, and they both got a beginning. The only difference is the language and the duration.
John Turley:
So what if we make sprints, sorry, stages 10 days long? What's the difference now? And yet people would say, "Well, we're Agile, and we do sprints, and that would still be a stage." Come on, we've got to find some common ground right to build a common meaning making between large groups of people. Otherwise, only the Agile listeners amongst us can work for Agile organizations, and everybody else is doomed. And that's not true, is it? That's nonsense, right? So we've got to come together and find these ways of working as my friend John Kern points out so eloquently.
Sean Blake:
Okay, that's good advice. So for these, some people that you meet, there's still this resistance that has been around for many years. How do you go about encouraging people to get out of their comfort zone to try this cross functional way of working and be more transparent, I guess with contributing to the team and not necessarily pushing towards being just an individual contributor?
John Turley:
Another great question, Sean. So there are a couple of ways we can do it. The psychometric instrument that I mentioned earlier, that can sort of measure I kind of always put that in inverted commas, because it doesn't really measure anything, it assesses, I suppose, is a really, really powerful tool. Off the back of that measurement, the psychologists that we work with can create a report that explains lots of this sort of meaning making stuff, adult developmental psychology to the individual. And it tends to be mind blowing. It really shifts people's perspective about what they are and how they're operating in the world.
John Turley:
Once people start to understand that there are these developmental stages, and we all move through them potentially to the last days of our life, we can start to see the disagreements. They just start to fall away. Disagreements start to fall away, because they cease to be seen as opposing views that can't be reconciled, because I'm this type of person and they're that type of person.
John Turley:
And they start to be seen as incompatibilities in meaning making. So people start to go, "Okay, well, I think this and you think that. How are we both making our meaning around this, that means we can see other's perspective?" And immediately, then you've started to find a mechanism to find some common ground.
John Turley:
So the leadership development profile report, which is the report that comes from the psychometric instrument really sheds a lot of light on for the individual, both on how they're working and what development looks like, what psychological development looks like for them. So that's a powerful tool. We have another service that we call dialogue partnering, which we're piloting, which is sort of what over an eight or 10 week program, it's a one on one collaborative inquiry into how an individual is making their meaning, and what the strengths of their meaning making and the limitations of their meaning making are.
John Turley:
And once people start to realize that the way, the reason they feel defensive because the way they code has just been criticized is because they're drawing their meaning from being the best coder on the planet. But there is a development path that leaves that behind, which is where many, many people get to. It's kind of like an a-ha moment, people just realize that reality is different to what they thought and it can be adjusted.
John Turley:
So the LDP, the Leadership Development Profile reports, dialogue partnering, and working with senior management to create a deliberately developmental environment, which does those things I mentioned before, they're the critical tools that we use to help individuals unlock their own psychological development. And the question is, of course, why would they be motivated to do this? Why would they care? And they care, because 80% of people have got a very low level of engagement in their work. Most people are treading water, killing time. It's not a joyous place to be. Once people start to work in cross functional teams and get involved in joyous work with their colleagues to create things they couldn't, which is a basic human instinct, that's a buzz, then you come into work and enjoying yourself.
John Turley:
That's what I said to you at the beginning of that call, right? I'm having a great time, I'm working with some brilliant people unlocking new knowledge that we believe humankind doesn't have. That's a buzz. I'm not treading water in my role, you know what I mean? And this isn't unique to me. In my view, the whole world could be like that. We could all work in roles like that, maybe that's got a bit far. But certainly, many more of this could then currently do to get on board with the psychological development and enjoy your role more, enjoy your work. There's a lot of time.
Sean Blake:
Yeah, I really resonate with what you said about the buzz. And I've seen that happen when the light bulb comes on in people, and it's no longer this factory line of work getting passed down to you. But you realize you're now part of a team, everyone's there to support you, you're working towards a common goal. And it's transparent, you can see what other people are working on, and you're helping each other build something together. It's actually fun. For the first time in a lot of people's careers, it's a fun and enjoyable experience to come to work. So that must make you feel really good about doing what you do.
John Turley:
Yeah, it does. It's why I get out of bed, and it's what I've been about for 20 years trying to unlock this, really help other people unlock this. I got a phone call from a colleague the other day who said they were doing some exercise, and they were thinking about their new role. And they thought to themselves, this is what it feels like to do joyous work.
John Turley:
I mean, that [inaudible 00:42:51] job done, because this is a very capable individual. Once they're feeling like that, you know that they're going to do great things. When they're feeling like they're other people feeling, that people are clot watching, or there's this culture of busyness, where we can't admit that we don't know things. And then we've got to be in a meeting doing something, in the transparent world that you're just talking about, if I've got any work to do, I can just sit and say, "I'm going to work today, I'm waiting for more stuff to write." And it's not a bad thing. It's like, great, you're working at a sustainable pace. That's a good thing. I worked for a Swiss bank for years and years, working at a sustainable pace but nobody was interested, you need to work at a full on flat out unsustainable pace. And when you're burned out, you can go and we'll get somebody else to come in and do it. That's how it works. That's miserable.
Sean Blake:
It's not what we want, Sean, is it? It's not what we want. And unfortunately, a lot of people have been there before and they've experienced it. And once they see the light, they never want to go back to it, which I guess is a good thing once you recognize that there's a better way.
John Turley:
Yeah, agreed.
Sean Blake:
Yeah. Okay, well, I think we're going to wrap up shortly. I do have two more questions for you before we call an end.
John Turley:
I'll try and keep the answers brief.
Sean Blake:
No, that's fine. I'm really enjoying it. I could probably go for another hour but I know we've got other things to do. So in the research, I've read some of your blog posts, and I watched some of the talks that you've done and events in the past, and you speak about this concept of hidden commitments. And I just like to learn a bit more, what is a hidden commitment? And what's the implication?
John Turley:
Great question. So Robert Kegan and Lisa Lahey, developmental psychologists, wrote a book called Immunity to Change. This is a book that I read here a few years ago. And in there, Bob and Lisa talk about hidden commitments. And so they start by pointing out that we all make New Year's resolutions and they all fail. We really mean them when we make them. And when I was in my late teens, maybe I really did mean them when I made them. But I could never keep them.
John Turley:
In another book, Kegan points out, I think it's in the book called The Evolving Self. He points out that a large majority of men, after they've had heart attacks, I think it's a study in America. But it's been a while since I read it, I think it's six out of seven, don't change either their diet or their exercise regime after they've had a heart attack. And the reason he uses that as a case study in the book, because he's pointing out that it's not that these people don't know what to do, you need less calories in, more out. And it's not that they're not motivated to do it. They've had a near death experience. They'd like to stay alive, we presume.
John Turley:
Yet still, they don't make any meaningful change to their diet, their exercise regime, why not? And what Bob and Lisa say in the book from their research is that it's down to hidden commitments. We all have our way of making meaning. We have our values and our assumptions that we absorb from society as if by osmosis. And we don't question them. We can't question all of the assumptions that we absorb as we grow up. It's just not possible. So we have these hidden assumptions that we're committed to hidden commitments. And sometimes, these hidden commitments conflict with our stated objectives. And when the hidden commitment conflicts with our stated objective, the result is that we get very confused about the fact that the stated objective sort of falls by the wayside, and we don't really understand why. We might think, I would think a common out, because I just need to try harder, I just need more willpower. I just need to stay the course. And it's not true very often. There is something else in your meaning making this conflicted with our stated objective. And once you can surface it, then you can start to examine that hidden commitment, and you can play around with it.
John Turley:
And when you can play around with it, then you're adjusting your meaning making. And the technique that we use in dialogue partnering comes from Bob and Lisa's book, where we're essentially uncovering those hidden commitments and seeing how they conflict with commitment. So that's sort of, and then once you can see it, and you can experiment with it, you can start to unlock change in yourself. Peter Senge, I think he's director of innovation. He's very famous, director of innovation for MIT. And he has a beautiful little quote, something like, "What folly it is to think of transforming our organizations without transforming ourselves?"
John Turley:
We need to change our relationship with power in order to change the way power is distributed across our organizations. And that's an example of a hidden commitment that we don't normally think about. We just think we can empower people magically, whilst retaining all the power for the senior manager. And that just doesn't work. There's a hidden commitment, conflicting with the idea that we want to empower our teams, which is a quite flawed idea.
Sean Blake:
Wow. Okay. Well, I really like the approach to work and looking at the social structure, the social networks, and the psychology behind it all. It's really fascinating and it's not something I've really come across before, especially in the Agile space. So that's really unique. Thanks for sharing that, John. Last question for you. 2020 has been interesting to say the least. We've talked about some things that have stayed the same over your career, some things that have change. What do you think is going to come next, looking forward to the next five, 10 years? What are some of those trends that you think are really going to stand out and maybe change the way that your work, it changes the way that that your nine to five looks or changes the way that you interact with your clients?
John Turley:
I think that this won't just change the way my nine to five looks. It will change like everybody's nine to five looks. I think that the world is in a difficult place. A lot of us are upset, and it looks like a bit of a mess, and we're all anxious, I think. A lot of us are anxious. But as a friend said to me, he was quoting somebody else, never let a good crisis go to waste. The amount of changes, a lot of energy in the system, the amount of changes in the system is palpably changing things.
John Turley:
Many of us recognize there must be a better way of doing things because our ways of organizing ourselves as society, including our organizations is collapsing. It doesn't work anymore. People are realizing through work that people like the names I've mentioned, and through our original research, I hope will sort of contribute in an original way to this, that there is a better way of organizing ourselves that humankind does have the knowledge and the experience to do what we need to do.
John Turley:
It just isn't in IT. We need to look outside of it to what the psychologists say about mindset, not what the Agile people say about mindset. That's a radical idea. And as we import this learning and this knowledge, we have a framework that helps us understand to a much greater degree what's really going on, and how we can unlock real change. So everything that I talked about today, very little of it is original. We have some original work I can't really talk about. Does it matter? The knowledge is out there. If we do the people and culture bit and the tools and the methodology together, then it scales, then we change the way organizations work, which is going to change everybody's nine to five.
Sean Blake:
That's great. It's bringing it back to basics, isn't it? What we know about human beings, and now let's apply that to what we know about work. So that's really eye opening. And I've learned a lot from our conversation, John. I've got a few books and a few research papers to go and look at after this. So thank you so much for appearing on the Easy Agile podcast, and we really appreciate your time.
John Turley:
Sure, my pleasure. I mean, I love and we love at Adaptavist to sharing what we're doing. So we can all engage in more joyous work, man. So thanks for helping us get the message out there.