Easy Agile Podcast Ep.16 Enabling high performing agile teams with Adaptavist

"Great convo with Dave & Eric! Key takeaway: revamp Easy Agile's org structure representation. Exciting stuff!"

Nick Muldoon, Co-Founder and Co-CEO of Easy Agile, is joined by Dave West, CEO, and Eric Naiburg, COO, from Scrum.org.

In this episode, Nick, Dave, and Eric unpack the current agile landscape, discussing the role of the agile native and emphasizing the importance of building connected teams by flipping the hierarchy and putting leaders in supporting roles.

They emphasise the importance of empowering the people closest to the problem to make the call, and ultimately creating an environment for success to happen.

We hope you enjoy the episode!

Share your thoughts and questions on Twitter using the #easyagilepodcast and make sure to tag @EasyAgile.

Transcript:

Nick Muldoon:

Hi folks. Welcome to the Easy Agile Podcast. My name's Nick Muldoon. I'm the co-founder and co CEO at Easy Agile, and today I'm joined with two wonderful guests, Eric Naiburg, the Chief operating officer at scrum.org, and Dave West, the chief executive officer at scrum.org. Before we begin, I'd just like to acknowledge the traditional custodians of the land from which we broadcast today, the people of the Dharawal speaking country. We pay our respects to elders past, present, and emerging, and extend the same respect to all Aboriginal, Torres Strait Islander and First Nations people that are joining us today. So gentlemen, thank you so much for making some time. We really appreciate it.

Eric Naiburg:

Thank you.

Nick Muldoon:

I guess I'd love to just jump in and, Dave, I've got a question for you first and a follow on for you, Eric. I'd love to just get a quick assessment, Dave, of the Agile landscape today and I guess the shifts that you may have seen now that we're out of these COVID lockdowns, these back and forth, COVID lockdowns.

Dave West:

Yeah, it's interesting. So I've been the CEO almost eight years here at scrum.org, and it has changed a bit during those eight years. I think what we're seeing and is a, dare I say, the deployment phase, mass deployment of these Agile ways of working and this Agile mindset throughout industries and throughout all organizations. It's more than an IT software development thing. And I think that that was accelerated during COVID. What's interesting though is many of the characteristics of Agile that became so important during COVID, particularly around empowered teams, particularly around trust, particularly around the hierarchy and the reduction of hierarchy, some of those things are being challenged as we return to the new normal, which some people would rather was just the normal. So I am seeing some of that. However, generally Agile is here, it's here to stay. I think the reality is that most knowledge workers, particularly those knowledge workers dealing in complex work are going to be using some kind of Agile approach for the foreseeable future.

Nick Muldoon:

And last week you... Was it last week? I believe you were in Paris for the first face to face?

Dave West:

[foreign language 00:02:37] I was and it rained the entire time actually, Nick. So yeah, I spent a lot of time inside in Paris.

Nick Muldoon:

Well, what was the sentiment from the Scrum trainers there, from the conversations they're having?

Dave West:

Yeah, it was interesting. We talked a lot about at scale, enterprise adoption, the challenges. It is funny that the challenges are challenges that you expect, and most of them are about people, legacy systems, people status, power position. We talked a lot about the challenges that teams are getting in these large complicated organizations. That continues to be the conversation. There is, obviously, this is Europe, they're very close to Ukraine and the conflict there. So there's definitely some conversations about that. We have six Ukrainian trainers and also about the same number of Russian trainers as well. So that's always a conversation. And then there's a general downturn of the economy that was also being talked about.

Layoffs are happening throughout Europe, and particularly in the technology sector, but I think that's growing to some extent. Vodafone just announced today that they were laying off, it's about 6,000 employees, and they're one of the biggest telecommunication companies in Germany, for instance. So there was definitely some of that, but so if you add enterprise, you add conflict uncertainty, you add economic uncertainty, those three things will come together. But what was funny in it is that throughout all of this, they were incredibly upbeat and excited. And I think because they're talking to people that they've never spoken to before, they're talking to people about how Scrum is a natural way of working, talking about the challenges of empowered teams, empiricism, continuous improvement.

And I had some really exciting conversations with trainers who were like, Yeah, well we're doing this in this aerospace company or this electric car supplier in Germany or whatever, or this financial services startup that's using blockchain for the first time. And of course they're using Agile. And so it was funny. It was almost as though all of those things, though there were the backdrop, it was still incredibly positive.

Nick Muldoon:

So this is interesting, and I guess if I reflect on the background for both of you, Eric, I'm looking at, you two have worked together from rational days-

Eric Naiburg:

A few times.

Nick Muldoon:

... a few times, but the prevalence of the Agile... I would describe you two as Agile natives and it sounds like, Dave, you've got your tribe there in Paris last week that are Agile natives. And I guess Eric, for you, what's the sense around the people that you are interacting with from a leadership perspective in these companies? Can you identify the Agile natives? Yeah, I guess is it an easier conversation if you've got Agile natives in leadership levels?

Eric Naiburg:

It's definitely an easier conversation if they're there. Sometimes they're in hiding, sometimes they're not Agile natives masquerading as Agile natives as well, which always makes it a little bit difficult because you have to peel back that onion and peel through who are they and what's their real agenda. I was talking to a CIO last week, and he was talking about the typical CIO lasts two to three years. So what is their real agenda? What are they trying to achieve? And Dave mentioned the people part of this, and people often become the hardest part of any Agile transformation or working in an Agile way. People want to protect themselves, they want to protect their turf, they want to do the things that they need to do to be successful as well. So you see that as talking to leaders within organizations, and they want to do better, they want to improve, they want to deliver faster, but they've still got that pressure. Organizations, at least large organizations, haven't changed. They still have boards, and they still report to those boards, and those boards still have their agendas as well.

Nick Muldoon:

You're making me recall a conversation that I had, this is several years ago, but on a trip through Europe, and it was with the Agile native, that was the Agile practice lead and probably wasn't masking, probably was legitimately an Agile native, yet they were talking about the mixed incentives for their, maybe not their direct leader, but the VP further up. And it was actually a, I don't want to say a zero-sum game, but there was some kind of fiefdom thing going where the various VPs would fight for resources, people, whatever, because that would unlock further bonus. But at the end of the day, it was not optimizing the entire financial services company. Are we still seeing that today?

Dave West:

Oh, very much so. In fact, a colleague of ours says, "Science used to have a saying, science progresses one funeral at a time." And I think Agile definitely has some of that, not funerals hopefully, but retirements.

Nick Muldoon:

Retirements

Dave West:

Retirement.

Nick Muldoon:

Yeah.

Dave West:

Yeah. The reality is that when you don't have incentives aligned, where you don't have teams aligned to those incentives and leadership aligned to those consistent incentives, then you're going to always be dealing with some challenges. What's so frustrating is we all know the industrial revolution, and particularly the recent revolution of mass production and oil, which just happened in the deployment phase just after the second World War, was enabled by changing working practices created by people like Ford and Deming and all of these people. We all know that. The digital revolution is happening around us. It may even pass us if you believe the AI buzz that's happening. We may be put to the side and computers may just take over, but this digital is happening, and you are in with leaders and they're like, "Yeah, totally respect that. We are going to be a hundred percent digital. We are an airline, but really we are a digital company with wings."

