Easy Agile Podcast Ep.22 The Scaled Agile Framework

TL;DR

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

Introduction

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

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

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

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

About Our Guest

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

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

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

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

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

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

Transcript

Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"Okay, alright. And then what?"

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

"And then what?"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Navigating Conflicting Forces - Outcomes vs. Predictability

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

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

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

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

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

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

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

"Because we have to increase mobile revenue."

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

The Power of Renaming Teams

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

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

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

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

Prove the Model

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

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

Team Autonomy and Empowerment

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

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

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

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

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

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

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

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

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

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

The Two-Way Solution

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

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

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

Demand Proactive Transparency

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"Why is it difficult?"

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

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

"Well, because we have a sales team."

"Why does that make it difficult?"

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

"Okay, now I understand."

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

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

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

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

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

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

---

‍

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

‍

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

"Really enjoyed my conversation with William and Riz, I'm looking forward to implementing their recommendations with our team" - Angad Sethi

In this epsiode I spoke with William Rojas and Rizwan Hasan from Adaptavist about the ways we can enable high performing agile teams:

• The significance of team alignment
• When and where you should be using tools to assist with your team objectives
• Prioritizing what conversations you need to be apart of
• Advice for remote teams

Subscribe/Listen on your favorite podcasting app.

Thanks William & Rizwan!

Transcript

Angad Sethi:

Good afternoon/evening/morning everyone. How you guys going?

Rizwan Hasan:

Oh, good. Thanks Angad.

William Rojas:

Yeah. How are you?

Angad Sethi:

Yeah, really good. Really, really stoked to be having a chat with you guys. Should we start by introducing ourselves? Riz, would you like to take it?

Rizwan Hasan:

Sure. My name's Riz Hasan, I'm based in Brussels, Belgium. Very newly based here, actually used to be based in New York, not too far from William. We usually used to work together on the same team. My role here at Adaptavist is I'm a team lead for our consulting group in EMEA. So in the European region and in the UK. So day to day for me is a lot of internal management, but also working with customers and my consultants on how our customers are scaling agile and helping them with tool problems, process problems, people problems, all the above.

Angad Sethi:

Yeah. Yeah. Sounds awesome.

William Rojas:

As for myself, William Rojas. I'm actually based out of a little suburban town called Trumble in Connecticut, which is about an hour plus northeast of New York, basically. And as Rez mentioned, yeah, we've worked for a number of years we've worked together, we were running a agile transformation and scaling adoption team for Adaptavist. My new role now is actually I took on a presales principle, basically a presale principle consultant these days. It's actually a new role within Adaptavist, and what we do is we have, actually all of us, I think most of us are all like ex-consultants that support the pre-sales process, and work in between the sales team, and the delivery team, and all the other teams that support our clients at Adaptavist.

Angad Sethi:

Awesome, awesome.

William Rojas:

I help find to solutions for clients and make the proposals and support them through, get them on through delivery.

Angad Sethi:

I'm Angad, I'm a software developer and I'm working on Easy Agile programs and Easy Agile roadmaps, two of the products we offer for the Atlassian marketplace. We're super excited to speak to you guys about how your teams are operating in, like what's a day to day. Riz, would you like to answer that?

Rizwan Hasan:

Sure. Yeah. So apart from like the internal management stuff, I think what's particular to this conversation is how we walk clients through how to navigate planning at scale, right?

Angad Sethi:

Yeah.

Rizwan Hasan:

I'm working with a client right now who's based in the states, but they're acquiring other software companies left and right. Which I think is also a trend that's happening within this SaaS ecosystem. And when that happens, they're trying to bring all that work in together. So we're talking through ways of how to visualize all that in an easy way that isn't really too much upfront heavy with identifying requirements or understanding what systems we want to pull in, but more so what do you want to pull in? So really right now, in this phase of the data that I'm working with this client, it's really just those initial conversations about what are you planning? What are you doing? What's important to you? So it's a lot of these conversations about that.

Angad Sethi:

And so you mentioned it's a lot of internal management. Are some of your clients fellow workmates, or are they external clients?