They describe themselves in this way, and then they don't want to challenge the fundamentals of how authority, how value is managed, how risk is made transparent, how governance is, it happens, how funding is made and planning, et cetera. They don't want to challenge any of those assumptions. They like that the way it is. But we are going digital. It is ironic that it still is happening. However, that isn't totally hundred percent. The organizations that get it, the organizations that have leaders that are either insightful, either motivated, or maybe they want to write a book or something. Maybe their reasons aren't always as clear, but those leaders are dragging these organizations into the 21st century.

Great example. Proctor and Gamble, Gillette. Gillette, the latest exfoliating razor. I can see you haven't used it, unfortunately, Nick, with your rather handsome beard. So yeah. Anyway, I use it a lot, as you can tell. The exfo... Was built using Scrum and Agile. This is Proctor and Gamble, an ancient, okay not ancient, an older organization, but really has got it. They realize that if they want to keep up with their customers, their partners, their suppliers, they need to work in quite different ways. And so it isn't roses, but there are roses in the garden as it were.

Eric Naiburg:

And it goes beyond, when you think of that organization, you think of what Gillette has done, is it goes beyond traditional Agile thinking. Traditional Agile thinking, we think software, and this is engineering, this is manufacturing, this is bringing together marketing because in those types of organizations, marketing drives what the product's going to be, and then engineering figures out how to deliver that product and so on. So it's really bringing together the whole organization into how do we deliver something, and deliver it together. I think that's one of the big things that we're seeing. And one of the big changes that Agile helps to drive is that team. So you talked about incentives and team incentives, that's a piece of it, but it's team ownership. It's team togetherness.

It is that ultimately they all feel accountable, and bringing that accountability together as a team versus, and I think even... So my wife's in manufacturing and it's always... She's on the R and D side of it, and complaining about the marketing people. You have those conversations of, "Well, they don't realize what it takes to actually build this thing. They just have the dream." And by bringing them together in that team, and really they're having their daily scrums, they're planning together and they're having those hard conversations respectfully, that starts to build that team and build them in a way that they're able to actually deliver faster and more what the customer wants.

Dave West:

Can I just lean in, I'm sorry, we just taken over here a little Nick, but I just want to lean into something that Eric said around it is all about the teams. One of the fundamental problems we see in many organizations is hierarchy. Because if you get these massive hierarchies, obviously there's, "I've got to be in control of something. I need to take ownership of things. I need to be off irresponsible for certain things." That's how hierarchies work. And so that often undermines the ability of a team to effectively function. We need to flip that so that these hierarchies become, instead of being on top of the teams, they need to be underneath the teams supporting them. Think of them as those support trusses on bridges or whatever. You have some fabulous bridges in Australia and in Melbourne and in places like that and in Sydney.

So think of it upside down, holding up the teams. But that means, going back all again to incentives again, that those leaders need to understand what they're responsible for in this new world. And they're doing it for very good reason. They're doing it because the teams need to be, they're closer to the problem, they need to be empowered to make the decisions in real time based on the data, the information they have, they need to have clean line of sight to the customer. All of those things are the reason why a hierarchy is just too slow to respond and too bureaucratic. So we need to flip it and enable those teams. And that's a huge challenge.

Nick Muldoon:

I Love this. You two have given me something to ponder. So for the first six years of the company's life, of Easy Agile's life, we did have a very simple team page, and Dave and I as co-CEOs were at the bottom of the page. And then you had the leaders of the pillars. So you had, at the time, Tegan was the head of product, the leader, and they sat on top of Dave and I, and then the team sat on top of that. And it's interesting, I'm actually trying to reflect now, it's probably only in the last 12 or 18 months as we went through 40 people, that that page or that visualization has flipped. I've got an action item obviously to come out of this, thank you gentlemen, to actually go and flip it back because it's a communications mechanism, but if we actually put ourselves at the foundation in this supporting role for supporting the folks, that sets the tone, I imagine, for the team members in how they think of themselves and maybe that accountability piece as well, Eric.

Eric Naiburg:

Yeah. Yeah. That's interesting because sometimes it's those little things that change how people think and feel. I use a lot of sports analogies when I talk and meet with people, and especially with where Dave was talking of empowering the people closest to the problem. We have to do the same in sport. If we have to wait for the manager to tell us to pass the ball, it's never going to happen. We've got to allow the people to make decisions and make those decisions on the field. We need to apply that to business as well. Allow the people who are closest to the problem, closest to what's happening, make those decisions within the business as well.

Nick Muldoon:

So if we come back to Proctor and Gamble, and we don't have to rabbit hole on it, but they're one of the large, long-lived companies, and I don't know about their approach, in particular, but I think about GE, and GE had their internal training university program, and they were training their leaders, training their managers how to manage, training their leaders how to lead. How does a Proctor and Gamble go about shifting that conversation internally, and what's that timeframe? Because presumably you've start with someone that's on a team. Do you have to elevate them over time through the hierarchy of the company?

Dave West:

It is interesting. I'm fortunate to spend maybe because we're both British people living in Boston, I'm fortunate to spend quite a lot of time with, and there's videos on our site with this, by the way, interviews with Dave Ingram who runs R and D for male grooming, it's called, in the Gillette part of P and G. And the case study is out there. So I talked to him a lot about how you drive it in a huge organization where they've got everything to lose. They've got products that are amazing, they've innovated, those products are the products that you put into your shopping cart as you walk down the aisle. They don't want to muck that up. Let's be frank. If suddenly, because of some innovation, there's no razors on the shelves, then I, as a board man need a razor. So I will buy an alternate product, and it's possible that then I'll always buy that product.

So they've got to be very, very careful. They've got more to lose. So we talk a lot about how you manage change and it's all of the above. What he's done very smartly is he's empowered the product owner role or the person, the glue role, whether it's using Scrum or something else, and he's really invested in these change agents in his organization, and he's definitely led by doing, he's been very honest and open about that, and very clear that he doesn't have all the answers and he's looking for them to help him during this, which isn't perhaps what you'd expect from a traditional organization where-

Nick Muldoon:

The leader might need to feel that they have the answer to all of these questions.

Dave West:

Exactly. And he's done a really, really good job of doing that. And primarily because he says, "Well, my success is ultimately their success, so if I can make them be a little bit more successful, there's more of them than me, so let's make it work." Which I think is an unusually honest and very insightful view of it. So he's driven it predominantly through product management ownership areas. He's then provided a support environment around that. He's then definitely advertised the successes. He's spent a lot of time building cross-functional teams. The thing that Eric was talking about. And really been very careful working with their leadership. If you're material science, there's a whole department, if there's marketing, there's this whole channel thing that they have. Basically working with their leaders to create the environment for success to happen. And I don't think it's easy. I think there's many surprising roadblocks along the way, and I can't speak for him on this, but he's taken that divide and conquer approach, focusing on that catalyst role.

Nick Muldoon:

Because you, obviously, you're providing a lot of training for various, well, I guess people at various levels in these companies. And obviously it's a far cry from having a CST and a CSM and a CSPO certification going back a decade, decade and a half. What's the uptake around the leadership training? And what does that look like, Eric? Is there renewed interest in that at the moment or are people demanding more of that leadership training? Is it fit for purpose for today's leader?

Eric Naiburg:

So I think to a point it is. We're certainly seeing growth in the leadership training. Matter of fact, Dave and I were just looking at those numbers earlier this week or yesterday, I guess. Today's [inaudible 00:21:29]

Nick Muldoon:

Are there are any numbers you can share with us?

Eric Naiburg:

It's hard to share the exact numbers, but we're seeing double-digit growth in number of students taking our leadership classes. Both how do you measure, so our evidence-based management classes, as well as our leadership training, but that also only goes so far because a lot of those folks, depending on how high up, especially in the organization you go, aren't willing to take lots of time out to take such training. So a lot of it happens in that coaching. They're hiring the executive coaches or the Agile coaches that are in there. The scrum masters that are in there are actually working to help coach those folks. And a lot of it's less about the training and more about the mindset shifts. So if you look at our Agile leadership course, a large part of it is spent on getting people to think differently. And really some of it's hit you over the head type of activities, where it really helps to drive those points across of, "Wow, I need to think differently. I need to work differently. I need to treat people differently."

Nick Muldoon:

Differently.

Eric Naiburg:

It's that, and we're seeing good success with that because especially when that light bulb goes off for folks, and that light bulb that goes off saying, "Wow, this is different." We have some exercises in our classes that really get you thinking and get you... There's one, for example, where you're thinking you're doing the right thing for the customer, and you're thinking you're doing exactly right until it kills the customer, because you didn't necessarily think through the whole. It's, "Well, this is what the customer wanted, so we need to do it, but maybe I should have got together with the team and let the team make decisions." I'm going a little extreme, but-

Nick Muldoon:

No, I appreciate it.

Eric Naiburg:

... it's those sorts of things that we have to change. And a lot of what we do in the course is educate leaders on what those teams are going through, and what the individuals on those teams need, and the type of support that they need, not how do you manage those teams, not how do you manage those people. But how do you empower and enable those people to be successful?

Nick Muldoon:

I want to just rewind for a second, sorry.

Eric Naiburg:

Killing people.

Nick Muldoon:

It sounded like there's a friction point in actually getting these leaders to take the time out of the office to go and get some education.

Eric Naiburg:

There is, yes.

Nick Muldoon:

Is that correct?

Eric Naiburg:

Yeah.

Dave West:

It's incredibly hard if you're at a large organization, in particular, when your schedule is overlapping meetings continuously eight to nine hours a day for them to take that moment to step back. Everybody, I believe very strongly, Nick, that everybody needs to take time to invest in their own personal and professional development. And that time is not a waste. Ultimately it is an incredibly good investment.

Nick Muldoon:

Yes.

Dave West:

We know-

Nick Muldoon:

It's great ROI.

Dave West:

Totally. Even if it just resets you, even if you have that moment of clarity because of it. it's not a surprise that people like Bill Gates go on retreat every three to six months and he takes his big bag of books-

Nick Muldoon:

Books.

Dave West:

And he goes off grid for a few days just to reset. I think that that time is incredibly effective. But what's interesting is, we are under, in America in particular, and I'm sure it's true in Australia, it's certainly true in England, where I'm from, motion is more important than outcomes. It's all about the motions. If you look busy, you're not going to get fired. And I think to some extent we learned that in school. I don't know if your parents said to you or maybe you got your first job. I was working on a delicatessen counter at the co-op supermarket, and I remember there was an old worker there, turned to me, he goes, "Whatever you do, when the manager walks by," Mr. Short-

Nick Muldoon:

Look busy.

Dave West:

... was his name. And he was everything that name implies. "Mr. Short walks by, look like you're doing something, start cleaning something, otherwise he'll take you off and make you do provisions, and you don't want to dealing with that milk, it's rancid." And I remember that. Look busy. And I think we've got a lot in our culture. I try to take time every week. I book, for instance, my lunch hour, I book it and I always try to do something in it. I try to watch a TED talk, read something, just to clear your mind to think about something different. I think that time is incredibly important. However-

Nick Muldoon:

Get exposed to some new perspective, right?

Dave West:

Exactly. Even if it means, even if the stuff you're watching or whatever isn't that relevant necessarily. Sometimes that lack of relevance is exactly what you need because your mind does something.

Nick Muldoon:

A mental break.

Dave West:

Exactly. And however in corporate America, and I think that's corporate in general, that doesn't happen. People are overly leveraged, they're incredibly busy. They have to attend these meetings, otherwise their profile is diminished. And I think that's at the detriment of the organization and the company. Here's a question, Nick.

Nick Muldoon:

Yeah.

Dave West:

Who have you helped recently?

Nick Muldoon:

Who have I helped recently? I spend most of my time, and I get most of my energy out of coaching conversations with individuals. So on my [inaudible 00:27:35] profile, I've got futurist very high up, and so I love exploring what is your life and your career going to look like in five years time? They're the conversations that I really get jazzed by.

Dave West:

And that's what everybody... Who have you helped is more important than what have you done.

Nick Muldoon:

Yeah.

Dave West:

And I think you need to balance that.

Nick Muldoon:

I pulled up these stats because I thought you might find them interesting. We did a survey last year of a subset of our customers. And we had 423 teams. So it's not a huge sample size, but 423 teams. And the reason I think about it is because there's a lot of, what was the statistic here? So just to give you a sense, most common sprint duration is 14 or two week sprints. Most teams have six people that are involved. Fibonacci for story pointing, an estimation. 10% of these teams achieved what they set out to achieve at the start of the sprint. And so the teams, this 10% of teams, the subset, they did add work into their sprints, but teams that were unsuccessful, rolled work from sprint to sprint.

And so perhaps what it indicated to us is that there are teams that over commit and under deliver, and in fact 90% of them, 90% of the survey teams, it would appear that they over commit and under deliver. And then there are teams that are, maybe, leaving time, Dave, maybe for some education or some spare time in their two-week sprint. And they actually happen to pull on more work and they achieve that. And I'm just thinking about that from a sense of, are 90% of these teams trying to be busy or are they trying to be perceived to be busy? Even if it's at the expense of actually delivering?

Eric Naiburg:

Or are they even pushed into it? It's interesting, there's a question on our professional scrum master one, our PSM one test that often people get wrong. And I think it's a great question, which is, I'm paraphrasing because I don't remember it exactly, but it's essentially how much of the sprint backlog needs to be filled coming out of sprint planning. And a significant number of people say it needs to be complete coming out of sprint planning. Which goes in the face of Agile and Scrum.