Rizwan Hasan:

They're mostly internal because I manage a team, so I have different people who are working on different types of projects where they might be doing cloud migrations. They might be doing some scripting work. In terms of services, we cover everything within the Atlassian ecosystem, whether it be business related, process related, tool related. So it's a big mix of stuff at all times.

Angad Sethi:

Cool. And is it usually like you're speaking to all the team leads, and giving them advice on agile ceremonies, and pushing work through pipelines and stuff?

Rizwan Hasan:

Yeah, actually, so a story of when I first moved to Brussels, because we've... So professional services started at Adaptavist in the UK, and this was maybe like seven-eight years ago, and it's expanded and myself and William were part of like the first group of consultants who were in North America. That expanded really quickly, and now that we're in EMEA, it's almost like a different entity. It's a different way of working, and a lot of leadership has moved over to North America, so there's new systems and processes and ceremonies and then all that's happening. But because of time zones there's a conflict.

So what I started to do when we got here was to reintroduce some of those habits and consistent conversations to have, to really be much more on a better planning cadence. So interacting with people who would be, say, bringing work to delivery in presale. So folks who are, who work similar to William's capacity over here in this region, and then also project managers who would be responsible for managing that work. Right? So on the equivalent of like a scrum master on an engagement or like an RTE on a big engagement. Right?

Angad Sethi:

Yep. Yep. That's awesome. Just one thing I really liked was your terminology. You used conversations over ceremonies or speaks about the agile mindset in that sense, where you're not just pushing ceremonies on teams, where you actually embody being agile. Well, I'm assuming you are from your conversation, but I guess we'll unpack that. What about you, William? What's your [crosstalk 00:06:32]

William Rojas:

I was going to say, one of the things that's interesting challenge that we face, because Adaptavist has an entire branch that does product development and there are product developers, and product managers, and product marketing, and all sorts of things like that. And they set plans and they focus, deliver and so forth, as you would expect a normal product organization to do. On the consulting side, one of the things that's very interesting is that a lot of our, like we have to answer to two bosses, right? Like our clients come in and say, "Hey, we need this," and we have to support them. In the meantime, we have a lot of internal projects, internal procedures and processes and things that we want do as a company, as a practice, but at the same time, we still need to answer to our clients.

Angad Sethi:

I see.

William Rojas:

So that's actually one of the interesting challenges that from an agile perspective, we're constantly facing having to balance out between sometimes conflicting priorities. And that is definitely something that, and although consulting teams at different levels face this challenge. Right?

Angad Sethi:

Yeah.

William Rojas:

So as Riz mentioned, we're constantly bringing in more work and like, "Okay, we need you to now adjust and re-plan to do something different, then manage." Yes. It's an ongoing problem that's just part of this part of this world kind of thing.

Angad Sethi:

Yeah. Okay. I see. And so if I heard that correctly, so it's, I guess you're constantly recommending agile processes, but you may not necessarily get to practice it?

William Rojas:

But more so we're both practicing for ourselves as well as trying to tell our clients to practice it or trying to adjust.

Angad Sethi:

I see, yeah.

William Rojas:

You know, a client comes in with needs and says, "Okay, now we have to re-plan or teach them how to do it, or re-accommodate their new emerging priorities as well." So we ultimately end up having to practice agile with and for our clients, as well as for ourselves. It's that constant rebalancing of having to weave in client needs into internal needs, and then the constant re-priority that may come as a result of that.

Angad Sethi:

Yeah.

William Rojas:

And then we're constantly looking for like, how do we make this thing more efficient, more effective? How do we really be lean about how we do the work and so forth? That is definitely one thing that we practice. We try to practice that on a daily basis.

Angad Sethi:

Yeah. And I guess that's a very, a tricky space to be... not a tricky space. It can be tricky, I guess, but adding to the trickiness is remote work. Do you guys have a lot of clients who have transitioned to remote work? And I don't know, has it, has it bought to light problems, which can be a good thing, or like what's your experience been?

William Rojas:

So that's interesting because so I've been doing consulting for over a couple decades, and traditionally, so I've done a lot of that, that travel warrior, every week you go travel to the client to do your work, you travel back and you do that again next week, and you do that month after month. In coming to Adaptavist, Adaptavist has historically always been a remote consulting company. So five years ago it was like, wow, we would go to clients saying like, "Okay, we need you to do this." And we're like, "Yeah, we can deliver that. And no, we don't need to, you know. We may come in and do a onsite visit to introduce ourselves, but we can deliver all this work remotely." So we've always had that history.

Angad Sethi:

Okay.

William Rojas:

But nonetheless, when COVID hit and everybody went remote, we definitely experienced a whole new set of companies were now suddenly having to work remotely, and having to establish new processes and practices that basically forced them to be remote. And I think we've had the fortune of in a sense, having always been-

Angad Sethi:

Yep, remote start.

William Rojas:

... S8's.

Angad Sethi:

Yeah.

William Rojas:

I know whenever we bring on people into the company, into consulting particular, that's one of the things we always point out. Remote work is not the same as being in the office. It has its ups and downs. But we've always had that benefit. I think we've been able to assist some of our clients, like, This is how this is how it's done, this is how we do it." So we've been able to teach by example type of thing for some of the clients.

Angad Sethi:

There you go.

William Rojas:

Yeah.

Angad Sethi:

Awesome. That was actually going to be my next question is what's the working structure at Adaptavist and what sort of processes? I'm sure that it's a big company and therefore there'd be tools and processes particular to teams in themselves. Just from your experiences, what are some of the processes or tools you guys are using?

Rizwan Hasan:

So, in terms of planning and work management, because we started off as a remote first company, and since COVID, business is good. I'll be frank there, it's been good for us because we specialize in this market. We've had a huge hiring spurt in all these different areas, and one thing that I noticed internally, as well as problems that... I wouldn't say problems, but a trend that we're seeing with a lot of other clients is that because of this remote push, and the need for an enterprise to be able to give the teams the tools they need to do their work, there's a lot more flexibility in what they can use, which has pros and cons.

On the pro side, there's flexibility, the teams can work the way they want. On the con side, administration might be difficult, alignment might be difficult. So we're seeing a lot of that with customers and ours. So we're almost going on this journey with customers as we're scaling ourselves, and learning how to navigate this new reality of working in a hybrid environment.

William Rojas:

I think in terms of some of the tooling and so forth that we get to do. So we obviously internally we have, we're pretty, pretty much in Atlassian. Atlassian stack, that is very much how we work every day. All our work is using Atlassian tools. All our work is tracked, all our client work is tracked in JIRA, all our sales work, basically everything we do, we use JIRA and Confluence, we're really big on Confluence. We have a lot of customizations we've done to our instance over the years, things that we just have developed, and so that's internal.

I think the other aspect is often, depending on the client that comes to us and the type of work that we're doing for that client, then the types of tools that we use can pretty much run the full gamut. We have a lot of Atlassians, we do a lot of work in JIRA with our clients, like work in Confluence. Sometimes we're working on helping them scale, so we bring on some of the add-on to support some of the scaling practices within to support JIRA. We'll do a lot of JSM work. We do often DevOps work, and then we'll bring on a lot of the DevOps tool sets that you would expect to find, so things to support delivery pipelines.

So it really depends quite a bit on the client. We even do some agile transformation work. And then there, we do some a lot of custom build things, practices and so forth. And we bring in surveys and tools that we've been able to develop over the years to support that particularly. So a lot of the tools often are dictated by what the client and the specific engagement call for.

Angad Sethi:

In my personal experience recently with COVID, I find myself in a lot of meetings, we are experimenting with, with Async decision making. Have you experimented with Async decision making processes yet?

Rizwan Hasan:

I'll start by saying I hate meetings. I think most meetings are a waste of time, and I tell my team this. And I'm like, "If we don't need to meet, like we're not going to meet."

Angad Sethi:

Yeah. Awesome.

Rizwan Hasan:

And I think that really comes. Yeah, awesome, for sure. Awesome.

Angad Sethi:

I love it.

Rizwan Hasan:

But it comes down to really is when you do meet, are you having the right conversation? And I think a key component being like an agile team, quote-unquote, is you have an understanding of what we all are doing collectively and what the priorities are. Which is tough to actually get. So when we talk about like asynchronous decision making, with a team that has some degree of understanding of what priorities are, what goals are, it gets easier. And you can have more low impact interactions with people.

So we use Slack a lot and we have a lot of internal bots on our Slack to be able to present information and collect feedback at asynchronous times, because there's voting features, there's places where you can comment. And I think when we talk about teams that are growing across the globe and also time zones and flexible working, that's a real thing now. There's a practical way of how to do that, that we're starting to dig into what does that look like?

Angad Sethi:

Do you find yourself in a million Slack groups?

Rizwan Hasan:

Yep.

Angad Sethi:

Yep. You do. Do you see any extra hurdles you've got to skip because of that? Because you maybe, do you find yourself hopping from conversation to conversation, whereas it would just be easier if everyone was in the same conversation? Does that happen a bit?

Rizwan Hasan:

Yeah. Yeah. All the time.

Angad Sethi:

I hear you, yeah, there you go. Okay. Cool.

William Rojas:

But I would say we have a lot of impromptu. I think we do have a lot of impromptu meetings. And sometimes we may be in a Slack typing away. It says, you know what? [crosstalk 00:17:29]

Angad Sethi:

Just jump in a huddle.

William Rojas:

Into Zoom and then let's chat or Slack conversation, and then just face to face conversation, and then just address it then and there. But I think we have been looking at, it's almost like I think a balance between the time spent on the meeting, and the amount of people that need to be in the meeting, and the benefit and value that comes out of that meeting. And a daily meeting where work was people would pick up work or support from a sales perspective. And it was very, very much necessary as per part of the work coming into the consulting pipeline. But it felt very inefficient.

So that's one of the means, for example, we did away with, and it's now a completely asynchronous process, by which work comes in and it gets allocated, people pick it up, people support it, we deliver things, we track where things are and so forth. And we now use all of that is basically all done through Slack. So we did away with all the meetings around, "Hey, who can help with this?" But meantime, we have another meeting where we're trying to get people on projects. And that is very much a, we need to negotiate on that often. So that's a meeting that's still very much done.

Angad Sethi:

Yep.

William Rojas:

Everybody comes in, we all talk, we decide what we need to get done. People balance back and forth. So that trade off I think is really important to really understand what, there are meetings that are necessary, very valuable, and they should remain. And there's ones that really a Slack is a much better mechanism to be able to make those kind of decisions

Angad Sethi:

Yeah. Very true. Yeah. And does it well, sorry, firstly, pardon the location change. I'm sitting right next to the router now, so hopefully the iPhone holds. What sort of a scale are we speaking about here in your Slack? The reason I ask is with larger organizations, it can be harder to scale. Therefore I'm just trying to get a gauge of what scale your Slack is at.

Rizwan Hasan:

So we just hit, we are just over the 500 mark, that'd be in terms of employees. With basically our general, which seems to be, I think, I don't want to say universal, but the standard across any organization that has Slack general as the best indicator of how many people you have logged on. So we're just about the 500 mark, which I would say is probably around mid-size, but it's definitely getting to the point where we're starting to see, it's almost a little bit too much in order to disseminate information, find their information, etc.

We're actually partners with Slack also. So we work with them pretty closely on some opportunities. [crosstalk 00:20:39] Yeah, exactly. And we're starting to talk with customers also about the same problem, about how much is too much, and when do you start to form communities around people that are delivering the same type of value. So those conversations are more aligned and there's not just a whole lot of chatter and people get confused, like when they read Slack and like, "Oh, is this the priority now? Or am I supposed to be doing this or change in process?" That communication is harder now, I think, really. And this is where a lot of folks, I think, who are moving to this remote environment are struggling with, is that alignment communication.

Angad Sethi:

Yeah. Very true.

William Rojas:

And it is, I would say fairly organic, like our channel proliferation. We do have, I would think even for company of our size, we're pretty loose about how channels get proliferated, who gets to create them, what they're for and so forth. But then it gives the flexibility of based upon your interests or the context of what you need to communicate on, then you can either join a channel that supports it or create a channel if necessary to support it. So it is, in that sense, pretty organic. But it is true that there are hundreds, if not thousands of Slack channels that we have, and so kind of staying like which one should you be on, is definitely one of our biggest challenges.

Angad Sethi:

Yeah. Well, that just blows my mind just because like 500 people on a Slack. Our whole company is 35 people and I'm pulling my hair out being in too many Slacks. So well A, that blows my mind.

William Rojas:

It does allow us, for example, to have client specific Slack channels. So anybody, if you need to talk about, if you're working on a particular account, you're working for a client, then there's a channel for that. And if you're working on another client, there's another channel. The thing I find helpful about it is that it gives you that context of if I want to communicate with so and so, if I communicate with Riz on a particular account, I will go to the account channel. If I want to talk to Riz one-on-one, I go to a one-on-one chat.

Angad Sethi:

I see, yep, the flexibility.

William Rojas:

So we do have that benefit of where to put the information. But it does mean that I have probably over a hundred channels in my roster of things that I follow, and I'm always behind.

Angad Sethi:

Yeah.

William Rojas:

Well, yeah. So the next level of it is, then you begin to prioritize which channels should I really be notified about, and which ones are most important. I want to track those. And I try to keep that list to a minimum in terms of unread messages, and the stuff that I try to get to, and I'm bored and I have nothing else to do so, but yeah.

Rizwan Hasan:

I've been leaving a lot of channels too. I've been just really cutting the cord with some channels. You know, I had some motivation to really help out here, but I just can't and it's just too much noise. And just got to cut the cord and be like, if it's empty, there's no conversation happening or if it's slow, then move on.

Angad Sethi:

Yep.

William Rojas:

We also have the ability to, you can get added back in. So sometimes you leave and then somebody will put you back in, like, "I need you to talk about this." But it is pretty organic. I know we do leave it up to the individual to decide how best to manage that.

Rizwan Hasan:

Yeah.

Angad Sethi:

That's awesome.

Rizwan Hasan:

We had a instance today, actually, where there was an old, it was basically a sales opportunity, a customer who had reached out to us for a certain ask, and we hadn't heard from them for months, like eight-nine months. And someone posted, someone who I'm pretty close with on our sales team posted, "Hey, this is kicking back up again, but I don't have the capacity." And I just left immediately as I saw that message. I was like, "I can't help out. Sorry."

Angad Sethi:

Yeah. The old so-and-so has left the group is a bit of a stab in the heart, but yeah.

Rizwan Hasan:

Yeah.

Angad Sethi:

We will get over it. Just coming back to a point you mentioned, Riz, you said you used the words, alignment and communication. Both of you when consulting with clients, are those the two main themes you guys like to base your recommendations around?

Rizwan Hasan:

I'll give you a very consulting answer and say it depends.

Angad Sethi:

Yeah.

Rizwan Hasan:

But when we engage with a customer, one of the toughest parts of our job is understanding if there is even alignment in the group of people that we're talking to as well, because at the scale of projects that sometimes we work with, we have like 20 to 25 people on a call. And of all of those people, they may have different motivations or objectives of what they're wanting with their engagement with us. So I would say, that's primarily what's driving what we're trying to find out, what we're trying to do with them is get some alignment between the group and ourselves, and communicating that is not always easy.

Angad Sethi:

Yeah.

William Rojas:

Let's say, adding on what Riz, that also depends quite a bit on the specific engagement with that client. So in particular, if the engagement, because if an engagement is like, "Get me onto the cloud." Okay. You know, come in. Often there's much better alignment for something like that. If the engagements are more about, "Hey, help us scale agile, help us get better at how we deliver." Then the need for alignment, the need to make sure that we're all communicating correctly, we all understand, we all come to the meeting with the same objectives and so forth, is so much more critical.