Dave West:

Exactly.

Eric Naiburg:

Because we don't know there. There's that uncertainty. All we need is enough to get started, and once we get started, but I think people are fearful of, "Well, we've got two weeks, we need to be able to plan those two weeks and we better be able," and this is some of that top-down pressure that we talked about. "Well, we need to show that we've got two weeks worth of work here and that we're not sitting around, so let's fill it up." And those are some of the misnomers about Agile and Scrum. "Well, it's a two-week sprint, we need to plan two weeks." Well, no, we don't. We need to have a goal. Where are we going to get to? How we achieve it is going to take time because we're going to learn as we go. As a matter of fact, the scrum team that I'm on right now, we were running a three-week sprint, and two weeks in we've actually achieved our goal. And now we're able to build upon that goal. And we already delivered on that goal a week early, which is great.

Nick Muldoon:

Do you think, Eric, that there's a fear from leadership that if people haven't got two weeks worth of work teed up, that they're just going to be twiddling their thumbs?

Eric Naiburg:

I don't know that it's a fear from leadership. I think it's a perception that the workers have of what leadership is thinking. I think it's more that. And I think it's the, "Well, we said we've got two weeks," and they are going to ask us, management's going to say, "When will you deliver?" I don't know that we'll ever get away from that when will we deliver question, even though we continually try to get away from that answer. But they're going to ask it. So if they're going to ask it, I better be prepared, which means I better have a whole bunch of work laid out. And that just breaks everything that we teach. It breaks everything that we think in Agile.

And all I need in planning is I need a goal, and some idea of how I'm going to get there. And over time let's revisit it and let's continue to revisit it and go to it. But it amazes me how often that some of the answers to that question are, you have a full sprint backlog go coming out of sprint planning, you have enough to get started. I forget what some of the others are. But it amazes me how many times when I review tests people put the full back sprint backlog where it even says, right in the scrum guide, "You're going to inspect and adapt throughout the sprint." Well, how do I inspect and adapt if I've already decided what I'm going to do?

Nick Muldoon:

Who's the onus on? If it's not actually the leadership's wish that you fill up all your time and you operate at a hundred percent capacity, then is the onus on the leader to make it known or is the onus on the team to engage in the conversation?

Dave West:

It's the leader.

Eric Naiburg:

Yes.

Nick Muldoon:

Yeah. Yes, both. Yeah.

Dave West:

I think it's more the leader because I think they have to create the environment where the team actually can challenge it, and actually have that very clear conversation. What worries me about your stan is the fact that I don't... The first few sprints. Yes, maybe you get overly excited, maybe you fill the sprint, which you don't need to. Maybe you're just keen. That's okay. The thing is, what happens on sprint three or four or five, when the same pattern is manifesting itself over and over again. That's worrying. And I think that speaks really clearly to the lack of help the team's having. Whether you call it an Agile coach, and in Australia, I think the Agile manager is a phrase that's used, or whether it's an Agile, or whether it's a scrum master, whatever. Scrum.org has a scrum master.

And the reason why we have a scrum master isn't because we don't know scrum, though there's some days it might be questionable. But cobbler's children, all that stuff. But the reality is, we do know Scrum, we talk it, we breathe it, we love it. But having somebody that steps back and says, "Hang on, Westy, what have you done there? Have you forced encouraged the team to fill the sprint? Have you set them an unrealistic goal? Have you listened to them and asked them the questions? Or have you told them what you want? And what do you think that's going to do?" I know that I have, because Eric and I fund the sprints, as it were. When we go to a sprint review and we say stuff, because a sprint review is ultimately there to provide feedback to the team, to allow them to inspect and adapt for the next sprint.

You can't change the past, but you can change the future based on feedback. If I go in with, "Oh, well that's rubbish and you should do this, and what about that?" Yeah, it's going to have an impact. So ultimately we have to think about, as leaders, what we bring, and also have somebody often helping us to be the leader that we need to be because we get excited and we get enthusiastic and we get, "Oh, you can do this and that? Let's do it. That sounds awesome." And sometimes that can...

Eric Naiburg:

And that's part of why I say it's both. That's why I said the yes. It's on the leader, but the leader needs to be reminded of that. The leader needs to be supported by that, especially by the product owner and the scrum master. The product owner has to be able to say no. The product owner has to... I talk about happy ears and most CEOs and senior leaders are-

Nick Muldoon:

Happy ears?

Eric Naiburg:

Yeas. Most CEOs and senior leaders I've worked with have what I call happy ears. They come from one customer or they talk to one person and heard something that-

Dave West:

Do this.

Eric Naiburg:

... that one person might have thought was great. And next thing you know, they're putting all these new requirements on the team. And I've worked in many startups and big companies where, even at IBM, that happened. And the product owner needs to be able to say, "Whoa, hold on. That's a great idea. Let's think about it. And we'll put it on the backlog, we'll think about it later. But let's not distract the team right now from what we're trying to do and what we're trying to achieve." And that's why I say it's both. It's not just on the leader. You're not going to fully change the leader. You're not going to fully change them to not have those exciting moments. And that's what makes them entrepreneurs. That's what makes them who they are.

But the team needs to be able to push back. The leader needs to be accepting of that pushback and the scrum master and the product owner, as well as others on the team, need to be able to have that pushback. I remember very, very early in my career, I worked for a company called Logicworks. We had a data model, a little data modeling tool called Irwin. And I remember sitting in my cube, and the CEO had just come back from a meeting with one client, and comes over, and I was a product manager-

Nick Muldoon:

Eric, do this.

Eric Naiburg:

And starts talking about, we need to go do this now, and blah, blah, blah, blah, blah. It's like, well, hold on. It's like, but blah, blah, blah said they'd buy it. Well one, did you actually talk to the people using it? Or did you talk to somebody way up here who has no idea how they're actually using the tool? Which the answer was talking to CEO to CEO conversation. And just because they'll buy it, will anybody? But you have to be able to have those conversations. You have to build that trust with the leader from the team, and from the team to the leader, to be able to have those pushbacks and be able to say, "That's an interesting idea. We'll take it under consideration for the future, but right now we have a focus. We've got a sprint goal and we're not going to destroy our sprint goal because you got excited about something."

Dave West:

As you can see, Nick, I have a really hard time getting any of my ideas into our organization because they ask things like this. So annoying, Nick. They say, "Okay, that's great. Is that more important than these five things that are currently driving our product goal?" I'm like, "Ugh, what do you mean? I can't have dessert and main course and an appetizer? I have to pick one that's just so not fair." And they said, "Well, we could spin up another team and then that requires investment. It's going to take time." And I'm like, "Oh gosh, don't you hate it when you have intelligent, smart teammates?" It's just hard.

Nick Muldoon:

Dave and I have definitely, so Dave Elkin, my co-founder, he comes from an engineering background and I come from a product background. And we've definitely noticed in the last, again, probably in this timeframe, in the last 18 months, as the team's grown or through a certain inflection point, in the past, we would quite come comfortably have conversations about what about this idea and how about that? And we'd try and tease things out, and we'd tease them out with the team, but there was no expectation that that stuff would get picked up. And then we had few examples where teams would go and take on and think that they needed to look at this stuff and we're like, "Oh, no, no, no, sorry, we should clarify that we just wanted to get a brainstorm or we wanted to get a thought out of our head, and we wanted some perspective on it, but this should absolutely not mean that you should chase it down." And so the language and how we've had to approach things like that, or activities like that, has certainly changed.

Eric Naiburg:

I've seen that a lot lately-

Nick Muldoon:

[inaudible 00:39:50] Inflection point.

Eric Naiburg:

... probably in the last two or so years. And I think maybe because of remote, it's made it even worse, because you don't get all the emotion and things. But I've definitely seen a lot more of that, of, "Well, I'm just," I've been told this doesn't translate, "but I'm just spit balling and I'm just throwing an idea out there just to have a conversation." And because the leader said it, people think it's fact and that they want to do it. And all they were doing is, "Hey, I heard this thing. What do you think?"

Nick Muldoon:

What's your perspective?

Eric Naiburg:

Yeah, exactly. And I think as leaders, we have to be very careful to understand the impact of what we're saying, because we may be thinking of it as, "I'm just throwing it out there for some conversation." Somebody sitting at the desk just heard, "Oh, they want us to go do that." And I've seen that a lot in companies recently, including in ours, where the way something's said or what is said is taken on as we must do this versus, "Hey, here's an idea, something to noodle on it." So you're not alone, Nick.

Nick Muldoon:

I love it. Hey, Eric, Oregon, that's a great place to call it. That is, and you have given me, you've both given me a lot to noodle on, so I'd like to say thank you so much from our listeners and from the crew at Easy Agile for joining us today. I really appreciate it. It's been wonderful having you on the podcast.

Dave West:

Well, thank you for inviting us. We're really grateful to be here, and hopefully some of this has made sense, and yeah, let's continue to grow as a community and as a world working in this way, because I think we've got a lot of problems to solve. I think the way we do that is people working effectively in empowered ways. So let's change the world, man.

Nick Muldoon:

I love it. Okay, that's great. Thank you.

"It was a pleasure speaking with Ray about empowering teams and helping people reach their full potential" - Mat Lawrence

Mat Lawrence, Chief Operating Officer at Easy Agile is joined by Ray Arell. Ray currently works as the Director of Agile Transformations at Dell Technologies, is the host of the ACN Podcast, and the President Of The Board Of Directors for the nonprofit Forest Grove Foundation Inc.

Ray is passionate about collaborative and inclusive leadership, and loves to inspire and motivate others to achieve their full potential. This is exactly what Mat and Ray dive into in this episode.

Ray and Mat explore the concepts such as inclusive and situational leadership and the connection to agile ways of working, empowering the organisational brain, and fostering authenticity within teams.

This is a fantastic episode for aspiring, emerging and existing leaders! Lots of great tips and advice to share with colleagues and friends and understand the ways we can be empowering and enabling one another.

We hope you enjoy the episode!

Transcript:

Mat Lawrence:

Hi folks, it's Mat Lawrence here. I'm the COO at Easy Agile and I'm really excited today to be joined by Ray Arell. Before we jump into our podcast episode, Easy Agile would like to acknowledge the traditional custodians of the land from which we're broadcasting today, the people of the Gadigal-speaking country. We pay our respects to elders past, present, and emerging, and extend that same respect to all Aboriginal Torres Strait Islander and First Nations people joining us today. Ray, thanks for joining us today. Ray is a collaborative and inclusive leader who loves to inspire and motivate others to achieve their full potential. Ray has 30 years of experience building and leading outstanding multinational teams in Fortune 100 companies, nonprofits, and startups. Also, he's recognized as a leading expert in large-scale agile adoptions, engineering practices, lean and complex adaptive systems. So Ray, welcome, really good to have you on the podcast today.

Ray Arell:

Thank you.

Mat Lawrence:

Love to get started by understanding what you enjoy most about being an inclusive leader and working with teams.

Ray Arell:

Yeah, so I've been in leadership probably for about 15 years, leading teams at different sizes. When you have the more intimate, smaller teams of maybe five or six people, upwards of teams that are upwards of several hundred people working within an organization that I might be the leader of. And what I enjoy the most about it is just connecting with the talented people that do the work. I mean, when you go into leadership, one of the things that you kind of transition from is not being the expert person in the room that's coding or doing hardware development or something else. You have these people who are now looking for direction or vision or other things in order for them to give them purpose in order to move forward with their day.

And I enjoy coaching. I enjoy mentoring. I mean, a lot of my technical side of me is more nostalgia now more than it is relevant with the latest technologies. There's something rewarding when you see somebody who can, if you think of Daniel Pink's work of autonomy, mastery and purpose, that they suddenly find that they are engaged with the purpose that we're doing as an organization and then the autonomy for them to just do their day and be able to work and collaborate with others. And that's always been exciting to me.

Mat Lawrence:

I can relate to that. Yeah. I think in our audience today we're going to have a mixture of emerging leaders, aspiring leaders, and experienced leaders. I'd love to tap into your experience and ideally rewind a little bit to earlier in your career when you were transitioning into being a leader. And I'd love to understand around that time, what were some of the successes that you saw in the approach that you take that you've been trying to repeat over the years?

Ray Arell:

Well, I think early on, I think, especially when you grow up through the technical ranks, and suddenly at least the company that I was with at the time, very expert-based culture, if you were the smartest person in the room, those are the people that they looked at and said, "Okay, we're going to promote you to lead, or we're going to promote you to manager or promote you into the leadership ranks." I think looking back on that, I think Ray 2.0 or Ray 3.0, whatever version I was at the time, that I very much led from that expert leadership stance, which is sort of I know what is the best way to go and approach the delivery of something, and everyone should be following my technical lead for however this product comes together.

And I don't think that was really a good approach. I think that constrained people because you ended up being more or less just telling people what to go do versus allowing them to experiment and learn and grow themselves in order to become what I had become as a senior technical person. And so I think lesson learned number one was that leading a team from an expert slant I think is probably not the best approach in order if you're going... especially if you think of agile and other more inclusive teamwork type of projects, you're going to want to give people more of a catalytic or a catalyst leader type of synergistic-based leadership style so that they can self-organize and they can move forward and learn and grow as an engineer.

Mat Lawrence:

Are there any times that stand out for you where you got it horribly wrong? I know I've got a few stories which I can happily share as well.

Ray Arell:

I'd love to hear some of yours. I think horribly wrong I think is... The question is is anything ever really not fixable, not recoverable? And in most cases, most of the issues that we've dealt with were recoverable. I think that looking at, and again, kind of back into that stance of well, am I creating a team or am I creating just a group of individuals that are just taking their work from the manager and I'm passing them out like cards type of thing... I think early on, probably the big mistake was just being too controlling, and the mistake of that control meant that I couldn't have a vacation. Others were dependent versus being interdependent on one another. And I think that made the organization run slower and not as efficient as it could be.

Mat Lawrence:

I've certainly been guilty of that same approach earlier in my leadership career where I became the bottleneck, absolutely.

Ray Arell:

Yeah. Exactly.

Mat Lawrence:

And to recognize that, it can be quite hard to undo, but it's definitely worth persevering with. Something else that I was fortunate to get some training in situational leadership, oh, probably nearly 10 years ago now. And that really opened my eyes to an approach, the way I was treating different people in my team. But I was treating them the way I first judged them. So if I saw [inaudible 00:07:01] an expert and a master, I would treat them as an expert and a master in all things. And [inaudible 00:07:05] if someone was less capable at that point in their career, I'd kind of assume the same thing. And so I would apply the same level of direction or lack of direction to those people for everything. And in situational leadership, the premise for those who don't know at home, is you change the level of direction that you give depending on the task at hand. Have you used that approach or something similar to guide how you include people in different ways?

Ray Arell:

Well, in order to include people, I think part of it is you need to... As you said, you were situationally looking at each person, and you were structuring it in a way that was from a way, an approach, of very individualized with somebody. I think the philosophy that I... Not everyone is very open or can communicate very well about their skills and their strengths, or in certain cases some people, they might be good at something but they don't exercise it because they themselves feel that that's not one of their strengths, but in reality is it is. So I think that when you're saying from a situational leadership perspective, when you hear somebody place doubt that they could be the one that could do something or to take up, say, even leadership of something, I think part of that just gets into that whole coaching and mentoring and really setting it up and helping them to be successful through that.

And I think from an inclusive perspective, I think there's a set of honesty that you have to bring into your work and humility about being humble about even what you've accomplished. Because in engineering in particular, you tend to see that when you put people into a room, the people who are newer will sit back, and they will yield to who they think has the more experience. And reality is that they came from, say, let's say they just got fresh out of college. They actually might have more skills in a particular area based upon what they just went through in their curriculum that we might not have. And so the question of how do we use the whole organizational brain in order to bring all of the ideas onto the table, I think at times it requires us to be able to be effective listeners and to sometimes just pause and allow people to have the floor and pick up the pen and not hog the space, if that makes sense.

Mat Lawrence:

It really does, and I think I've seen that in every company I've worked in to some level. I'd be really interested to tap into how you go about addressing that scenario. For the people who are listening that would face that situation, it might be the first time they've been a leader and seeing that scenario and observing it. Is there any advice you would give them to help change that dynamic?

Ray Arell:

Well, one, just becoming aware of it. I frequently doodle when I'm in a group of people, and what I'll do is I'll sit there and I'll put dots on a paper of where people are at in the room, and then I start drawing lines between those individual dots if I see the communication happening between certain players. And what's interesting is if you watch that over about a 15-minute period of time, you start to see this emergent pattern that maybe someone's domineering the conversation or they're the focus point of the conversation, and it isn't going around the full room. So then that's when you get to be a gatekeeper and you invite others into the conversation. And then you politely help the ones who are being dominant in the conversation to pause, to just give space and allow those other people to talk and to get that out.

And then I think the question of whether or not what the person says may sometimes be coherent or not coherent to the conversation, or maybe they're still trying to learn about just dynamics of everything. You just have to help to get, sometimes, to get that out of people, and use open words to basically open sentence... I mean, some open questions to pull that out from them. And I think that works really well.

Mat Lawrence:

I love that. I'm a doodler as well. I'm an artist originally in my early career, and I've worked my way into solving problems through tech a long time ago now, but I still can't... I need that physical drawing to help my mind think as much as anything else [inaudible 00:12:30] than just doodling on a pad.

Ray Arell:

Same here.

Mat Lawrence:

Something that you said a little earlier, we touched a little bit on inclusivity. In your LinkedIn bio you talk about being an inclusive leader who loves to inspire and motivate others to achieve their full potential. Something I'm really passionate about is that last part in particular, is helping people achieve their full potential. It's why I love being a people leader and a COO. You get to do that across a whole company. I'd love to first touch on the idea of being an inclusive leader. How do you define what it means to be one?

Ray Arell:

Well, inclusive leadership, there was an old bag that I used to have, a little coaching bag that I used to carry around with me. And at the very top of it said, "Take it to the team," was the motto that was at the top of it. And at the bottom of the bag it basically said, "Treat people like adults." Were the two kind of core things that I think part of what being inclusive is is that I have to accept the fact that, yeah, I'm a smart person, but do we get a better decision if we socialize that around the team? Do we see what other ideas or possibility thinking? Sort of in the lean sense, make the decision as late as you can.

It's more towards the Eastern culture of, well, if I keep the decision open, maybe we're going to find something that's cheaper or better or even just more exciting for our customers. And so I think part of that is knowing that you don't have to be the one that has to make the decision. You can let the team make the decision. And we all embrace because we're empowering ourselves with this was what we all thought, not just what Ray thought, which I think is cool.

Mat Lawrence:

There's a second part to that piece you talked about in your bio around helping motivate others to achieve their full potential.

Ray Arell:

Yeah, yeah.

Mat Lawrence:

Yeah. Let's talk about where that came from for you, that passion, and what are some of the ways you look to help emerging leaders reach their full potential?

Ray Arell:

Yeah, I mean, I was lucky enough when I joined Intel Corporation that Andy Grove was still running the organization at the time. As a matter of fact, he taught my Welcome to Intel class. At the time when I joined Intel, there was only about 32,000 employees. And here's the CEO, founder of the company teaching the Welcome to Intel class, which I thought was incredibly cool, a great experience to have. He oozed this leadership, whatever mojo or whatever it is he is got going out into the environment as he's talking about the company. But he was really strong on the one-on-ones, the time that you can spend with your manager or others within the organization because you can have a one-on-one with anyone within the company. And he encouraged that. And I think that helps to... When somebody is trying to figure it out, they're brand new to the company, and you get a standing invitation from the CEO that says, "You can come and have a conversation with me," I think that sets the cultural norm right up front that this is a place that's going to assist and help me along my career.

And I could tell you that there's been a number of different times that those developed into full-blown, "I'm the mentee and they're the mentors." And in those relationships over time, it's sort of like then you say, "Well, I'm going to pay that forward." Today I have at least six or seven mentees that have all sorts of questions about how do they guide through their career or if they had some specific area that they wanted to go focus on. And it's their time to pick my brain. And in certain cases, if I don't have the full answer, I can guide them to other mentors that can help them to grow.

Mat Lawrence:

I love that approach of pay it forward that you touched on there. It's definitely something that I've been trying to do in the last couple of years myself, and I wish I'd started sooner mentoring. I've had the privilege of working with some amazing leaders in my career who I've learned a lot from. And once I started mentoring, I realized how much I learned by being a mentor because you have to think. You really think about what these people are going through and not just project yourself onto them. And it validates the rationale about why you do things yourself, why you think that way. And it forces me to challenge myself.

And I think if there's anything... I talk to some of the younger people at work who are emerging leaders, and they're exceptional in their own way. They've all got very different backgrounds, but a lot of them don't feel like they're ready to be a mentor. They really are. They're amazing people. And I wonder, have you seen people earlier in their careers try and pass it forwards kind of early on or do people feel they have to wait until [inaudible 00:18:22]?

Ray Arell:

I think it depends. One, I think the education system, at least in the United States, has shifted a bit. When people go for their undergraduate degree, it used to be just they were by themselves, they did their book studies. Very little interaction or teamwork was created for this study. I mean, back when I got my electrical engineering degree, it was just me by myself. There might be occasional lab work and lab projects, but it wasn't something that was very much inclusive, nor did they have people step up into leadership roles that early. I look at now my daughter who's right now going to the university, and everything is a cohort group. There's cohorts that are getting together. The studying that they do, they each have to pick up leadership in some regards for some aspect of a project that they're working on. So I think some of the newer people coming into the workforce are sort of built in with the skills to, if they need to take up leadership with something, run a little program, run a project, they've been equipped to do it. At least that's what I've seen.

Mat Lawrence:

I love that concept. Something that I've been observing and I talk it about a lot with our leadership team and our mentor exec teams for the [inaudible 00:19:56] as well. A lot of the conversation that comes up is around team dynamics, team trust, agility within teams, and to generally try and empower teams, set them up so they can be autonomous, they are truly empowered and they're trusted to make great decisions and drive work forwards. You've got a lot of experience in agile and agile [inaudible 00:20:21] agile leader. In your experience leading agile teams, those adoptions and those transformations, I'd love to understand if you see there's a connection between being agile as a team and those traits that an inclusive leader will have. Is there a connection there in your mind between what it means to be agile and be an inclusive leader?

Ray Arell:

I think so. Because if you think of early on, they established that servant leadership was a better leadership style for agile teams. And so I think when we talk about transformation, some of the biggest failures that occur tend to be more based upon not agile, but on issues of trust and other sort of organizational impediments that had already existed there before they got started. And if they don't address those, their agile journey is painful.

I've heard people say that they've gotten Scrummed before, using it in a really kind of derogatory way of thinking that, well, instead of getting a team of empowered people to go do work within the Scrum framework, they end up being put under a micromanagement lens because the culture of the manager didn't shift, and the manager is using it as a daily way to making sure that everyone is working at 120% versus what we should be seeing in the pattern is that the team understands their flow. They're pulling work into the team. It's not being pushed. And those dynamics I think are something that if leadership doesn't shift and change the way that they work, then it just doesn't work in organizations.

Mat Lawrence:

In the many places that you've worked and coached and guided people on, you've started to come across... There's a term that we've started to use of agile natives where people who've really not known any different because so many companies in world are going through agile transformations, and that'll continue for a long time. But as some companies are born with agility at the forefront, have you experienced many people coming through into leadership roles that don't know anything but true agility and really authentic agility as you've just described?

Ray Arell:

Well, I think it's kind of interesting because as you talked about that phrase, I was thinking about it, about, well, if you knew nothing else... But I can also say that you could become native after you've been in the culture for a period of time as well. So you can eventually... That becomes your first reaction, your first habit is pulling more from the agile principles than you would be pulling from something else. Yeah, there are those people, but it's been interesting watching companies like Spotify or watching Salesforce or watching Pivotal, and I can just go down the list of companies that have started as an agile organization, they got large, and then suddenly the anti-patterns of a large company start to emerge within those companies. So even though the people within the smaller tribe are working in an agile way, the company slowly doesn't start to work in an agile way any longer. It falls underneath a larger context of what we see happening with the older companies.

And I think some of that could be the executive culture might be just coming in where they bring somebody from the outside who wasn't a native, and they have a hard time dealing with the notion that, well, we're committing to a delivery date sometime over here, and we think we're going to hit it. But no, we don't have what would be affectionately known as a 90% confident plan that says that we've cleared all risk out of the way. And yeah, it's going to absolutely happen on that day. And some of those companies get really... They feel that they have to commit everything to the street, and if they don't meet it, they've already glued those in to some executive bonus program, ends up driving bad behaviors, unfortunately,

Mat Lawrence:

Yes, I have been there. I'm assuming that in our audience, we're going to have people who are transitioning into more senior leadership roles. They're not emerging leaders, they've been doing it for a while, and they've probably run some successful agile teams at the smaller level as you've described. For those people who are moving into the more senior roles, maybe into exec positions, is there any guidance that you'd give them for navigating that change and trying to maintain, through agile principles and what it means to be agile, in those more senior roles?

Ray Arell:

Yeah, I think part of it is the work that you did as a smaller team, everything still can scale up. And I hate to use the word scale because I think scale is kind of... People kind of use it... What would be the right word? It's misused in our industry. I think values and principles are scale-free. You can still walk each day walking into your team and still embracing those 12 principles, and you're going to do good work. The question is though, is if you're doing that at the lower level, say with a Kanban board, the question is, what does it look like when you're at your executive desk? What is the method that you go pool? If you look at most of the scaled frameworks that are out today, there's very little guidance that's given to what should be in the day in the life of an agile executive. What should that look like?

And for me, if I think about the business team, the management team is working with the delivery teams daily. They should be doing that. So what are you going to put in place for that to facilitate and occur? What are you going to do about... stop doing these big annual budget processes. Embrace things like the beyond budgeting or other things where you're funding the organization strategically, and you're not trying to lock everything in on an annual cadence, but yet your organization beneath is working every two weeks. So you should be able to re-move your bets with any organization based upon the performance of each sprint. Can you do that?

The last one is probably the most important one, is impediments. And that is how fast does it take information to go from the lowest part of the organization to the highest point of the organization? And if that takes three weeks, two weeks, or even sometimes later for certain organizations, optimize that. How do you optimize an impediment that you can personally help to go remove for people so that they're not slowed down by it any longer, whatever that might be?

Mat Lawrence:

You're touching on something there, which I think is a fundamental part of being agile, which is that ability to learn and adapt, and you can only learn when you are aware of what's happening around you, you can observe [inaudible 00:28:39] to it.

Ray Arell:

Well, I said something a couple months ago, and everyone just went, "Why did you say... I can't believe you said that out loud." It's the quiet stuff out loud sometimes. [inaudible 00:28:53]. We were trying to get a meeting together to go fix one of these impediments, and all the senior leaderships was busy. They were busy. And my question was is if this isn't the most important thing right now for us, what do you do? Really, are you doing in your day if this one isn't the highest priority that you walk into? And the questioning senior leaders that maybe they're not paying attention to the right things, and sometimes speaking that truth to power is something we have to do every once in a while.