Angad Sethi:

Yeah.

William Rojas:

So in those kind of engagements, we're constantly realigning. Because it's not even like we had the alignment. It's like yeah. Okay. We have it, next week it's gone. We got to go back and get it again. So that keeping, making sure that everybody's marching towards the same set of objectives, defining what those objectives are, letting them evolve as appropriate and so forth, all that becomes so much more critical.

Angad Sethi:

Yeah.

William Rojas:

And that's where the tools, that's where things like JIRA and then again, like how do we scale? How do we show what everybody's doing? And so forth, that's where it becomes that much more important. And in those kind of engagements, the tooling becomes essential. Not that the tooling's going to answer it, but the tooling becomes a way by which it helps us communicate, yeah. This is what we all agree we're going to do. Okay. The tool says so because that's the decision we've made.

Angad Sethi:

Yeah.

Rizwan Hasan:

It's really interesting that you say cloud migration, William, like when you say, "Okay, I'm moving to cloud, we know what the alignment is," but even then, I'm finding is that, especially within the Atlassian ecosystem, because that's what we're exposed to all the time, but when we're moving data from a completely old infrastructure to something brand new, it's not going to be the same. And you have folks who are thinking that, "Oh, we're just going to be taking all this stuff from here and putting it over there." But what usually doesn't come along with it is that you're going to have to also change the way you work slightly. There's going to be changes that you're not accounting for.

And that's where the alignment conversation really is important because we work with small companies who understand, okay, moving to the cloud will be completely different. We also work with legacy organizations like financial institutions that have a lot of red tape, and process, and security concerns, and getting that alignment and understanding with them first of what this means to move to a completely different way of working, is also part of that conversation. So it's a constant push and pull with that.

Angad Sethi:

Yeah, yeah. It's really heartwarming to hear the two of you deal with the JCMA, which is the geo cloud migration system.

Rizwan Hasan:

Quite a bit, yeah.

Angad Sethi:

That's awesome, because yeah, that's something we are working on currently as well. So I'll end with a super hard question and I'll challenge you guys to not use the word depends in there. And the question is the number one piece of advice for remote teams practicing agile. Start with you, Riz.

Rizwan Hasan:

Get to know each other.

Angad Sethi:

Yeah, okay.

Rizwan Hasan:

Keep it personal. I think one of the hardest things about this new reality is making that connection with someone, and when you have that, that builds trust, and when you have trust, everything's a lot easier. So I'd say that. People really aren't... The enemy. That's not the right word, but work shouldn't be a conflict. It should be more of like a negotiation, and if you trust each other, it's a lot easier to do that.

Angad Sethi:

Yeah.

Rizwan Hasan:

So yeah.

Angad Sethi:

That's awesome.

William Rojas:

It really is.

Angad Sethi:

I'm going to definitely take that back with me.

William Rojas:

Yeah. And just if I could quickly add to that. That's like looking for ways how to replace the standing around by the, having a cup of coffee. How do you replace that in a remote setting?

Rizwan Hasan:

Yeah.

Angad Sethi:

Yeah.

William Rojas:

How do you still have that personal interaction that maybe there's an electronic medium in between, but there's still sort of that personal setting. I think that's one of the things you're looking for. Because yeah, it is very much about trust. And I think to that, I would also add, back to the alignment. Right? Because in some ways that strong interaction helps build and maintain the alignment, because often it's not so much that you get alignment is that you stay aligned.

So it is this constant, and having those interactions, having that trust and so forth, is what in a sense allows us to stay aligned. Because we know each other, we know how to help each other, we support each other, so we stay in alignment. So the trust and so forth are a good way to help build and maintain the alignment itself that you're looking for. That's absolutely. In remote world, you don't have the benefit of seeing each other, the whiteboard, all those things are not the same.

Angad Sethi:

Very true. Getting cup a coffee, yep.

William Rojas:

But we still need to stay in sync with what needs to get done. That's so important.

Angad Sethi:

Very true. And so would you guys want to drop any names of tools you're using to facilitate that trust between team members in a remote setting?

William Rojas:

So I would say, like I mentioned from my role, one of the things that we do is in the presales area, we support some of our larger accounts, almost as more of like a solution account manager, per se. So we come in and help make sure that the client is getting the solution that is meant to be delivered. So we work with the delivery teams, we work with the client, we sit in between.

There's one large client that we've been working on for years now, and we basically, to the point that they're moving towards some flavor of safe. That I wouldn't call it fully safe, but they do have a lot of safe practices, but they do PI planning, and so we come in and join the PI planning. That's actually one of the, like I said, how do you stay alive?

Angad Sethi:

That circle. Yeah. [crosstalk 00:33:15]

William Rojas:

You pull up your program definition, you look at what features you want to deliver in the PI, who's going to deliver that feature in the PI, and then in your readout, go back to the tool and say, "Look, this is what we've agreed to." Others can ask questions and so forth, and constantly going back to... For example, just last week, we're doing now sprint planning and saying, "Actually, okay, this feature's going to drag on another sprint. Let me go back and readjust in," this client is using the Easy Agile programs. The original plan of saying this features not going to be, not two sprints, but the three sprints instead, for example.

So that habit of getting into using the tool to communicate what we decided and what we just had to make changes to. So it becomes this, a communication vehicle, it's really important. Yeah, they use programs, they use the roadmap piece of programs to help them do their PI planning, and stay in sync with what it is that ultimately gets communicated out at the end of PI. And then during the sprints of the PI itself, and it's very helpful for them. Again, there's I think they have seven trainings, and they all use that to help stay in sync, stay aligned.

Angad Sethi:

Awesome. Awesome.

William Rojas:

One other quick thing I'll say is, I think there will be, some of where we've gone will now become status quo, become permanent. So I think that this has been as shift across the market, across the industry, across company, how people work. So the idea of remote work, the idea of using tooling to really establish communication, and help facilitate communication, all that, while it's been around, I think the big difference is now everybody, like you have no choice. Everybody has to do it.

Angad Sethi:

Has to. Yeah.

William Rojas:

And I think we've definitely seen a big shift across the entire industry because of that. That will now solidify and let's see what the next level brings. But I definitely think that we've reached a new stage of maturity and so forth pretty much globally, which is pretty cool.

Angad Sethi:

Yeah.

Rizwan Hasan:

Yeah.

Angad Sethi:

Yeah, it is. Thank you guys. I won't keep you too long. I think, has the sun set there, Riz? I can see the reflection going dark.

Rizwan Hasan:

Yeah. It is getting there. Yeah, for sure.

Angad Sethi:

Yeah. Yeah. I won't hold you guys for too long.

Rizwan Hasan:

All good.

Angad Sethi:

But thank you so much for the conversation. I honestly, I took a lot away from that. And yeah, I hope I can add you guys to my LinkedIn. I would love to be in touch still.

William Rojas:

Definitely.

Rizwan Hasan:

Yeah, sure.

Angad Sethi:

Yeah. Trying to establish a point of contact, not to add to one of your Slack channels, but yeah. Just so that we can be in conversation regarding the product and improving it.

Rizwan Hasan:

Yeah, sure. And we have a partner management channel. I know we've been talking to Haley a little bit.

Angad Sethi:

Awesome.

Rizwan Hasan:

She was reaching out, that's about some other stuff.

Angad Sethi:

Beautiful.

Rizwan Hasan:

Yeah, happy to. We engage with your product and it's in our white papers too, and we're going to put out another white paper this year where we're going to talk about Easy Agile too. So yeah. We'll stay in touch.

Angad Sethi:

Cool.

William Rojas:

I just gave you, so my LinkedIn is under a different, my LinkedIn is not with my work email. Because that way I can keep the same account place to place.

Angad Sethi:

Sounds good.

William Rojas:

Yeah. You can look me up on LinkedIn with that.

Angad Sethi:

Wicked awesome. Thanks guys.

William Rojas:

Awesome. All right.

Angad Sethi:

Have a good day.

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