Mat Lawrence:

I agree. That level of candor is definitely required at all levels and being able to receive that feedback so you can learn and adapt as an individual, as we were talking about earlier, about being adaptive as a leader, but also as a team. There's a point that I'd like to touch on before we wrap up, which is as you climb up the career ladder and you get into a more senior position, and then you become responsible for a broader range of things, particularly as you start reaching that executive level, I've witnessed people struggle with the transition from being the person, as you talked about right at the start of this discussion, being that person who knows everything and who can direct and have all the answers into someone where I see your job changes to being the person who can identify what we know least about, what we as an exec team know least, where we're... have the least confidence, where we see the impediments and we don't know what to do with them.

How do you go about guiding people to embrace that? Because I think what I see is the fear that comes with that, almost a fear of exposure of, "Oh, I'm admitting to people I don't know what I'm doing." And I've been rewarded through my entire career by becoming more of an expert, and suddenly my job is to be the person who's confident enough to call out, this is what we don't understand yet. Let's get together and try and resolve it. When the risk is greater, the impact is greater, and you're responsible for more things, how do you help people transition into that higher-level role?

Ray Arell:

Well, I think part of it is can they let go of that technical side, having to have their hands dirty all the time? And I've seen certain leaders that, really, somebody needs to go back and say, "Are you really sure that this is the career that you're wanting to go to? You seem to be more into wanting to be into the nuts and bolts of things, and maybe that's the best place for you because you feel more comfortable in that space." The other aspect though, as they transition, I think is again, trust becomes critical. Trust the people that are working for you, that they're not coming in and being lazy and you have to go look over their shoulders all the time because you feel that they might not be being productive or other things. You have to have the ability to say that, look, that the people that you hired are talented, and they are moving us towards our goals.

I think what becomes more critical for the health of the organization is that you have to do a much better job at actually saying, "Okay, well, here is our vision," whether it be a product vision, whether it be the company's vision, whatever that might be, helping people to understand what that North Star is, and then reinforcing that not from a perspective of yourself, but a perspective from the customer. And I think this is where a lot of companies start to drift because they start to optimize some internal metric that, yeah, that'll build efficiency within your organization. But what does the customer think? And constantly being able to represent as, if you think of from an agile perspective, the chief product owner of the organization, to be able to represent this is what the customers need and want and to be able to voice that in the vision and the ambitious missions that are set up for the organization. Make it real for people.

And then the last part of that is not everything is going to happen and come true. If you read most executives' bios, there's lots and lots and lots and lots of mistakes. And I remember this of one leader, he was retiring. And I thought this wasn't most awkward time that he actually did this. He actually went up on the stage and he talked about his biggest failure. Now, throughout my career working with this person, I always wondered whether or not they were human. And then on the day of this person's exit, they finally decided to give you a few stories about mistakes that they made. And I think that he really needed to share those stories much, much earlier because I think people would've probably found... They would've been a little stressed working around him. And it would also show some vulnerability for you as a leader to say that you don't have everything figured out, and sometimes it's just a guess. We think that this is where the product needs to go.

And then as soon as you put it in front of the customers, they're going to tell you whether or not... If you take the Cano model and suddenly you're going to hit this is the most exciting thing since sliced bread, are they going to love it or are they going to go, [inaudible 00:35:12]. I'll take it if it's free. You get into this situation where it's like, well, we can't charge as much. But I think those stories become important and anchor organizations. One other aspect of this is I think that by having somebody who's approachable and can relay those stories effectively into the organization and talk about these things, I think then that opens the door for everyone else to do it as well. Because like it or not, humans are hierarchical in the way that we think about things. A lot of people manage up, so they mimic leaders. So be that leader that somebody would want to mimic.

Mat Lawrence:

I think that's great advice, Ray. The connection for me that's run through this whole conversation is around engaging with your work authentically, whether it's the team that you're trying to lead, whether it's the agile practices at whatever scale and level that you're operating at. And to build that trust to enable that to work requires that level of authenticity.

Ray Arell:

Yeah, exactly.

Mat Lawrence:

I would love, as we wrap up, for you to leave any final tips or advice for both current and emerging leaders on that topic. If there's a way beyond just sharing your own personal stories, how would you advise people? What would you leave them with to build some trust in their teams?

Ray Arell:

Well, a couple of things. Number one, you have to be mindful about who you are as a person. Again, like I was saying, that people manage up. And if you send out an email at three o'clock in the morning, and five minutes later your people were responding to you, then you're not being a really good role model of a good work-life balance. So a lot of your tendencies will bleed off into the organization. So regardless how you assess yourself, do an assessment of your leadership, where you think it is. Harvard Business Review, a long time ago, put off the levels of what they saw as leadership models. And the lowest level is the expert and the achiever-based leaders. And if you're one of those, those are not very conducive to a good agile or collaborative culture. So if you're currently setting in that slant, then you should look ways of being able to move yourself more to a catalytic or a synergistic-based leader.

And that journey's not an easy one because I went through that myself. It took years in order to pull away from some of those tendencies that you had as an expert leader. And as an example, an expert-based leader tends to only talk to other experts. If they perceive somebody not to be an expert of something, they tend to discount those individuals and not engage with them. And so again, the full organizational brain is what's going to solve the problem. So how do you engage the entire organization and pull those ideas together?

The other one is that as you go into, from an emergent leader perspective, I think you said it yourself earlier, and that's not just the bias of you're not an expert, I'm not going to talk to you, but any bias that you might have can affect the way that you lead and judge an individual, and really could limit or grow their career based upon maybe a snap judgment that you might have had. So I think you have to be mindful of your decisions that you're taking within the organization and especially the ones you're making of people. And so you got to be careful of those.

The last one is probably just... And this gets into the complex adaptive systems space. Not everything is cut and dry, black and white, or mechanistic, meaning that we can take the same product, redo it again and again and again, and we're going to get different answers. We're going to get different requirements. We're going to get different things. It's okay for that stuff to be there. And it's okay for the stuff that's coming out of our products to be different every once in a while, and specifically because everything, it's a very complex environment. Cause and effect relationships and complexity is, customer can change their mind, and we have to be comfortable with a customer changing their mind. Our customer might have new needs that come up.

And likewise, our employees, they sometimes will have change of thought or change of what they are excited about. How do you encourage that? How do you grow those individuals to retain them in the company, not to use them for the skill they have right now, but how do you play the long game there? And I know I'm getting a little long-winded here, but the thing that I see most, even with all the layoff notices that are going on right now, is that that company's not playing the long game. I think that's a bad move because all you're doing by letting an employee go is enabling your competitor with a whole bunch of knowledge that you should be retaining. So anyway, I'll cut it short there.

Mat Lawrence:

Right. Thank you for sharing your wisdom with us today. It's been an absolute pleasure. I've really enjoyed the chat. So yes, thank you for joining me on the Easy Agile Podcast.

Ray Arell:

Awesome. Thank you for having me.

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