Easy Agile Podcast Ep.12 Observations on Observability
On this episode of The Easy Agile Podcast, tune in to hear developers Angad, Jared, Jess and Jordan, as they share their thoughts on observability.
Wollongong has a thriving and supportive tech community and in this episode we have brought together some of our locally based Developers from Siligong Valley for a round table chat on all things observability.
💥 What is observability?
💥 How can you improve observability?
💥 What's the end goal?

"This was a great episode to be a part of! Jess and Jordan shared some really interesting points on the newest tech buzzword - observability""
Be sure to subscribe, enjoy the episode 🎧
Transcript
Jared Kells:
Welcome everybody to the Easy Agile podcast. My name's Jared Kells, and I'm a developer here at Easy Agile. Before we begin, Easy Agile would like to acknowledge the traditional custodians of the land from which we broadcast today, the Wodiwodi people of the Dharawal nation, and pay our respects to elders past, present and emerging, and extend that same respect to any aboriginal people listening with us today.
Jared Kells:
So today's podcast is a bit of a technical one. It says on my run sheet here that we're here to talk about some hot topics for engineers in the IT sector. How exciting that we've got a couple of primarily front end engineers and Angad and I are going to share some front end technical stuff and Jess and Jordan are going to be talking a bit about observability. So we'll start by introductions. So I'll pass it over to Jess.
Jess Belliveau:
Cool. Thanks Jared. Thanks for having me one as well. So yeah, my name's Jess Belliveau. I work for Apptio as an infrastructure engineer. Yeah, Jordan?
Jordan Simonovski:
I'm Jordan Simonovski. I work as a systems engineer in the observability team at Atlassian. I'm a bit of a jack of all trades, tech wise. But yeah, working on building out some pretty beefy systems to handle all of our data at Atlassian at the moment. So, that's fun.
Angad Sethi:
Hello everyone. I'm Angad. I'm working for Easy Agile as a software dev. Nothing fancy like you guys.
Jared Kells:
Nothing fancy!
Jess Belliveau:
Don't sell yourself short.
Jared Kells:
Yeah, I'll say. Yeah, so my name's Jared, and yeah, senior developer at Easy Agile, working on our apps. So mainly, I work on programs and road maps. And yeah, they're front end JavaScript heavy apps. So that's where our experience is. I've heard about this thing called observability, which I think is just logs and stuff, right?
Jess Belliveau:
Yeah, yeah. That's it, we'll wrap up!
Jared Kells:
Podcast over! Tell us about observability.
Jess Belliveau:
Yeah okay, I'll, yeah. Well, I thought first I'd do a little thing of why observability, why we talk about this and sort of for people listening, how we got here. We had a little chat before we started recording to try and feel out something that might interest a broader audience that maybe people don't know a lot about. And there's a lot of movements in the broad IT scope, I guess, that you could talk about. There's so many different things now that are just blowing up. Observability is something that's been a hot topic for a couple of years now. And it's something that's a core part of my job and Jordan's job as well. So it's something easy for us to talk about and it's something that you can give an introduction to without getting too technical. So we don't want to get down. This is something that you can go really deep into the weeds, so we picked it as something that hopefully we can explain to you both at a level that might interest the people at home listening as well.
Jess Belliveau:
Jordan and I figured out these four bullet points that we wanted to cover, and maybe I can do the little overview of that, and then I can make Jordan cover the first bullet point, just throw him straight under the bus.
Jordan Simonovski:
Okay!
Jess Belliveau:
So we thought we'd try and describe to you, first of all, what is observability. Because that's a pretty, the term doesn't give you much of what it is. It gives you a little hint, but it'll be good to base line set what are we talking about when we say what is observability. And then why would a development team want observability? Why would a company want observability? Sort of high level, what sort of benefits you get out of it and who may need it, which is a big thing. You can get caught up in these industry hot buzz words and commit to stuff that you might not need, or that sort of stuff.
Jared Kells:
Yep.
Jordan Simonovski:
Yep.
Jess Belliveau:
We thought we'd talk about some easy wins that you get with observability. So some of the real basic stuff you can try and get, and what advantages you get from it. And then we just thought because we're no going to try and get too deep, we could just give a few pointers to some websites and some YouTube talks for further reading that people want to do, and go from there. So yeah, Jordan you want to-
Jared Kells:
Sounds good.
Jess Belliveau:
Yeah. I hopefully, hopefully. We'll see how this goes! And I guess if you guys have questions as well, that's something we should, if there's stuff that you think we don't cover or that you want to know more, ask away.
Jordan Simonovski:
I guess to start with observability, it's a topic I get really excited about, because as someone that's been involved in the dev ops and SRE space for so long, observability's come along and promises to close the loop or close a feedback loop on software delivery. And it feels like it's something we don't really have at the moment. And I get that observability maybe sounds new and shiny, but I think the term itself exists to maybe differentiate itself from what's currently out there. A lot of us working in tech know about monitoring and the loading and things like that. And I think they serve their own purpose and they're not in any way obsolete either. Things like traditional monitoring tools. But observability's come along as a way to understand, I think, the overwhelmingly complex systems that we're building at the moment. A lot of companies are probably moving towards some kind of complicated distributed systems architecture, microservices, other buzz words.
Jordan Simonovski:
But even for things like a traditional kind of monolith. Observability really serves to help us ask new questions from our systems. So the way it tends to get explained is monitoring exits for our known unknowns. With seniority comes the ability to predict, almost, in what way your systems will fail. So you'll know. The longer you're in the industry, you know this, like a Java server fails in x, y, z amount of ways, so we should probably monitor our JVM heap, or whatever it is.
Jared Kells:
I was going to say that!
Jordan Simonovski:
I'll try not to get too much into-
Jared Kells:
Runs out of memory!
Jordan Simonovski:
Yeah. So that's something that you're expecting to fail at some point. And that's something that you can consider a known unknown. But then, the promise of observability is that we should be shipping enough data to be able to ask new questions. So the way it tends to get talked about, you see, it's an unknown unknown of our system, that we want to find out about and ask new questions from. And that's where I think observability gets introduced, to answer these questions. Is that a good enough answer? You want me to go any further into detail about this stuff? I can talk all day about this.
Jared Kells:
Is it like a [crosstalk 00:08:05]. So just to repeat it back to you, see if I've understood. Is it kind of like if I've got a, traditionally with a Java app, I might log memories. It's because I know JVM's run out of memory and that's a thing that I monitor, but observability is more broad, like going almost over the top with what you monitor and log so that you can-
Jordan Simonovski:
Yeah. And I wouldn't necessarily say it's going over the top. I think it's maybe adding a bit more context to your data. So if any of you have worked with traces before, observability is very similar to the way traces work and just builds on top of the premise of traces, I guess. So you're creating these events, and these events are different transactions that could be happening in your applications, usually submitting some kind of request. And with that request, you can add a whole bunch of context to it. You can add which server this might be running on, which time zone. All of these additional and all the exciters. You can throw in user agency into there if you want to. The idea of observability is that you're not necessarily constrained by high cardinality data. High cardinality data being data sets that can change quite largely, in terms of the kinds of data they represent, or the combinations of data sets that you could have.
Jordan Simonovski:
So if you want shipping metrics on something, on a per user basis and you want to look at how different users are affected by things, that would be considered a high cardinality metric. And a lot of the time it's not something that traditional monitoring companies or metric providers can really give you as a service. That's where you'll start paying insanely huge bills on things like Datadog or whatever it is, because they're now being considered new metrics. Whereas observability, we try and store our data and query it in a way that we can store pretty vast data sets and say, "Cool. We have errors coming from these kinds of users." And you can start to build up correlations on certain things there. You can find out that users from a particular time zone or a particular device would only be experiencing that error. And from there, you can start building up, I think, better ways of understanding how a particular change might have broken things. Or some particular edge cases that you otherwise couldn't pick up on with something like CPU or memory monitoring.
Angad Sethi:
Would it be fair to say-
Jared Kells:
Yeah. It's [crosstalk 00:11:02].
Angad Sethi:
Oh, sorry Jared.
Jared Kells:
No you can-
Angad Sethi:
Would it be fair to say that, so, observability is basically a set of principles or a way to find the unknown unknowns?
Jordan Simonovski:
Yeah.
Angad Sethi:
Oh.
Jess Belliveau:
And better equip you to find, one of the things I find is a lot of people think, you get caught up in thinking observability is a thing that you can deploy and have and tick a box, but I like your choice of word of it being a set of principles or best practices. It's sort of giving you some guidance around these, having good logging coming out of your application. So structured logs. So you're always getting the same log format that you can look at. Tracing, which Jordan talked a little bit about. So giving you that ability to follow how a user is interacting with all the different microservices and possibly seeing where things are going wrong, and metrics as well. So the good thing with metrics is we're turning things a bit around and trying to make an application, instead of doing, and I don't want to get too technical, black box monitoring, where we're on the outside, trying to peer in with probes and checks like that. But the idea with metrics is the application is actually emitting these metrics to inform us what state it is in, thereby making it more observable.
Jess Belliveau:
Yeah, I like your choice of words there, Angad, that it's like these practices, this sort of guide of where to go, which probably leads into this next point of why would a team want to implement it. If you want to start again, Jordan?
Jordan Simonovski:
Yeah, I can start. And I'll give you a bit more time to speak as well, Jess in this one. I won't rant as much.
Jess Belliveau:
Oh, I didn't sign up for that!
Jordan Simonovski:
I think why teams would want it is because, it really depends on your organization and, I guess, the size of the teams you're working in. Most of the time, I would probably say you don't want to build observability yourself in house. It is something that you can, observability capabilities themselves, you won't achieve it just by buying a thing, like you can't buy dev ops, you can't buy Agile, you can't buy observability either.
Jared Kells:
Hang on, hang on. It says on my run sheet to promote Easy Agile, so that sounds like a good segue-
Jess Belliveau:
Unless you want to buy it. If you do want to buy Agile, the [crosstalk 00:13:55] in the marketplace.
Jared Kells:
Yeah, sorry, sorry, yeah! Go on.
Jordan Simonovski:
You can buy tools that make your life a lot easier, and there are a lot of things out there already which do stuff for people and do surface really interesting data that people might want to look at. I think there are a couple of start ups like LightStep and Honeycomb, which give you a really intuitive way of understanding your data in production. But why you would need this kind of stuff is that you want to know the state of your systems at any given point in time, and to build, I guess, good operational hygiene and good production excellence, I guess as Liz Fong-Jones would put it, is you need to be able to close that feedback loop. We have a whole bunch of tools already. So we have CICD systems in place. We have feature flags now, which help us, I guess, decouple deployments from releases. You can deploy code without actually releasing code, and you can actually give that power to your PM's now if you want to, with feature flags, which is great.
Jordan Simonovski:
But what you can also do now is completely close this loop, and as you're deploying an application, you can say, "I want to canary this deployment. I want to deploy this to 10% of my users, maybe users who are opted in for Beta releases or something of our application, and you can actually look at how that's performing before you release it to a wider audience. So it does make deployments a lot safer. It does give you a better understanding of how you're affecting users as well. And there are a whole bunch of tools that you can use to determine this stuff as well. So if you're looking at how a lot of companies are doing SRE at the moment, or understanding what reliable looks like for their applications, you have things like SLO's in place as well. And SLO's-
Jared Kells:
What's an SLO?
Jordan Simonovski:
They're all tied to user experiences. So you're saying, "Can my user perform this particular interaction?" And if you can effectively measure that and know how users are being affected by the changes you're making, you can easily make decisions around whether or not you continue shipping features or if you drop everything and work on reliability to make sure your users aren't affected. So it's this very user centric approach to doing things. I think in terms of closing the loop, observability gives us that data to say, "Yes, this is how users are being affected. This is how, I guess the 99th percentile of our users are fine, but we have 1% who are having adverse issues with our application." And you can really pinpoint stuff from there and say, "Cool. Users with this particular browser or this particular, or where we've deployed this app to," let's say if you have a global deployment of some kind, you've deployed to an island first, because you don't really care what happens to them. You can say, "Oh, we've actually broken stuff for them." And you can roll it back before you impact 100% of your users.
Jared Kells:
Yeah. I liked what you said about the test. I forgot the acronym, but actually testing the end user behavior. That's kind of exciting to me, because we have all these metrics that are a bit useless. They're cool, "Oh, it's using 1% CPU like it always is, now I don't really care," but can a user open up the app and drag an issue around? It's like-
Jess Belliveau:
Yeah, that's a really great example, right?
Jared Kells:
That's what I really care about.
Jess Belliveau:
The 1% CPU thing, you could look at a CPU usage graph and see a deployment, and the CPU usage doesn't change. Is everything healthy or not? You don't know, whereas if you're getting that deeper level info of the user interactions, you could be using 1% CPU to serve HTTP500 errors to the 80% of the customer base, sort of thing.
Angad Sethi:
How do you do that? The SLO's bit, how do you know a user can log in and drag an issue?
Jordan Simonovski:
Yeah. I think that would come with good instrumenting-
Angad Sethi:
Good question?
Jordan Simonovski:
Yeah, it comes down to actually keeping observability in mind when you are developing new features, the same way you would think about logging a particular thing in your code as you're writing, or writing test for your code, as you're writing code as well. You want to think about how you can instrument something and how you can understand how this particular feature is working in production. Because I think as a lot of Agile and dev ops principles are telling us now is that we do want our applications in production. And as developers, our responsibilities don't end when we deploy something. Our responsibility as a developer ends when we've provided value to the business. And you need a way of understanding that you're actually doing that. And that's where, I guess, you do nee do think about observability with a lot of this stuff, and actually measuring your success metrics. So if you do know that your application is successful if your user can log in and drag stuff around, then that's exactly what you want to measure.
Jared Kells:
I think that we have to build-
Jordan Simonovski:
Yeah?
Jared Kells:
Oh, sorry Jordan.
Jordan Simonovski:
No, you go.
Jared Kells:
I was just going to say we have to build our apps with integration testing in mind already. So doing browser based tests around new features. So it would be about building features with that and the same thing in mind but for testing and production.
Jess Belliveau:
Yeah and the actual how, the actual writing code part, there's this really great project, the open telemetry project, which provides all these sort of API's and SDK's that developers can consume, and it's vendor agnostic. So when you talk about the how, like, "How do I do this? How do I instrument things?" Or, "How do I emit metrics?" They provide all these helpful libraries and includes that you can have, because the last thing you want to do is have to roll this custom solution, because you're then just adding to your technical debt. You're trying to make things easier, but you're then relying on, "Well I need to keep Jared Kells employed, because he wrote our log in engine and no one else knows how it works.
Jess Belliveau:
And then the other thing that comes to mind with something like open telemetry as well, and we talked a bit about Datadog. So Datadog is a SaaS vendor that specializes in observability. And you would push your metrics and your logs and your traces to them and they give you a UI to display. If you choose something that's vendor agnostic, let's just use the example of Easy Agile. Let's say they start Datadog and then in six months time, we don't want to use Datadog anymore, we want to use SignalFx or whatever the Splunk one is now.
Jordan Simonovski:
I think NorthX.
Jess Belliveau:
Yeah. You can change your end point, push your same metrics and all that sort of stuff, maybe with a few little tweaks, but the idea is you don't want to tie in to a single thing.
Jordan Simonovski:
Your data structures remain the same.
Jess Belliveau:
Yeah. So that you could almost do it seamlessly without the developers knowing. There's even companies in the past that I think have pushed to multiple vendors. So you could be consuming vendor A and then you want to do a proof of concept with vendor B to see what the experience is like and you just push your data there as well.
Jared Kells:
Yeah. I think our coupling to Datadog will be I all the dashboards and stuff that we've made. It's not so much the data.
Jess Belliveau:
Yeah. That's sort of the big up sell, right. It's how you interact. That's where they want to get their hooks in, is making it easier for you to interpret that data and manipulate it to meet your needs and that sort of stuff.
Jordan Simonovski:
Observability suggests dashboards, right?
Jess Belliveau:
Yeah, perhaps. You used this term as well, Jordan, "production excellence." And when we talk about who needs observability, I was thinking a bit about that while you were talking. And for me, production excellence, or in Apptio we call it production readiness, operational readiness and that sort of stuff is like we want to deploy something to production like what sort of best practices do we want to have in place before we do that? And I think observability is a real great idea, because it's helping you in the future. You don't know what problems you're going to have down the line, but you're equipping your teams to be able to respond to those problems easily. Whereas, we've all probably been there, we've deployed code of production and we have no observability, we have a huge outage. What went wrong? Well, no one knows, but we know this is the fix, and it's hard to learn from that, or you have to learn from that I guess, and protect the user against future stuff, yeah.
Jess Belliveau:
When I think easy wins for observability, the first thing that really comes to mind is this whole idea of structured logging, which is really this idea that your application is you're logging, first of all. Quite important as a baseline starting point, but then you have a structured log format which lets you programmatically pass the logs as well. If you go back in time, maybe logging just looked like plain text with a line, with a timestamp, an error message. Whatever the developer decided to write to the standard out, or to the error file or something like that. Now I think there's a general move to having JSON, an actual formatted blob with that known structure so you can look into it. Tracing's probably not an easy win. That's a little bit harder. You can implement it with open telemetry and libraries and stuff. Requires a bit more understanding of your code base, I guess, and where you want tracing to fire, and that sort of stuff, parsing context through, things like that.
Jordan Simonovski:
I think Atlassian, when you probably just want to know that everything is okay. At a fairly superficial level. Maybe you just want to do some kind of up time on a trend. And then as, I guess, your code might get more complex or your product gets a bit more complex, you can start adding things in there. But I think actually knowing or surfacing the things you know might break. Those would probably be your quickest wins.
Jess Belliveau:
Well, let's mention some things for further reading. If you want to go get the whole picture of the whole, real observability started to get a lot of movement out of the Google SRE book from a few years ago. The Google SRE stuff covers the whole gamut of their soak reliability engineering practice, and observability is a portion of that, there's some great chapters on that. O'Reilly has an observability book, I think, just dedicated to observability now.
Jordan Simonovski:
I think that's still in early release, if people want to google chapters.
Jess Belliveau:
The open telemetry stuff, we'll drop a link to that I think that's really handy to know.
Angad Sethi:
From [inaudible 00:26:12], which is my perspective, as a developer, say I wanted to introduce cornflake use Datadog at Easy Agile. Not very familiar, I'm not very comfortable with it. I know how to navigate, but what's a quick way for me to get started on introducing observability? Sorry to lock my direct job or at my workplace.
Jordan Simonovski:
I would lean, I could be biased here. Jess correct me or give your opinion on this, I would lean heavily towards SLO's for this. And you can have a quick read in the SRE-
Jess Belliveau:
What does SLO stand for, Jordan?
Jordan Simonovski:
Okay, sorry. Buzz words! SLO is a service level objective, not to be confused with service level agreement. An agreement itself is contractual and you can pay people money if you do breach those. An SLO is something you set in your team and you have a target of reliability, because we are getting to the point where we understand that all systems at any point in time are in some kind of degraded state. And yeah, reliability isn't necessarily binary, it's not unreliable or reliable. Most of the time, it's mostly reliable and this gives us a better shared language, I guess. And you can have a read in the SRE handbook by Google, which is free online, which gives you a pretty good understanding of Datadog.
Jordan Simonovski:
I think the last time I used it had a SLO offering. But I think like I was mentioning earlier, you set an SLO on particular functionalities or features of your application. You're saying, "My user can do this 99% of the time," or whatever other reliability target you might want to set. I wouldn't recommend five nines of reliability. You'll probably burn yourself out trying to get there. And you have this target set for yourself. And you know exactly what you're measuring, you're measuring particular types of functionality. And you know when you do breach these, users are being affected. And that's where you can actually start thinking about observability. You can think about, "What other features are we implementing that we can start to measure?" Or, "What user facing things are we implementing that we can start to measure?"
Jordan Simonovski:
Other things you could probably look at are, I think they're all covered in the book anyway, data freshness in a way. You want to make sure the data users are being displayed is relatively fresh. You don't want them looking at stale data, so you can look at measuring things like that as well. But you can pretty much break it down into most functionalities of a website. It's no longer like a ping check, that you're just saying, "Yes, HTTP, okay. My application is fine." You're saying, "My users are actually being affected by things not working." And you can start measuring things from there. And that should give you a better understanding, or a better idea, at least, of where to start with what you want to measure and ow you want to measure it. That would be my opinion on where to get started with this if you do want to introduce it.
Jared Kells:
We're going to talk a little bit about state and how with some of these, like our very front end heavy applications that we're building, so the applications we build just basically run inside the browser and the traditional state as you would think about it, is just pulling a very simple API that writes some things into the database with some authentication, and that sort of stuff. So in terms of reliability of the services, it's really reliable. Those tiny API's just never have problems, because it's just so simple. And well, they've got plenty of monitoring around it. But all our state is actually, when you say, "Observe the state of the system," for the most part, that's state in a browser. And how do we get observability into that?
Jess Belliveau:
A big thing is really, there's not one thing fits all as well. When we talk about the SLO stuff as well, it's understanding what is important to not so much maybe your company but your team as well. If you're delivering this product, what's important to you specifically? So one SLO that might work for me at Apptio probably isn't going to work for Easy Agile. This is really pushing my knowledge, as well, of front end stuff, but when we say we want to observe the state as well, we don't necessarily mean specifically just the state. You could want to understand with each one of those API's when it's firing, what the request response time is for that API firing. So that might be an important metric. So you can start to see if one of those APIs is introducing latency, and so your user experience is degraded. Like, "Hey when we were on release three, when users were interacting with our service here, it would respond in this percentile latency. We've done a release and since then, now we're seeing it's now in this percentile. Have we degraded performance performance?" Users might not be complaining, but that could be something that the team then can look into, add to a sprint. Hey, I'm using Agile terms now. Watch out!
Jared Kells:
That's a really good example, Jess. Performance issues for us are typically not an API that's performing poorly. It's something in this very complicated front end application is not running in the same order as it used to, or there's some complex interaction we didn't think of, so it's requesting more data than expected. The APIs are returning. They're never slow, for the most part, but we have performance regressions that we may not know about without seeing them or investigating them. The observability is really at the individual user's browser level. That makes sense? I want to know how long did it take for this particular interaction to happen.
Jess Belliveau:
Yeah. I've never done that sort of side of things. As well, the other thing I guess, you could potentially be impacted in as well as then, you're dealing with end user manifestations as well. You could perceive-
Jared Kells:
Yeah sure.
Jess Belliveau:
... Greater performance on their laptop or something, or their ISP or that sort of stuff. It'd be really hard to make sure you're not getting noise from that sort of thing as well.
Jordan Simonovski:
Yeah. There are tools like Sentry, I guess, which do exist to give you a bit more of an understanding what's happening on your front end. The way Sentry tends to work with JavaScript, is you'll upload a minified map of your JS to Sentry, deploy your code and then if something does break or work in a fairly unexpected way, that tends to get surfaced with Sentry will tell you exactly which line this kind of stuff is happening on, and it's a really cool tool for that company stuff. I don't know if it'd give you the right type of insights, I think, in terms of performance or-
Jared Kells:
Yeah, we use a similar tool and it does work for crashes and that sort of thing. And on the observability front, we log actions like state mutations in side the front end, not the actual state change, but just labels that represent that you updated an issue summary or you clicked this button, that sort of thing, and we send those with our crash reports. And it's super helpful having that sort of observability. So I think I know what you guys are talking about. But I'm just [crosstalk 00:35:25], yeah.
Jess Belliveau:
Yeah, that's almost like, I guess, a form of tracing. For me and Jordan, when we talk about tracing, we might be thinking about 12 different microservices sitting in AWS that are all interacting, whereas you're more shifting that. That's sort of all stuff in the browser interacting and just having that history of this is what the user did and how they've ended up-
Jared Kells:
In that state.
Jess Belliveau:
In that state, yeah.
Jordan Simonovski:
I guess even if you don't have a lot of microservices, if you're talking about particular, like you're saying for the most part your API requests are fine but sometimes you have particularly large payloads-
Jared Kells:
We actually have to monitor, I don't know, maybe you can help with this, we actually should be monitoring maybe who we're integrating with. It's actually much more likely that we'll have a performance issue on a Xero API rather than... We don't see it, the browser sees it as well, which is-
Jordan Simonovski:
Yeah, and tracing does solve all of those regressions for you. Most tracing libraries, like if you're running Node apps or whatever on your backend. I can just tell you about Node, because I probably have the most experience writing Node stuff. You pretty much just drop in Didi trace, which is a Datadog library for tracing into your backend and your hook itself into all of, I think, the common libraries that you'll tend to work with, I think. Like if you're working for express or for a lot of just HADP libraries, as well as a few AWS services, it will kind of hook itself into that. And you can actually pinpoint. It will kind of show you on this pretty cool service map exactly which services you're interacting with and where you might be experiencing a regression. And I think traces do serve to surface that information, which is cool. So that could be something worth investigating.
Jess Belliveau:
It's funny. This is a little bit unrelated to observability, but you've just made me think a bit more about how you're saying you're reliant on third party providers as well. And something I think that's really important that sometimes gets missed is so many of us today are relying on third party providers, like AWS is a huge thing. A lot of people writing apps that require AWS services. And I think a lot of the time, people just assume AWS or Jira or whatever, is 100% up time, always available. And they don't write their code in such a way that deals with failures. And I think it's super important. So many times now I've seen people using the AWS API and they don't implement exponential back off. And so they're basically trying to hit the AWS API, it fails or they might get throttled, for example, and then they just go into a fail state and throw an error to the user. But you could potentially improve that user experience, have a retry mechanism automatically built in and that sort of stuff. It doesn't really tie into the observability thing, but it's something.
Jared Kells:
And the users don't care, right? No one cares if it's an AWS problem. It's your problem, right, your app is too slow.
Jess Belliveau:
Well, they're using your app. Exactly right. It reflects on you sort of thing, so it's in your interest to guard against an upstream failure, or at least inform the user when it's that case. Yeah.
Jared Kells:
Well, I think we're going to have to call it, this podcast, because it was an hour ago. We had instructed max 45 minutes.
Jess Belliveau:
We could just keep going. We might need a part two! Maybe we can request [cross talk 00:39:21].
Jared Kells:
Maybe! Yeah.
Jess Belliveau:
Or we'll just start our own podcast! Yeah.
Angad Sethi:
So what were your biggest learnings today, given it's been Angad and I are just learning about observability, Angad what was your biggest learning today about observability? My biggest learning was that observability does not equal Datadog. No, sorry! It was just very fascinating to learn about quantifying the known unknowns. I don't know if that's a good takeaway, but...
Jess Belliveau:
Any takeaway is a good takeaway! What about you, Jared?
Jared Kells:
I think, because I we were going to talk about state management, and part of it was how we have this ability, at the moment to, the way our front ends are architected, we can capture the state of the app and get a customer to send us their state, basically. And we can load it into our app and just see exactly how it was, just the way our state's designed. But what might be even cooler is to build maybe some observability into that front end for support. I'm thinking instead of just having, we have this button to send us out your support information that sends us a bunch of the state, but instead of console logging to the browser log, we could be console logging, logging in our front end somewhere that when they click, "send support information," our customers should be sending us the actions that they performed.
Jared Kells:
Like, "Hey there's a bug, send us your support information." It doesn't have to be a third party service collecting this observability stuff. We could just build into our... So that's what I'm thinking about.
Jess Belliveau:
Yeah, for sure. It'll probably be a lot less intrusive, as well, as some of the third party stuff that I've seen around.
Jared Kells:
Yeah. It's pretty hard with some of these integrations, especially if you're developing apps that get run behind a firewall.
Jess Belliveau:
Yeah
Jared Kells:
You can't just talk to some of these third parties. So yeah, it's cool though. It's really interesting.
Jess Belliveau:
Well, I hope someone out there listening has learned something, and Jordan and I will send some links through, and we can add them, hopefully, to the show notes or something so people can do some more reading and...
Jared Kells:
All thanks!
Jess Belliveau:
Thanks for having us, yeah.
Jared Kells:
Thanks all for your time, and thanks everybody for listening.
Jordan Simonovski:
Thanks everyone.
Angad Sethi:
That was [inaudible 00:41:55].
Jess Belliveau:
Tune in next week!
Related Episodes
- Podcast
Easy Agile Podcast Ep.35 Jeff Gothelf on Customer-Centric OKRs, Goal-Setting, and Leadership That Scales
TL;DR
Jeff Gothelf, renowned author of "Lean UX" and "Who Does What By How Much," discusses the evolution from output-based work to outcome-focused goal setting with OKRs. Key insights: Teams need to shift from "we're building a thing" to defining success as "who does what by how much" – meaningful changes in human behaviour that drive business results; the biggest barrier to agile ways of working is that people get paid to ship features, not deliver value; leaders should change their questions from "what are you building?" to "what are you learning?"; psychological safety is critical – teams need to feel safe admitting when something isn't working; start small by simply asking "what will people be doing differently when we ship this?"; rename teams around outcomes (mobile revenue team) rather than outputs (iPhone app team); proactive transparency through weekly three-bullet-point updates builds trust with leadership. Bottom line: OKRs, when done right, are the "Trojan horse" that enables all other agile practices to succeed.
Introduction
For years, agile practitioners have championed better ways of working – Lean UX, design thinking, continuous discovery, customer centricity. Yet despite widespread adoption of these practices, many teams still struggle with the same fundamental problem: they're rewarded for shipping features, not delivering value.
In this episode, our CEO Mat Lawrence sits down with Jeff Gothelf to explore how this misalignment of incentives undermines even the best agile practices, and why customer-centric OKRs might be the missing piece that makes everything else click into place.
Jeff Gothelf is a renowned author, speaker, and consultant whose work has shaped how product teams approach collaboration and customer-centricity. Along with co-author Josh Seiden, Jeff wrote "Lean UX," which revolutionised how designers work in agile environments. Their follow-up book, "Sense and Respond," helped leaders understand how to manage in software-based businesses. Their latest book, "Who Does What By How Much," tackles the thorniest problem yet: how to align incentives and goals with customer outcomes.
This conversation traces Jeff's journey from helping designers work better in agile teams, to helping leaders create the conditions for success, to finally addressing the root cause – the goals and incentives that determine what gets celebrated, rewarded, and promoted in organisations. It's a masterclass in shifting from output thinking to outcome thinking, with practical advice for both team members and leaders navigating this transformation.
About Our Guest
Jeff Gothelf is an author, speaker, and organisational consultant who has spent over 15 years helping companies build better products through collaboration, learning, and customer-centricity. His work focuses on the intersection of agile software development, user experience design, and modern management practices.
Jeff is best known as the co-author (with Josh Seiden) of three influential books that have shaped modern product development practices. "Lean UX" (now in its third edition) began as a guide for designers working in agile environments but has evolved into a comprehensive framework for cross-functional collaboration and risk mitigation in product development. The book's core principle – moving from deliverables to outcomes – has influenced how thousands of teams approach their work.
Following "Lean UX," Jeff and Josh wrote "Sense and Respond," a book aimed at leaders and aspiring leaders. It makes the case that the overwhelming majority of businesses today are software businesses, and that managing software-based businesses requires fundamentally different approaches to team structure, management, and leadership. The book provides a roadmap for creating organisations where teams can actually practise the collaborative, customer-centric approaches described in "Lean UX."
Jeff's latest book, "Who Does What By How Much," represents the natural evolution of this work. After years of helping teams work better and leaders manage differently, Jeff and Josh identified that the real barrier to change was incentives and goals. Teams kept saying, "That's great, Jeff, but I get paid to ship features." This book tackles that problem head-on, showing how to use objectives and key results (OKRs) to create customer-centric goals that align with – rather than undermine – modern ways of working.
Beyond his books, Jeff has also authored "Forever Employable" and "Lean vs Agile vs Design Thinking," and he regularly speaks at conferences and consults with organisations on product strategy, team effectiveness, and organisational transformation. His approach is characteristically practical and rooted in real-world experience, making complex concepts accessible through clear frameworks and relatable examples.
Jeff's work continues to evolve as he helps organisations navigate the challenges of building products that customers actually want and need, whilst creating work environments where teams can thrive.
Transcript
Transcript
Note: This transcript has been lightly edited for clarity and readability.
Why Write Another Book? The Journey from Lean UX to OKRs
Mat Lawrence: Well, Jeff, welcome. I'm Mat Lawrence for our audience. I'm COO at Easy Agile, and today I'm talking with Jeff Gothelf, who is the renowned author, speaker, and consultant. You've written a good few books, Jeff. I've been looking through the list – Lean versus Agile versus Design Thinking, Forever Employable, and co-authored a few. The latest one being "Who Does What By How Much," and I was just telling Jeff in the intro here how you've managed to get across a lot of the things that I care about when trying to build teams and get them to understand OKRs. I've already given it to a few people and I'm definitely going to be giving it around. So, Jeff, welcome.
Jeff Gothelf: Thank you so much, Mat. That's very kind of you on all of that stuff. I appreciate it. Thanks for having me.
Mat: I'd love to cover a little bit around the book and the concept you're trying to get across. So I suppose the first question I have is what problem are you hoping to solve with the book? Why did you write it?
Jeff: It's really interesting. I wrote a blog post about this a while back because somebody challenged me on LinkedIn – and I appreciate a good challenge. They said, "How can you write about all this stuff? There's no way you know enough about each one of these topics to write a book. You're spreading yourself way too thin."
I thought that was a really interesting challenge. No one had ever asked that question, and it got me thinking. The answer that I came up with is that this book, "Who Does What By How Much," and it's a conversation about customer-centric objectives and key results, is the natural evolution of the work that Josh Seiden and I have been doing together for more than 15 years.
"We started with Lean UX, and Lean UX was a solution for designers helping them work more effectively in agile software development environments. The response to that book was, 'That's great, Jeff and Josh. We'd love to work this way. My company won't let me work this way.'"
So we wrote "Sense and Respond," which was a book for leaders and aspiring leaders to inspire them to manage differently, to recognise that the overwhelming majority of businesses today are software businesses, and that managing software-based businesses is different.
As we began to work with that material and talk about that, we kept bumping up against the same ceiling, and that ceiling was incentives and goals. No matter how hard we tried to convince people to be customer-centric, to learn continuously, to improve continuously, to work in short cycles, they said, "That's great, Jeff. But I get paid to ship features."
The goal, the measure of success, was shipped – preferably on time and on budget. That's what got celebrated and rewarded, incentivised and promoted. It was in the job descriptions and all that stuff. So it felt like we were really fighting a losing battle.
Objectives and key results has been gaining momentum for the last decade or so. To us, that felt like the perfect Trojan horse – and I know Trojan horse has a negative connotation, but I don't think of it in this case as a negative thing. It was the perfect way to have a conversation about goals in a customer-centric fashion that, if applied in the way that we describe in the book, would enable everything else that we've done to happen more easily.
"What Will People Be Doing Differently?" – The Question That Changes Everything
Mat: I love the evolution of it, Jeff. I've been working in tech now for about 15 years. Prior to that, I used to work in the arts and special effects, which in itself is a very agile industry where you're constantly building prototypes and figuring out what things need to do before they go on stage or be filmed.
When I entered into the tech world as an inexperienced founder and product developer, I was designing to solve problems, and I found the teams I was working with responded really well to that. "What are we trying to do? What are we trying to get here?" They used to give me feedback all the time on whether I was helping them see far enough ahead with the value we're actually trying to deliver.
When I joined Atlassian in 2014, when we were introducing OKRs there, I think we were facing a problem that you described really well in the book, which is around people focusing on shipping their to-do list. They have a backlog that is predefined, full of great ideas, and they really want to get it out the door. Trying to change that conversation to be around "how do we know if this is any good?" – the answer was we just don't know.
I'd love to touch on how have you guided teams to move from that more traditional output-based metrics and shipping into that outcome approach? Maybe you could give an example of where that shift has led to some significant success.
Jeff: Sure. The title of the book is "Who Does What By How Much?" Overwhelmingly, the teams that we've worked on and with over the years have focused on delivering output, making stuff. The question that we tried to get them to understand is: if you do a great job – let's say when – when you do a great job with this feature, how will you know? What will people be doing differently?
That's the question that starts the mindset shift from outputs to outcomes. Outcomes, the way that we describe them, is a meaningful change in human behaviour that drives business results. The human that we're talking about is the human that consumes the thing that you create.
"The question is how will you know you delivered value to that human? Traditionally, it's been like, 'Well, we made the thing for them. There it is.' We made the Sharpie. Terrific. Did anybody need a Sharpie? Anybody looking for a Sharpie? How do we know? What are people doing now that the Sharpie is out there?"
The mindset shift starts with that question. Even in an organisation that just doesn't get this yet, it's a really safe question. I think it's a safe question to say, "Okay, we're gonna build the thing. What do we expect people to be doing differently once we ship this thing?" And when I say people, let's get specific about who. Which people? Who?
This is the evolution of the book title and how we teach this stuff. So what would people be doing differently before we start? Which people? Who? Okay, it's accountants in large accounting firms. Great. When we ship this new system to them, what are they gonna be doing differently than they're doing today? Well, they'll be entering their data more successfully and finishing their work in half the time.
Terrific. What are they doing? Who does what? And how much of that do we need to see to tell us that this was actually valuable? Well, today they're seeing at least a 30% error rate in data entry. Okay, great. What's meaningful? What's a meaningful improvement? If we cut that in half, that's a meaningful improvement. By how much?
All of a sudden, we've constructed the success criteria that has moved the team away from "we're building a thing" to "accountants in large accounting firms reduce their data entry errors by 50%." Who does what by how much. That begins the mindset shift in that conversation in a safe way because we're not saying let's set new goals, let's rewrite our incentives. We're just saying, "Look, I'm just asking a question."
Then once we start to build stuff, and especially once we start to ship stuff, you remember that conversation we had three months ago? We talked about who does what by how much. Is it happening? Do we know? Can we find out? And if it isn't, let's figure it out.
The Non-Profit That Changed Their Approach - From One Million Buses to Ten Iterations
Jeff: I'll give you an example. There was an organisation I worked with – I really loved working with them. They were a non-profit organisation that was looking to address major diseases in the developing world. They had three or four very specific diseases that they were targeting in very specific locations around the world, and I was thrilled to be working with them and helping them.
They managed everything with a task list. They were like, "We're gonna create this campaign and we're gonna put it on buses in China." And I was like, "Okay. How do you know that? So what? If the campaign works, what will people be doing differently?"
"Well, they'll scan the QR code that's on the bus."
"Okay, alright. And then what?"
"They'll sign up for an appointment to get a cardiovascular check."
"And then what?"
"For those who need actual care, they'll sign up for care."
"All of a sudden, we've taken 'put an ad campaign on a bus' to 'who does what by how much.' When we started to think about it that way, they fundamentally were rethinking the level of effort."
Because you might imagine, it was going to be one million buses and hope that it works. Instead, they decided, "Hey, we're gonna do 100 of these in one locality, and we're gonna give it a week, and we're gonna not only see what happens, but find out if people saw the ad, if it speaks to them, if they understood what it said. Then based on that learning, we're gonna iterate on the campaign."
So instead of getting one giant shot at this advertising campaign to drive people to take better care of themselves, now they're gonna get ten iterations. I think that was massively impactful in helping that organisation do better work and help more people.
Mat: I love how you're bringing that back to the experimental and iterative approach that people so often want but really struggle to get to. I've seen so many occasions where OKRs end up describing something that takes three, four, five months to build and ship, and they're only trying to measure the big outcome at the end, whereas what you're talking about there is breaking it down, making it far more iterative and experimental.
Jeff: Reducing your risk. Imagine this organisation had, let's say, £100,000 for this campaign. Traditionally, they would spend that whole hundred grand and hope. The reality is there's no need to do that. They could spend 10 and learn and do a better job with the next 10 and a better job with the next 10, and if they've de-risked it enough, take the last 50 and dump it on the thing that you've actually validated.
It's a de-risking strategy as well. You're increasing the value you're delivering and reducing the risk of spending money on stuff that isn't gonna work. Feels like a no-brainer, doesn't it?
The Reverse Five Whys - Asking "So What?" to Find Your Outcome
Mat: You make it sound like everyone should be doing it, which I agree with. There was something that you did in the middle of that conversation which I really like, and it's kind of like the opposite of the five whys. You know, where you see the problem and you ask why, why, why and you go back to the root cause. Whereas you took that in the other direction there.
Jeff: Right. We were moving forward in time for the desired outcome.
Mat: Yeah, exactly. You said, "Okay, you want to put this thing on a bus. So what?" And you took that three or four steps forward to get to that ultimate outcome. I love that, and that's probably a tactical, practical approach that our audience can take.
I think some of the stuff that I've struggled with over the years is getting teams who are new to OKRs to understand how to move from writing their to-do list, writing their backlog, turning that into their key results, and actually getting it into the outcome base. I think that's one of the things that a lot of teams find hardest to grasp.
Jeff: And as I kicked off with, if your entire career you've been rewarded for shipping and producing and ticking off a to-do list, then it's really hard to break away from that without some form of leadership buy-in. That's coming back to that incentives and performance management criteria side of things. That's really hard because that's what people optimise for.
We can preach outcome-based work until we're blue in the face, as they say in America at least. But if you're paid to ship product, you're gonna optimise in most cases for what gets you paid. That's an important component of this that I think gets ignored a lot.
Two Audiences, Two Approaches - What Should Teams and Leaders Do Differently?
Mat: Let's talk practically around this. We're probably going to have different people listening to this. We could probably give two bits of advice. One is somebody who's in a team and they really want to try this, or maybe they've been trying this and struggling because the incentives don't match. The other group may be someone who's in leadership who is trying to change their organisation to move into this more outcome-based approach. What advice would you give to each of those people?
Jeff: Great question. Let's start with the folks trying to make this happen initially. In my opinion, one of the easiest ways to move this conversation forward in your organisation is to ask that question I mentioned: What will people be doing differently when we ship this?
Have that conversation. Position it any way you'd like, word it any way you'd like. But ultimately, you're not challenging the work. You're not saying "I'm not gonna do the work." You're not pushing back yet.
"All you're saying is, 'Look, we're gonna build this thing, and we're gonna do a great job. What do we hope people will do with this once we have it out there? What are we trying to see? Are we trying to see them increase average order value? Do we want them to abandon their shopping carts less? Are we trying to get them to sign up for a medical check-up at least once a year?'"
That starts it. That starts getting people to think about more than just "I am making a thing."
Mat: If you took that to leadership and said, "Yeah, we're gonna get this stuff out the door, but I want to check with you that you're happy that this is the outcome we're trying to get to, that this is the result if we get it right."
Jeff: I think that's great, and I think that you should come back to them after you ship and say, "Look, remember we met three, six, nine months ago and I said we're building this and we're hoping people will do this? Well, we built it as designed, on time, on budget, and so far we're not seeing the results that we anticipated. We talked to some customers, and here's why we think that is. What we'd like to do next..."
To me, that should be a safe conversation inside your organisation.
Mat: I can imagine people listening to this and getting some cold sweats at the concept of going to someone and saying, "I did everything that you expected from me, but it wasn't good enough."
Jeff: It's not that. What tends to happen in these situations is a lot of upfront planning and commitments, and then we execute. Regardless of all the work that people have done to convince people that there are better ways of working, that's generally speaking how people are doing work still. We did the thing, and guess what? It didn't work. It didn't work as we had hoped. It's not because we built it poorly. It works as designed. We did usability testing on it. People can use it, they can get through the workflow.
What we think is it's not solving a meaningful problem, or we decided to put it somewhere in the workflow that didn't make sense, or whatever the case is. I understand it's not a risk-free conversation. I'm not encouraging people to do things that are career-limiting per se, but at some point we've got to talk about this kind of stuff. Otherwise, we're just a factory. I don't think anybody wants to work in a factory.
It's Not About the Quality of Your Code, It's About Learning
Mat: I couldn't agree more, and I think that the heart of what I spend a lot of my time doing is helping people understand how to get the benefits out of being agile, that agility piece. What we've been discussing there is that key part of learning. You can plan and you can build, you can have alignment on those things, you can improve how you're building all the time and reach quality standards and pass usability testing. But ultimately, if you don't learn, you're never gonna get the insight that you need to adapt what you do next.
"Where a lot of people fall down with agility is they go through all of the motions up to that point, and then through fear, self-preservation, or they've just not seen anybody else around them do it before, they hesitate to say, 'This thing that we've all invested all this time and effort into isn't working as expected.' It does take some courage to do that."
Jeff: It does. I agree. But it's an evidence-based conversation. It's not "we did a crap job." We didn't. It's bug-free, it's high performance, it's scalable, it's usable. But you can build products like that – there are infinite stories of products that were amazingly executed that didn't meet a need, didn't solve a problem.
Mat: Yeah, I built one of those and had to close a business for it, so I know that all too well. If there's a lesson I learned through the years of doing that, which you touched on earlier, it's around by focusing on the outcomes that you want to see, those behaviours you want to change, and bringing the work down, de-scoping the work to start to experiment and iterate, you de-risk all of that. You'll learn a lot earlier whether you're on the right track or not rather than getting that big bang at the end.
Jeff: Yeah. Again, you're reducing the risk of building something that people don't want. Let's just use round numbers because they're easy. If you have a million-pound budget to build something – a new product, a new feature, a new service – and you spend 100 of that million and find out that this isn't the right thing to make, it's not a real problem, for whatever reason, you've just saved the company £900,000.
They should hoist you up on their shoulders and sing your praises, parade you around the halls. That's how it should be. You're a hero, and now we can take that £900 and do something that actually will deliver value with it.
If You're a Leader: Stop Asking "When Will It Be Ready?" and Start Asking "What Are You Learning?"
Mat: The second half of that question was around if you're a senior leader in an organisation and you want to move to an outcome-based approach, maybe you start with celebrating the people who are trying to do that and positively reinforcing it in that way. But what advice would you give that person?
Jeff: Absolutely. Celebrate anybody – literally hoist them up on your shoulders and parade them around the halls and say, "Look, this team tried this, figured out it wasn't going to work, and pivoted, and saved the company a million pounds." That should be a regular conversation and a regular thing that the company celebrates.
What's interesting is that you can find yourself on a team with resistant leadership, and you can also find yourself in leadership with resistant teams. And for a variety of reasons, not the least of which is that they've never actually been allowed to work this way and don't believe you that you're gonna let them work this way.
"Without getting caught up in too much process or training or dogma, I think as a leader you start to soften the conversations around this stuff by changing the questions that you ask."
Normally, it's like, "Hey, what are you guys working on? When will it be ready? How much is it gonna cost me? What do you predict the ROI is gonna be?" That's a typical line of questioning for a product team.
Conversely, you can say, "Hey, folks. What are you learning this week? This sprint? This quarter? What did you learn?" You might get a bunch of blank stares initially. They'll say, "What do you mean, what did we learn? We're building what you told us to build."
"Okay, well, cool. Next quarter when we meet, I'd love for you folks – I'm gonna ask you this question again. What did you learn this quarter about the product, about the customer, about the value of the thing that we're delivering? If you don't know how to answer those questions, I can help. I can get training for you. I can get some folks who've done this in other parts of the company to show you how they're doing this work."
To me, you're not enforcing. One of the issues of organisations just mashing process on top of organisations is folks don't understand why. Why are we doing this, and how is this supposed to make anything better? One of the ways to ease folks into a different way of working is to change your expectations of them and make that clear to them.
Instead of saying "What are you building? When will it be ready? What's the ROI?" say "What are you learning? Are we doing the right thing? How will we know?" And then if they don't know how to get the answers to that, don't make them feel stupid. Say, "Look, I'm gonna help you with that. I'll show you how the other teams are doing it. I'll get you some training. We'll work on this."
That's super powerful because you're changing the expectations that you have for your team, and you're making it explicit to them.
Navigating Conflicting Forces - Outcomes vs. Predictability
Mat: I've got this image in my head of people in a large organisation where they're on this journey that you've described with their team. Maybe they're a leader somewhere in the middle of the organisation, working with multiple teams, and they're starting to see some progress. The teams are on board, they trust that the questions you're asking are genuine and authentic, and they really want to understand the outcomes.
They're starting to come back with great questions themselves around who does what, what's the behaviour we're trying to change, how are we trying to change it, are we successfully doing that or not. Whilst that starts to get some traction and momentum, at the same time this leader's got other people in the organisation – maybe some more traditional executives who are getting investors on their boards asking for their KPIs to be met and the efficiency and the predictability they expect so they can forecast.
They have jobs to do themselves, and they seek some predictability. How do you help guide that person to navigate those two conflicting forces?
Jeff: It's hard. I've seen it multiple times. I think there are a couple of ways to navigate those political challenges in an organisation. One is you have to model the behaviour that you want to see both in your teams and in your colleagues as well.
Every interaction that you have with your peers at leadership level should contain these types of conversations around the customer, around learning, around value, around risk mitigation, and continuing to model the behaviour you want to see.
Someone says, "Well, we just have to build the iPhone app."
"Okay, great. But why? Why do we have to build the iPhone app?"
"Because we have to increase mobile revenue."
"Why? What is it today? What are we hoping to get?"
The Power of Renaming Teams
There's a super simple trick I wrote about probably a decade ago. If you're in a leadership position to get the organisation to start to think differently about how to do work, it's simply changing the names of the teams.
For example, let's say you and I work on the iPhone app team. What's our mission? Build an iPhone app. Exactly. So that's the iPhone app team, and that's the CRM team and that's the Android app team, whatever.
"What if we change the name of that team? Same team, same people. But it's the mobile revenue team. All of a sudden, the purpose of the team has fundamentally changed. It's no longer 'build iPhone app.' It's 'increase revenue through the mobile channel.'"
That might be an iPhone app, might be an Android app, might be a better website, might be a million different things. But from a leadership perspective, one of the things that you can influence is the name of these teams, and how you name them determines what work they do. That's really powerful.
Prove the Model
The other thing that you can do as a leader is prove the model. There's a lot of "my idea is better than your idea" type of conversations at work. Instead of saying, "I think we should work this way," say, "Look, I've got a pilot team in my group that's been doing this for the last three months. Here's what the team looks like. Here's the work that they're doing. Here's how they work. Here's what they're producing. Here's their happiness score. Here's their productivity. Here's their efficiency. Here's the impact of the work that they're doing with the customer."
If you've got one or two of those teams working that way, that's a compelling argument for saying, "Look, let's give it a shot." You've got the evidence that says this is a better way of working. Proving the model is always a good way to go.
Team Autonomy and Empowerment
Mat: One of the things that I'm picking up on in what you're saying leads to an outcome within teams that I've seen – around autonomy and empowerment within teams. Something I'm always trying to do in my role in organisations is make myself redundant. If the team don't need me anymore, I've done my job.
I'm at work where I've been very clear with the rest of the leadership team: I'm getting involved in way too many decisions, and I need to remove myself from those decisions because I'm slowing us down. If I have to have all of the context to be able to get involved with that and help move us forward, then we're gonna go slower than we should.
We're very quickly removing me from decisions, and it's been a great journey. Terrifying for me because I don't know as much about what's going on. But I'm seeing the teams themselves equipped with questions like "who does what by how much?" – that's one tool around the OKRs. Also equipped with other tools and ways of working, and usually it comes down to: are they asking the right questions? Are they applying the level of critical thinking to achieve those outcomes?
"Ultimately, if we can get teams to be more autonomous, leaders have a much better time of scaling themselves without burnout, without having to get really drawn in. When teams make decisions when you're not in the room that are fighting to achieve the outcome that you also want to achieve, that's when you really start to move quicker. That's when you start to really see the benefits of agility."
Have you got any thoughts on that that you'd like to share?
Jeff: It's a really tough sell. I see it all the time because I think that leaders have defined themselves – I don't want to speak in absolutes, so the majority of leaders have defined themselves in a way that says, "I tell people what to do." That's my job.
If you ask any kid – 10 years old, 12 years old, 9 years old – "What's a boss?" they'll say "A boss is someone who tells people what to do." I think we grow up with that, and I think leadership canon for the last hundred years has roughly said that, with the exception of the last 20 to 30 years where we've seen a lot of agile-themed, agility-themed leadership books and materials come out.
Still, I think the overwhelming majority of people believe that it's their job when they're in a leadership role to tell their teams what to do and to be keenly aware of every little detail. Because what if my boss comes to me and says, "Hey, what are your teams doing?" If the answer is "I don't know," that's probably a bad answer.
I agree with you. Day-to-day decision stuff – who better to make that decision than the teams doing the work day to day? They know far more about it than I do. They're with the work every day, they're with the customer every day, they're getting the feedback.
There's no reason for you to run these tiny things past the leader every day. It's exhausting for the leader, as you said, and the team knows more about it. Big strategic shifts, invalidated hypotheses, radical shifts in the market, new competitive threats – absolutely, let's talk about that.
The Two-Way Solution
I think there's a two-way solution here. Number one, leaders need to let go a little bit and understand that the most qualified people to make decisions about the day-to-day trivial stuff are the team doing the work.
David Marquet said this in "Turn the Ship Around." He ran the worst-performing nuclear submarine crew in the American Navy and turned it around to the best-performing crew. Basically, what he said was he pushed decision-making down as close to the work as possible. The only decision he kept for himself was whether or not to launch a nuclear missile, because people are gonna die and he didn't want that on anybody. That's his job as the leader.
Same thing here. You're gonna push decisions all the way down, and we've got to get folks to think about that.
Demand Proactive Transparency
To make that easier for people to swallow, people who are not used to this way of working, I think we have to demand greater proactive transparency from the teams.
Teams love to play the victim. "They don't let me work this way. My boss won't let me work this way. My boss doesn't get agility, doesn't get customer-centricity. She just comes down here and yells at us."
"What if on a weekly basis, without being asked for it, you sent your leader three bullet points in an email every week? Here's what we did this week. Here's what we learned. Here's what we're planning on doing next week."
If there's anything significant, you're gonna put that in there as well. But otherwise, just those three things. You're not even asking for a response. Weekly update, three bullet points, 15 minutes max of effort on your part.
In my opinion and in my experience, what happens is leaders chill out. Because all of a sudden they know what's going on. They see that you're doing work, that you're making objective decisions, and that you're taking the time to keep them informed. When their boss comes to them and says, "Hey, what are your teams doing?" they can just look at that email and be like, "This is what Mat's team is doing, this is what Jeff's team is doing."
To me, if there's a role here – and it's not an insignificant one – for the teams to play to improve their ways of working or to improve the comfort level that leaders have with new ways of working, this is it.
Mat: I have had the privilege of being someone on the recipient of those equivalent three-bullet-point emails running 12 different product teams, trying to understand what was going on. You're right – the stress levels go down when you understand proactively what's going on. It became the first thing I would do on a Monday morning knowing I had all that information.
It was something that teams were doing as part of their own weekly reviews as a team, and they just captured it and shared it. So there's no extra work for them. But it made this huge difference of suddenly I could understand where did I need to actually spend my time to help, rather than trying to chase and get information or get too close into managing people who didn't need it because they had it in hand.
I was able to prioritise and think, "Oh, that team looks like they're struggling, so we're gonna go and ask them some questions, see how I can remove some blockers for them."
Jeff: And if there is a blocker, add it in there. "We've been trying for three months to get access to customers. The sales team keeps blocking us. Can really use your help here."
The Shift from Being Rewarded for Knowing to Being Rewarded for Learning
Mat: There's a thing I've observed over the years – it takes a while to get there before you actually start getting rewarded for it in most organisations. In forward-thinking, very agile organisations, it starts a lot earlier, and I think that's something I'd like to try and shift left, try and get it earlier in people's careers.
It's this shift between: spend your entire career being rewarded for being knowledgeable, for being the expert, and knowing how to do something. You get promoted for that, you'll get a bonus for that, you'll get rewarded for it time after time. The more you learn, the more capable you become, the more experienced you are, you've got the answers for everything, you get promoted. You work your way up the career ladder.
Then you hit this tipping point where you hit a level where you realise there aren't many people around you at that point who are seeing the problems. Everyone's busy, everyone's focused on their thing. Then you realise that actually it's your job to call out that this thing isn't working. It becomes your responsibility to say, "There's a problem here we need to address as a company, as an organisation."
As an exec – Nick Muldoon is our CEO – we have an exec weekly, and the majority of that conversation is each of us saying what we don't understand, what we don't know, what we haven't figured out yet. We trust each other that all the rest of it's in hand and working beautifully. The things we really want to talk about is what don't we understand and what are we learning or what are we seeing that we need to try and figure out what to do with.
I see people struggle with that transition if they've not started it earlier in their career. Going back to the basics around sharing the learnings and are we actually achieving what we wanted to, are we seeing the behaviour shift, are we seeing it measured – if we're saying no, having the freedom to be able to call that out earlier, I think it makes that transition in life a lot more straightforward.
Jeff: Look, there's a level of seniority, and the subtheme here that we are dancing around but haven't yet named is psychological safety. It's this feeling that I'm comfortable calling things out that are against the grain, that contradict the plan, that are not working, and I keep seeing and nobody's addressing.
"I think there's a level of seniority that brings some psychological safety. But ultimately, organisational culture has to make it safe."
In other words, if leaders like you and your leadership team are consistently curious – "What do we not know? What are we not aware of? What's not working?" – your teams are going to feel comfortable calling those things out to you because you're asking those questions.
When they change the questions that they ask, it models psychological safety. It models the kinds of questions they want their teams to ask, and that's how change starts.
Building Psychological Safety - "If You Don't Know How, I'll Help You"
Mat: I couldn't agree more, Jeff. I think we've covered a lot of ground today, and psychological safety is one of those really hard intangible things for some people, particularly if they've never experienced it. We see it when we get new people joining our team. We're in a privileged environment where we have a lot of psychological safety.
When new people join from organisations that haven't had that, their behaviour is almost fighting against it. They hold on to their protected ways of working where they get a little bit territorial and they don't want to be vulnerable. It can take a good few months for people to settle in and relax into it.
There was a piece that I want to go back to, and maybe we wrap up on this. You talked earlier around a leader talking to their team and asking them questions to help them understand that it's okay to come back and say, "This thing that we've been developing, this product that we've been getting out the door, isn't having the desired impact." To look at it, question it, be curious, and come back to it.
The thing that you touched on there which I really love was that supportive nature of it. It's okay to do this, and if you don't know how to do it, I'll help you. If you were to give one last tip to our audience – how would you encourage people, leaders specifically, to move more into that space?
Jeff: I think it's a question of asking the right questions. I've been married a long time – half my life, it turns out. I did the maths the other day. If I've learned nothing in my 20-plus years of being married, I've learned that you don't start out immediately solving the problem. You listen and you ask questions. I've learned that. It took a long time.
I think that's our nature as leaders as well. The tendency is "let me solve that for you." Well, hang on. Before you jump to solutions, dig into the problem. What's the issue here? What's the problem? How can I best help you?
"Well, listen, we've set these customer-centric goals now. We've got great OKRs. Thanks for teaching us how to do that. Normally though, we're told what to do, and no one's telling us what to do now, and we don't know what to do. We have no idea how to figure that out. In the past, people have told us. Now I don't know what to do. Can you help us? How do we figure that out?"
To me, those are the kinds of answers you want to elicit from your teams. What's actually going on here?
This is where five whys comes in. "Well, you know, we keep hearing that we should be talking to customers. The reality is it's really difficult to get to our customers."
"Why is it difficult?"
"Well, because we're in a B2B space and we sell aeroplane engines."
"Okay, great. And why does that make it difficult to reach customers?"
"Well, because we have a sales team."
"Why does that make it difficult?"
"Well, because they guard their contacts and they don't want us messing with it."
"Okay, now I understand."
"I think if it's about asking the right questions as a leader, and then when you get to the root cause, you say, 'Well, listen, I can try to unblock it in this way. Do you think that would be helpful? Yes or no?' That becomes far more of a partnership than a hierarchical relationship."
Then you trust me to be honest with you about how well things are working and where things need help, and that's tremendous.
I run a very, very tiny business in the sense of number of people – it's three and a half people total. Even in a three-and-a-half-person business, people try to do good work and people don't want to bother you with what's going on. Sometimes people get overwhelmed, whether it's with work or personal stuff or a combination of the two, and then things start to slip.
The more you can foster that kind of transparency and trust, psychological safety, the less you find out that something is broken with the consequences of it being broken. You find out well in advance of anything actually happening.
Mat: I love that, Jeff. I think that's a great place to wrap up. I'm really grateful for your time, really enjoyed the conversation, and thank you for sharing your wisdom.
Jeff: My pleasure, Mat. Thanks so much for having me. This was fun.
---
Thank you to Jeff Gothelf for joining us on this episode of the Easy Agile Podcast. To learn more about Jeff's work and get your copy of "Who Does What By How Much," visit jeffgothelf.com. You can also find his other books, including "Lean UX" and "Sense and Respond," which provide the foundation for the customer-centric approach to OKRs discussed in this episode.
Subscribe to the Easy Agile Podcast on your favourite platform, and join us for more conversations about agile, product development, and building better teams.
- Podcast
Easy Agile Podcast Ep.4 Em Campbell-Pretty, CEO & Managing Director at Pretty Agile
"We spoke in detail about scaling agile, being a SAFe fellow, discipline, the traits of effective leaders and how to trust your people."
Transcript
Nick Muldoon:
Good day, folks. Thanks for joining us for another Easy Agile Podcast. This morning, I'm joined by Em Campbell-Pretty of Pretty Agile. Em is one of 22 SAFe fellows globally and she's been doing agile transformations at scale for over a decade now. She's also the author of two books, The Art of Avoiding a Train Wreck and Tribal Unity. So, all about culture and psychological safety here, and all about obviously scaling agile release trains, tips and tricks.
Nick Muldoon:
My key takeaways that I was really jazzed about, the traits of effective leaders for scaling agile transformations and being an effective organization, trust, as in trusting their people, an openness to learning and a willingness to learn, the ability to experiment and treat things as failures if they are failures, and discipline. Em and I talked a bit about discipline today as a trait of leaders. It's a really great episode and I took a lot from it, and you'll hear my takeaways at the end and what I need to go and learn after some time with Em this morning. So, let's get started. How many weeks a year are you typically on the road?
Em Campbell-Pretty:
How many weeks a year am I typically on the road? A lot, most. It would be unusual for me to spend four weeks without going somewhere. That would be unusual. I don't travel every week, but I travel most weeks, and I travel in big blocks. Right? So, I'll go and do ... Like I said, just before the lockdown, we did three weeks in Auckland, so that was in February-March.
Em Campbell-Pretty:
We went to Auckland, we had a client in Auckland, we just stayed there. So, three weeks in Auckland, came back here, and did not return to Auckland. Returned to support that client virtually over Teams and Zoom was how that one went. But yeah. Normally between running around Australia, Southeast Asia, Hong Kong, Singapore, Manila, the US, New Zealand, yeah, not home that often, normally. This has been truly bizarre.
Nick Muldoon:
So, this is a very unusual year for someone like yourself that's flying around visiting clients all over the world.
Em Campbell-Pretty:
Absolutely. Absolutely. It's been a very strange year. It's an interesting difference on energy as well. Not flying all the time I think is good for my body. I feel the difference. I also feel the difference sitting in a chair all the time. So, I was traveling a lot, but I was on my feet most days when I was working. Now if I'm working, I'm sitting a lot.
Nick Muldoon:
You're sitting down. Yeah.
Em Campbell-Pretty:
So, that's interesting. But I don't miss the jet lag at all. I don't miss the amount of time the travel consumes at all. In fact, it's been nice. I've had a little bit of head space. I've probably blogged more this year than I have in a few years because I've just had some head space and being able to think. But I don't get to see the world either, and all my holidays got canceled. So, nevermind work. I had trips to Europe. Four weeks from now, I was supposed to be in Canada seeing polar bears.
Nick Muldoon:
Aw.
Em Campbell-Pretty:
Tell me about it!
Nick Muldoon:
I would love to see polar bears. They look so cuddly on TV. I'm not sure that that would actually be the circumstance if I was to try to approach one and give one a cuddle.
Em Campbell-Pretty:
Yeah. I don't think cuddling was involved. I was told I could bring a camera and a tripod, which means obviously I'm going to stand some distance away from this polar bear and take photos. But that will not be happening either. So, no holidays and no travel for work, and of course, being in Melbourne, not even any, let's just go to [crosstalk 00:04:15].
Nick Muldoon:
Coffee or anything like that.
Em Campbell-Pretty:
Just nothing.
Nick Muldoon:
Nothing.
Em Campbell-Pretty:
Nothing.
Nick Muldoon:
Yeah, because you've been on legit lockdown.
Em Campbell-Pretty:
Yep.
Nick Muldoon:
So, tell me then about the shift over the last 10 or 15 years in these scaled, agile transformations. Obviously today, like you described with this client in Auckland, everything's got to be remote. Presumably, not as effective. But I'd love to get a sense of what the evolution is from the transformations 10 years ago, banking, telcos, that sort of environment to the clients that you're working with today. Describe what it was like 10 years ago.
Em Campbell-Pretty:
So, 10 years ago, and it's so interesting to reflect on this now, I read Scaling Software Agility, which is a book that Dean published in 2007. Then I discovered that wasn't the latest book, so then I read Agile Software Requirements. This was 2011. I'm this crazy, angry business sponsor with this program of work I'd been sponsoring for five years that's never delivered anything, and in this cra-
Nick Muldoon:
You were the crazy, angry business sponsor?
Em Campbell-Pretty:
Yeah. Yeah, yeah. I was the crazy [inaudible 00:05:26]. I was very angry. You would be angry too if you were me. I refer to it now as the money fire. So, basically, here's my job. Right? Go to the CFO, ask for money. Give the money to IT. IT lights a match, sets it on fire. Comes back, asks me for money. I get to go back to the CFO and say I need more money. Five years. Five years. That's all I did. Ask for money and try to explain where the other money went.
Em Campbell-Pretty:
Anyway, in the strangest restructure ever, I end up the technology GM for the same group I had been the business sponsor of for the past five years. Apparently, they couldn't find anybody appropriately qualified. So, you can do it, Em. Sure. So, I'm a bit of a geek, so I read books, and I'm reading these books by Leffingwell because I'd been doing some agile ... So, I'd been doing something I'd been calling agile. Let's just go with that.
Em Campbell-Pretty:
It was interesting to me because I could see little rays of light. But it still wasn't really making anything happen, so hence the reading. These books talk about this agile release train [inaudible 00:06:46] that sounds cool. We should so do this thing. So, I set about launching this train at a Telstra in early 2012. It wasn't called SAFe, right? It was just the books and these things called an agile release train.
Em Campbell-Pretty:
Now, to look back 10 years ago, it wasn't called SAFe. People weren't running around doing this. I was not actually really qualified for the job I was in. Well, I wasn't a technology leader by any stretch of the imagination, and I decide that I'm just going to launch an agile release train. So, there were rare and unusual beasts, and I'm not sure I really understood that when I went down the path of doing it.
Em Campbell-Pretty:
I'm big on the, I read it in a book, I read it in a blog, I heard it at a conference, I'll just try it. That's very much always been my mental model. So, I read it in a book and I just tried it. Then we discover that actually, literally nobody is doing this, so it becomes Australia's first agile release train and Australia's first SAFe implementation. Oh, boy, have I learned a lot since then.
Nick Muldoon:
Well, yeah. I was reflecting on that because I dug out The Art of Avoiding a Train Wreck, right? This is one of the ones that you signed for Tegan. But obviously, you've learned a ton since then because you've managed to put together a tome of tips and tricks and things to avoid as you are pursuing these transformations. As an industry, though, well, as an industry, I guess this spans many industries, but as a practice these days, are we actually getting better at these transformations? Are there companies out there today, Em, that are still taking piles of money and setting it on fire?
Em Campbell-Pretty:
So, I think I meet people every day who hear my story and go, "Oh, my god. You used to work here?" So, I think there's still many, many organizations that have an experience that is like the experience I had back in 2010 and what have you. So, it seems to be something that really resonates with people. I guess so many of the businesses we go into now either are not agile at all or, I guess like my world was, doing something they call agile. What we find is the something that they call agile, I wouldn't say it's not agile. But it leaves a lot to be desired.
Nick Muldoon:
They're on a journey, right?
Em Campbell-Pretty:
Yeah. Yeah. Well, I guess so because they end up having a conversation with us. So, they understand that what they're doing is not enough. They understand that what they're doing isn't getting them the results that they want. I don't know that they understand why. It's interesting to me sometimes that they look to SAFe because you asked me about how's the client base changed? One of the things that's really interesting in Australia is we get far more of the small to medium sized companies now than the big ones.
Em Campbell-Pretty:
So, they're companies that consider themselves agile. But what we're calling them, the startups that are no longer startups, right? These are organizations that they're generally old 10, 20 year old startups and they're scaling and they see their problem as a scaling problem. So, that's what leads them to a conversation around the scaled agile framework.
Em Campbell-Pretty:
When we look at them through a SAFe lens, we go, "Gee, you're tiny. But okay. I can see that you can have an agile release train and it won't do you any harm. In fact, it would probably help you a lot in terms of mid-range planning," because mid-range planning just seems to be nonexistent for a lot of these organizations. Prioritization. A lot of these small organizations, very knee-jerky in terms of how they prioritize, bouncing from one thing to the other.
Nick Muldoon:
Are they reacting to the market, or are they reacting to the leaders, maybe the lack of discipline in the leadership?
Em Campbell-Pretty:
You know what? They would say they're reacting to the market. I would say they've got a discipline issue.
Nick Muldoon:
Yeah. [crosstalk 00:11:23].
Em Campbell-Pretty:
So, I read, obviously, big reader, last summer, obviously Australian summer, US winter, I read Melissa Perry's The Build Trap. Interesting book and your well respected thought leader in product management. Not a big fan of SAFe. Probably not a big fan of agile either was the takeaway I had from her book. But the thing that she does talk about that I really thought was valuable was the lunacy in chasing your competitors. So, building features because your competitors-
Nick Muldoon:
Your competitors [crosstalk 00:12:06].
Em Campbell-Pretty:
... build them, or building features to land a contract or retain a customer. So, I thought she sees all of that as lunacy, and I tend to agree. So, that was my ... I think that's quite interesting. Her perspective is you don't know if the competitor's actually having any luck with that thing that they've built. So, if you build it because they built it, you don't know. You have no idea. So, don't just build it because they've built it. It might not be doing them any favors either.
Em Campbell-Pretty:
Of course, once you start just doing random stuff for this big customer or this big client, you start to lose your way as an organization. People end up with completely different versions of their products, branches that they can't integrate anymore. It's interesting. So, when I look at that, I go, "I feel like there's a discipline issue in some of these organizations at the leadership level."
Em Campbell-Pretty:
What is it we're trying to do? What is our vision? What is our mission? What is our market? What are we doing to test and learn in that market, as opposed to just get a gun, let's do everything, grab everything? Oh, my goodness. They were doing that over there. Stop this, start this, stop this. Of course, if you're stopping and starting all the time, you're not delivering anything, and that seems to be something that we see a lot with these organizations. They're not delivering.
Em Campbell-Pretty:
I'm not saying their delivery mechanism is perfect. There's challenges there too. But some part of the problem is the inability to stay a course. Pick a course and stay a course. I'm not saying don't pivot, because that's stupid too. But being more deliberate in your choices to pivot, perhaps. Yeah.
Nick Muldoon:
Do you get a sense, Em, that there are leadership teams in various geographic regions that are more effective at this and more effective at that longterm planning and having that discipline and that methodical approach to delivery over an extended time period?
Em Campbell-Pretty:
I think regions and cultures and nationalities certainly play a role in the leadership, I don't know, persona, personality. I don't know that I could say when I've worked in this country or this part of the world that their leaders are better at forethought. I think some cultures lend themselves to lean and agile more than others. Hierarchical cultures are really, really challenging.
Em Campbell-Pretty:
That can be both a geographic thing, but it can also just be an industry thing, right? So, government can be very hierarchical. The banks can be very hierarchical. Some of the Asian cultures are very hierarchical. But some companies are just very hierarchical as well. So, who owns the company, who leads the company, all of that can play a big role in what's acceptable because so much of success in this scaled agile journey comes down to a leadership that is willing to trust the teams, a leadership that is willing to learn, a leadership that's willing to experiment, and a leadership that's prepared to be disciplined.
Nick Muldoon:
So, leadership with trusting the teams, willing to learn, willing to experiment, and with discipline. They're those four things that you-
Em Campbell-Pretty:
Yep.
Nick Muldoon:
Yeah, okay. I'll make a note of those, Em. I'll come back to those. Trust, learn, experiment, and discipline. I'm interested, I guess, this year being a very interesting, a very unique year for doing remote transformation work and coaching and consulting, 10 years ago, what was the percentage of remote team members distributed teams? Now, you've basically, I think the big banks in Australia aren't even going back to the office until 2021. Atlassian is not going back to the office until 2021. Twitter, Jack Dorsey, my old CEO, said, "Work from home forever," sort of thing. What's the takeaway for this year and what do you expect for 2021 and beyond?
Em Campbell-Pretty:
So, look. This year has been eyeopening, and look, some things are, as I would have anticipated, some things have been different. So, obviously, we're seeing entire organizations going online. We're seeing the teams are online, the PI planning's online, everything's online. That's actually in some ways opened up opportunity. So, where we've had clients who have had the most odd setups in terms of distribution, and you can make a train work where you've got teams across two locations. But we're big fans of the entire team is in Sydney or the entire team is in India. We don't have half the team in Sydney and half the team in India.
Em Campbell-Pretty:
But organizations really struggle with that because perhaps all the testers are in India and then you want a tester on every team and now you've got a problem. How do you create a complete team and not cross the time zones? So, the opportunity becomes if I can find teams that are not physically co-located but time zone friendly, I have a little bit more option. So, I can have a train that operates between, I don't know, Sydney and India. Or I can find a four hour overlap in their day, and I can insist that that team works 100% online.
Em Campbell-Pretty:
So, the big thing that we'd advise against is I don't want that team hybrid. Right? I don't want three people sitting in the office in Sydney and three people sitting in their homes in India. I want everybody online. I want an even playing field, and I think we can do that now in a way that is more acceptable than before. Because the same advice I was giving, gee, back when I wrote Tribal Unity, same advice. Right?
Em Campbell-Pretty:
So, 2016, everybody, equal playing field. If you're going to be distributed, everyone has to be online, as opposed to some people online and some people in a room. So, that's a more acceptable answer now than it was prior to this year. So, that's good. I think that's good.
Nick Muldoon:
In 2021, then, Em, you mean this is just going to play forward. I guess there's going to be a reversion of some of these companies back to the office because they've got huge real estate and workplace infrastructure already.
Em Campbell-Pretty:
Yeah. So, look. We're seeing clients closing offices the same way that you see some of the companies in the US doing that. We're also seeing parts of Australia and New Zealand with no particular COVID impact at this point actually going back into the office, and having created that example of teams that are crossing time zones, and then going back into the office and going back to that hybrid space. So, that's interesting and [crosstalk 00:20:08].
Nick Muldoon:
So, where you're back into that environment where you might have some people working together in an office that can get a cup of coffee together and then some that are stuck still at home. I guess there's not just even regional differences, right? If you've got a team member that's got a particular health situation, they're not going to feel comfortable necessarily coming back into the office, regardless of the situation, until there's a vaccine or something.
Em Campbell-Pretty:
Absolutely.
Nick Muldoon:
Yeah, okay.
Em Campbell-Pretty:
So, yeah. Look, I think it's going to be interesting. I would strongly advocate that organizations have teams that are either in person teams or online teams, and the team just either operates 100% online or the team operates 100%-
Nick Muldoon:
In the office.
Em Campbell-Pretty:
... in person and in the office, and if you have a train that has both in any train level ceremony, everybody goes to a desk and-
Nick Muldoon:
And do it online.
Em Campbell-Pretty:
... a video camera and we do it that way. I think the thing that seems to be most sticky about the physical environment and SAFe is PI planning. Nobody needs to beat. Right? That was cool. Nobody needs to beat, no one's PI planning slipped, everybody just went. They were all online. So, we'll just PI plan online. It'll be fine. We saw people use whatever infrastructure they had available to them.
Nick Muldoon:
Yeah. [crosstalk 00:21:30].
Em Campbell-Pretty:
So, I'm sure a number of people called you folks and said, "We need a tool." But some just went, "We have Google Suite, we have Microsoft whatever it is, we have this, we have that. We're just going to make it work," and no matter what they used, they made it work and they ran the events and their events were effective and they got the outcomes. The big thing that is missing is that energy. You can't get the energy of 100, 200 people in a room from an online event. But mechanically-
Nick Muldoon:
We can achieve it.
Em Campbell-Pretty:
... we can achieve it. So, we hear everybody wants to go back to PI planning in person because of the social, because of the energy, which I think is awesome. I absolutely think that is awesome, and I can see this world in which people do a lot more work from home, work remote, whatever that looks like, and then the PI planning events are the things that we do to bring ourselves together and reconnect on that eight, 10, 12 week basis. That's my feeling. Could be wrong.
Nick Muldoon:
I guess I'll be really interested to see how it plays out, and I think we should return to this conversation in 12 months, Em.
Em Campbell-Pretty:
Yeah. Oh, no.
Nick Muldoon:
I'm just thinking, what's going through my mind is one of our customers in New York, financial services company, and for one of their arts, it was 150,000 US exercised to bring their people together once a quarter.
Em Campbell-Pretty:
Yeah. Wow.
Nick Muldoon:
I'm now going, I'm like, "Okay, yes, they're doing it digitally now." That's fine. They're going to miss out on things. But if they lose the budget, do they have to fight to get the budget back? Or does the budget sit there? There's these other unknown ramifications of this shift over the course of 2020 that we're yet to see play out, I guess.
Em Campbell-Pretty:
I think you're right, and I think it would be particularly interesting for the trains that have been launched remotely. So, if the train has been launched remotely, do you ev-
Nick Muldoon:
So, not existing trains that have been working together for six to 12, 18 months. But you want to get a brand new train started. Have you done that remotely this year with some of your clients?
Em Campbell-Pretty:
Oh, we're in the process of doing it now.
Nick Muldoon:
Cool. Tell me.
Em Campbell-Pretty:
We had one, though, literally just before the lockdown. So, they did their first PI planning face to face and then immediately moved to remote working and, yeah, now working on remotely launching a train. For us, we have a playbook. It's a bunch of workshops. It's a bunch of classes. We just use online collaboration tools. We've found things that replicate the sort of tools that we would have in a physical room, and the joy of being able to read people's Post-it notes, right? This has been the absolute highlight for me, the joy of being able to read people's Post-it notes.
Nick Muldoon:
No more hieroglyphics.
Em Campbell-Pretty:
Yeah. Absolutely.
Nick Muldoon:
What is that that you wrote, Sally? Yeah.
Em Campbell-Pretty:
Everyone can say everything at once, right? So, you think about the classroom and the workshop where there's a group of people huddled around Post-its and a flip chart paper and they're still huddled in a way in their virtual huddle, but everybody can read, right? It's not that I'm not close enough, I can't read, I can't read your handwriting. There's this great equalizer is the online world. So, I think that's great. I think the challenge for the trains launched remotely is going to be do you ever get the face to face experience?
Em Campbell-Pretty:
Because if I go back over the years, one of the things we know is your first PI planning event sets the standard. So, people get this imprint in their heads of what is possible. For example, if you skip something in your first PI planning event, you just decide to, I don't know, skip the confidence vote or something weird like that, you don't do the roam of the risks or you just skip something, you never do it because you're successful without it.
Nick Muldoon:
It never gets picked up. Yeah, okay.
Em Campbell-Pretty:
You're successful without it. So, every compromise you make, and you make a series of compromises, and then you're successful despite those compromises, and that becomes a false positive feasibility. It tells you, yes, I was right. I was right.
Nick Muldoon:
I don't need to do that.
Em Campbell-Pretty:
I didn't need to do those things because I was awesomely successful and I didn't do these things. So, it's the learning [crosstalk 00:26:15]-
Nick Muldoon:
That's confirmation bias, is it?
Em Campbell-Pretty:
Yeah, that's it. That's the one. Confirmation bias. That's exactly it. Yep. Yeah, and I think there's going to be a bunch of confirmation bias in these remotely launched trains, and unless they're inside organizations where there's enough knowledge of SAFe and the physical PI planning to know that there's going to be value in bringing them together, but I can see that being a real challenge. I think trains that are launched online may never go into a physical PI planning event because of that confirmation bias.
Nick Muldoon:
All right.
Em Campbell-Pretty:
That makes me really sad.
Nick Muldoon:
I want to come back to something you said before about the leaders, and you mentioned the trust, the openness to learning and experimentation, and the discipline. I was going back over your SAFe Global 2018 talk about the seven traits of highly effective servant leaders.
Em Campbell-Pretty:
Yep.
Nick Muldoon:
Yeah?
Em Campbell-Pretty:
Yep.
Nick Muldoon:
I guess I had some questions about this, and obviously, these are four of the traits. What are the other three traits that I'm missing? Then I've got a followup question about some of the actual things that you talked about that you picked up in your trip.
Em Campbell-Pretty:
[inaudible 00:27:29] one of those four on the list I had in 2018.
Nick Muldoon:
I'll quiz you on it.
Em Campbell-Pretty:
How awkward. So, in 2018, the answer was people first, a respect for people, that sort of lens, lean thinking, manager, teacher, learner. So, we had that one. Yeah. Learner. [inaudible 00:28:00] crazy. What else did I have? [inaudible 00:28:10].
Nick Muldoon:
Yeah. Okay. I wanted to talk about that one, actually. I made a note about that. What is that, and are there examples of that in the West?
Em Campbell-Pretty:
A lot of people talk about true north.
Nick Muldoon:
[inaudible 00:28:28]. True north.
Em Campbell-Pretty:
Yeah. True north. The translation I got, which I got from Mr. [inaudible 00:28:39], who partnered with Katie Anderson for the lean study tour I did in, I don't know, '18, '17, '18, 2018, I think, so the translation he gave was direction and management sort of things. So, it's mission, right? It's strategic mission. It's that sort of thing.
Nick Muldoon:
So, just a sidebar here for anyone that hasn't seen Em's talk on this, there's a woman by the name of Katie Anderson. She runs an annual, I think, I guess not this year, but she runs an annual-
Em Campbell-Pretty:
No, not this year. She did not go this year.
Nick Muldoon:
... not this year, runs an annual lean, Kanban, kaizen study tour to Japan and visits ... Who did you visit, Em? You visited with Katie. How many were in the crew that you went over there with?
Em Campbell-Pretty:
So, I think it was a group of about 20 from memory. Katie lived in Japan for two years and then went back to the US. She lives in San Francisco, I think. While she was there, she really liked the idea of putting together these lean study tours. She was already a lean practitioner more in the healthcare side of things. So, she got the opportunity to ... We actually were on a test run tour.
Nick Muldoon:
Oh, cool.
Em Campbell-Pretty:
So, this was her experiment. She had a relationship with Ohio State University and they brought some people to the table and she brought some people to the table and they made it happen. She also had an existing relationship with Mr. [inaudible 00:30:24], who was John [inaudible 00:30:26] first manager at Toyota. So, he's a 40 year Toyota veteran.
Nick Muldoon:
Veteran.
Em Campbell-Pretty:
He came with us for the week. So, we of course went to Toyota, but we went to a bunch of Toyota suppliers as well. Isuzu, [inaudible 00:30:43]. Then we also went to Japan Post, which was fascinating. We went to a city which name escapes me right now, but they called it 5S City because all the companies in that city practice the 5S, the manufacturing 5S.
Nick Muldoon:
Tell me about it. It's not coming to mind. I don't feel comfortable or familiar.
Em Campbell-Pretty:
You don't feel good about 5S?
Nick Muldoon:
No.
Em Campbell-Pretty:
No. That's not good. So, how would I ... The 5S is five Japanese words, which I'm going to go ... Yeah. My Japanese, nothing. But it's about standardized work. So, for example, when you go into the 5S factories, you'll see the floors marked up where you need to stand to do a particular job.
Nick Muldoon:
[crosstalk 00:31:41] This is what Paul Aikas picked up for his-
Em Campbell-Pretty:
Oh, no.
Nick Muldoon:
I feel like I've seen Paul Aikas' videos of their manufacturing in the US that everything's marked up.
Em Campbell-Pretty:
Yeah.
Nick Muldoon:
Okay.
Em Campbell-Pretty:
Probably. That would be my guess. We should ask Teddy.
Nick Muldoon:
We can ask Paul, and we can ask all these people. There's time.
Em Campbell-Pretty:
Well, yeah.
Nick Muldoon:
Okay.
Em Campbell-Pretty:
Okay.
Nick Muldoon:
So, that lean tour, the Japan study tour, that was a super effective and motivating thing for you?
Em Campbell-Pretty:
Yeah. For me, it was very reinforcing. So, I had I guess my own lens on what lean leadership meant, and I found that particular tour to be very reinforcing around the value set that I believe is part of that. Katie [inaudible 00:32:43] created [inaudible 00:32:44] that is designed to show you that. So, she's often very clear that says this is not Japan, right? This is not a reorganization into Japan. This is not every leader in Japan.
Em Campbell-Pretty:
This is, I've hand picked a series of lean leaders to show you it being practiced. But it was certainly very reinforcing for me. So, very similar messages I picked up in terms of how I like to head, how I coach others to lead was built into the messages that she delivered. So, it was very cool. It was very cool. Some of those leaders, just so inspiring, particular kaizen. I think the thing that just really hits you in the face as you're talking to these folks is kaizen, this drive to get better.
Nick Muldoon:
All the time.
Em Campbell-Pretty:
All the time. Absolutely. It's these folks looking for, they're looking for the one second, right?
Nick Muldoon:
Yeah.
Em Campbell-Pretty:
The one second improvements. There's a video that floats around. Have you seen the Formula 1 video-
Nick Muldoon:
Yeah.
Em Campbell-Pretty:
... where they do, yeah, the changeover in 63 and it takes them over a minute and they do the changeover in 90-something in Melbourne and it takes them six seconds or whatever it is. It's like that, right? It's that how do I find one more second, half a second? They're just so driven. If I can remove a step that someone has to take, can I move something closer to somebody?
Nick Muldoon:
Yeah. There was some comment in the presentation that you gave. There was some comment about if I have to take another five steps, that's an extra 10 seconds. Then that's an extra 10 seconds every time I do this activity every day, and that all adds up. So, how do we shave these seconds off and be more effective and deliberate about how we do this?
Em Campbell-Pretty:
That was just huge, right? I called it kaizen crazy in the presentation. I'm just so, so driven to improve, and just tiny, small improvements every day.
Nick Muldoon:
So, one of the other practices that I didn't grok out of that talk was about the Bus Stop. What was the Bus Stop about?
Em Campbell-Pretty:
Was that in that talk? Really?
Nick Muldoon:
I'm forcing you to stretch your mind [crosstalk 00:34:57].
Em Campbell-Pretty:
You are. You are. You are. You are quite right. It really was [inaudible 00:35:01]. Okay. Oh, you're awful.
Nick Muldoon:
Yes.
Em Campbell-Pretty:
Yes. Yes, you are. Okay. So, effective leaders are human was the tagline on that one. It was really about leaders being down to Earth and being one with the teams. So, things I saw in Japan, this factory run by a woman, [inaudible 00:35:42], I think it was, so very unusual. Not a lot of women leaders in Japan. Her husband took her name because [inaudible 00:35:52]. It's a really interesting character.
Em Campbell-Pretty:
But her company has a bunch of morning rituals. You always say good morning and thank you and how they talk every day and everybody talks and everyone interacts. Then one of the other places we went to, they all had their uniforms they wore in the factory. But everybody wore the uniform, right? The CEO, the office workers, and everybody wore the uniform. Everyone was one.
Em Campbell-Pretty:
Then I was thinking about my experience leading teams, and a lifetime ago, I was working with a team that decided to enter a corporate competition. This competition was about showing your colors and showing the corporate values, which were things like better together and courage, and then [inaudible 00:36:49] a rainbow thing. So, this team decides what they're going to do, is it an address up in the rainbow colors, and they're going to be better together and show their courage and they're going to do the Macarena and they're going to video it and that's going to be how they're going to win this competition.
Em Campbell-Pretty:
I did not participate in this Macarena because someone has to take photos and stuff, right? How else are they going to enter the competition? So, had to do my bit. Anyway, we also had this ritual, which was about teams bringing challenges to leadership to resolve, and they did at the end of every spring. So, they do this Macarena and they film it and they enter the competition and at the end of the spring, they bring their challenges to leadership.
Em Campbell-Pretty:
Their challenge is Em did not do the Macarena. You are our leader, you did not do the Macarena. We are feeling very challenged by that, and we're bringing this to you to resolve. So, I went and spoke to the team that raised and said, "Look. I got to tell you. I don't know the Macarena. So, sorry." I still remember this so clearly. One of the guys said to me, "I read this blog about the importance of leaders being vulnerable." You know who wrote that blog post, don't you?
Nick Muldoon:
Oh, Em. Oh. You have it.
Em Campbell-Pretty:
So, we negotiated. I said, "Look. I think I can manage the Bus Stop." For those not from Australia, we grow up doing this in high school dances. In my part of the world, anyway. So, I grabbed my leadership team and we did do the Bus Stop and it was part of proving that we too were the same as everybody else and doing our bit and responding to the team's feedback. So, yes. That is where the Bus Stop fits in. Thanks so much for that, Nick.
Nick Muldoon:
Okay. No, I appreciate that. Now, I'm glad that I got that context. I try and do similar things. Typically, it's a karaoke or something, or that we haven't done that in a while. Yeah, okay. So, I guess the thrust of that talk was really about to leaders to serve, and it was all about being in service of. It sounds like what you took from the Japan study tour was these leaders there were very much in service of their people.
Em Campbell-Pretty:
Absolutely.
Nick Muldoon:
Do you see that as a trait that is prevalent in the best performing companies that you deal with, and how likely are they over a five, 10 year horizon, whatever that happens to be, to outperform their competitors or to be more successful in their market? Or I guess however they define success?
Em Campbell-Pretty:
I certainly see a correlation between leaders that like to serve and/or choose to serve and success with scaled agile, and business, because I guess we have seen over, it's close to 10 years, is those who practice together, your framework with discipline get results, and they get significant results. They improve their ability to deliver products and services, their cost base goes down, their quality goes up, their people are happier, their attrition goes down. We see it every single time.
Em Campbell-Pretty:
What we also see is when the leaders don't walk the talk, when the leaders are paying lip service to the transformation, it doesn't stick. They don't get the results. People don't find it a better place to work. People aren't bought into the change. So, there is definitely a correlation there. You can get pockets of wonderfulness inside an organization.
Em Campbell-Pretty:
We often observe that the organization that's transformation is as successful is the most bought in leader. Most senior bought in leader. So, if you're the leader of a train and you show the right behaviors, your train will be really great.
Nick Muldoon:
Successful.
Em Campbell-Pretty:
But that means nothing for the broader organization, solution train, the business unit, what have you. You see this thing that goes from the leader. If the leader's showing the right behaviors, you get within that space, you get the behaviors, you get the change, you get the results. But leaders who say one thing and do another, people don't buy it, right?
Nick Muldoon:
I guess this is true of any organizational change, isn't it?
Em Campbell-Pretty:
Yeah.
Nick Muldoon:
You hit the boundaries of your pocket, as you said, within the organization and then you meet the real world, the rest of the organization. People, maybe they don't have enough energy or they don't feel that they can influence and change that, and so they just live within their bubble because they don't feel that they can exert the pressure outside of that.
Em Campbell-Pretty:
Yeah. Look. I've certainly, I've seen successful bubble influence organizations. Successful bubbles can become interesting. Chip and Dan Heath's book, which one was it, Switch.
Nick Muldoon:
Oh, yeah. Switch. Yeah.
Em Campbell-Pretty:
[inaudible 00:42:02]. Shine a light on bright spot or something like that. So, bright spots inspire, and if you can create a bubble in an organization that outperforms the rest of the organization, or even if it performs better than it has previously, then everybody looks. Right? How did the organization that goes from poor delivery to great deliveries is what is going on here? That inspires others to get interested. One of the really interesting things we've seen in Australia, we can trace pretty much every SAFe implementation in Australia back to the one at Telstra.
Nick Muldoon:
Yeah, right. They all spun off from that, from the people that were part of it.
Em Campbell-Pretty:
Well, no. People who came and saw it. People who were inspired by it.
Nick Muldoon:
They're not necessarily directly involved in it.
Em Campbell-Pretty:
No. People came and got inspired by it, and then they went, did their thing, and then they inspired someone else. I haven't tried to do it recently, but there was a point in time we just could web together all of them because we could count them when we could see them. But we can web together most of them still. It says you saw someone who saw someone who saw someone who actually was someone who went to visit us at Telstra back in 2012, 2013 and got inspired.
Em Campbell-Pretty:
So, that bright spot can be really, really powerful, and that's what it takes, right? You get to add a little bit of noise, a little bit of difference, and people start to ask what's going on. I wouldn't say it's foolproof. I think it still requires, so someone's got to come, they've got to see, and then they've got to have the courage to do it for their part of the organization.
Em Campbell-Pretty:
That's the hard bit, right? I can come, I can see, I can get inspired. But am I prepared to put myself out there? There's a lot to be said for leaders who are prepared to take risks. That was one of the-
Nick Muldoon:
This was your lesson about the Bus Stop, right? You have to put yourself out there and be vulnerable.
Em Campbell-Pretty:
Yeah. Absolutely. Absolutely. This was actually, I was thinking, was the thing I was talking about at last year's SAFe Summit was be safe or be SAFe.
Nick Muldoon:
Be safe or be SAFe. Tell me about that.
Em Campbell-Pretty:
So, be safe, don't take a risk, or be SAFe, as in the scaled agile framework, and take that leap of faith. It comes back to, we started talking today about when I did this at Telstra, I didn't really understand that this wasn't a normal everyday, this is what everybody did sort of thing. It was a very new thing. So, I took a risk from a perspective that I was a business leader in a technology space and I really felt I had nothing to lose.
Em Campbell-Pretty:
So, I look back and that and go, "What on Earth possessed me?" And I go, "Well, I'm this business person leading this technology team. I wasn't supposed to succeed anyway."
Nick Muldoon:
Put it all on the line, right?
Em Campbell-Pretty:
I found out later they actually had a plan for when I did not succeed. I was supposed to fail.
Nick Muldoon:
Wait. How much waste is that? Why did they plan for something before it was ... Okay.
Em Campbell-Pretty:
Organizational policies. What can I tell you? Anyway, I did not fail. I did succeed, and because I took some crazy, calculated risks, and I've seen it time and time again, right? So many of these leaders in these companies that make this change are taking a leap of faith. I'm always saying I can't tell you exactly what's going to happen. I don't know whether you're going to get 10% cost out or 50% cost out. I don't know if your people are going to be 10% happier or 50% happier. I don't know that.
Em Campbell-Pretty:
What I do know is if you listen to what we're telling you and you follow the guidance and you behave in line with those lean and agile values, you will get results. You'll get results every single time. But you've got to be brave enough to buy in and take it on holistically and not do this thing where you manage to customize your way out of actually doing the thing-
Nick Muldoon:
Doing anything.
Em Campbell-Pretty:
... that you wanted to do.
Nick Muldoon:
Yeah. Okay. Em, this was awesome. Before we finish up, I want to take two minutes. You've mentioned books a lot today and you reminded me of this quote, Verne Harnish, "Those who read and don't are only marginally better off than those who can't." So, today so far, you've mentioned Chip and Dan Heath with Switch, you've mentioned the Leffingwell series from the late noughties. There might have been a few others. But tell me, what are you reading today? You've been in lockdown. What are the two or three top books that you've read since you've been in lockdown in Melbourne?
Em Campbell-Pretty:
Oh, my goodness. It's very awkward. Every time someone asks me, "What did you just read?" I go, "I don't know."
Nick Muldoon:
I don't think I remember.
Em Campbell-Pretty:
Can't remember. It's terrible. What am I reading? I need to open my Kindle. I don't know what I'm reading. Geoffrey Moore, Zone to Win.
Nick Muldoon:
Zone to Win.
Em Campbell-Pretty:
Zone to Win. I think that's what it's called. It's a newer book. I know this year, because obviously, I've read The Build Trap this year-
Nick Muldoon:
Yep. Melissa Perry. You mentioned that one. Yeah.
Em Campbell-Pretty:
Yep. I've read the Project to Product, Mik Kersten.
Nick Muldoon:
What was that one, Project to Product?
Em Campbell-Pretty:
Yeah. Project to Product, Mik Kersten. One of the IT Revolution press books. So, released just over a year ago. Very tied up in the SAFe 5.0 [crosstalk 00:48:21]. The other book tied up in the SAFe 5.0 release is John Kotter's Accelerate. So, I picked that back up. I read it a number of years ago when it first came out. But I like to revisit stuff when SAFe puts it front and center. Seems to make some sense to do that at that point in time.
Nick Muldoon:
Yeah, okay. It's interesting that, thinking about Verne Harnish, the scaling up framework, no relation to-
Em Campbell-Pretty:
No.
Nick Muldoon:
... scaled agile, for anyone that's not familiar. But so much of the scaling up framework about scaling businesses, they draw on so much content from existing offers, existing tomes, points of reference and experience, and it's super valuable, and I guess SAFe is no different, right? It draws on this wisdom of the collective wisdom.
Em Campbell-Pretty:
Absolutely. Absolutely. [inaudible 00:49:14] It was very fun to say in the early days, we stand on the shoulders of giants, a quote from somebody else whose name escapes me.
Nick Muldoon:
Yeah, okay. Well, Em, look. I wanted to thank you so much for your time this morning. This has been fantastic.
Em Campbell-Pretty:
No worries. It's great to catch up with you.
Nick Muldoon:
Yeah. I guess my takeaways from this, I like the be safe or be SAFe, like either be safe and don't take any risks, or be SAFe and actually put yourself out there and step into scaled agile. I definitely have to go and do a bit of research on the five S's as well and learn a bit more about that. But thank you so much for your time. I really appreciate it.
Em Campbell-Pretty:
No worries, Nick. Great to see you.
- Podcast
Easy Agile Podcast Ep.18 Top qualities of an agile leader and team
"It was great to chat with Alana and learn from her experience" - Sean Blake
In this episode, I was joined by Alana Mai Mitchell. Alana is a results coach, author, podcast host, and Senior Product Development Manager at one of Australia's largest banks where she works with Agile teams every day.
She has over 13 years experience in digital financial services and coaching. She's spoken live on Channel 10 here in the Australian media and has had her mental health story featured in publications, like The Daily Mail and Mamma Mia. She's the author of a book, Being Brave, and she's the host of the Eastern Influenced Corporate Leader Podcast.
We covered a lot of ground in today's episode. We talked about:- The importance of putting your hand up and telling your manager when you want to be challenged more and to be exposed to new opportunities.
- Building trust with your team and disclosing some vulnerabilities about yourself.
- Alana's mental health journey over the course of six years, and that journey continues today. What she's learned and what we can learn from her experience to better look after our teams and people in our community.
- Servant leadership and being a generous leader.
- The importance of authenticity and direct communication.
I hope you enjoyed today's episode as much as I did.
Transcript
Sean Blake:
Hello, welcome to the Easy Agile Podcast. My name's Sean Blake and I'll be your host today. Today, we have a really interesting guest and a fantastic episode ahead for you. Our guest today is Alana Mai Mitchell. Alana is a results coach, author, podcast host, and Senior Product Development Manager at one of Australia's largest banks where she works with Agile teams every day. She has over 13 years experience in digital financial services and coaching. She's spoken live on Channel 10 here in the Australian media and has had her mental health story featured in publications, like The Daily Mail and Mamma Mia. She's the author of a book, Being Brave, and she's the host of the Eastern Influenced Corporate Leader Podcast.
Sean Blake:
We covered a lot of ground in today's episode. We talked about communication styles. We talked about the importance of putting your hand up and telling your manager when you want to be challenged more and to be exposed to new opportunities. We talked about the importance of building trust with your team and disclosing some vulnerabilities about yourself. We covered Alana's mental health journey over the course of six years, and that journey continues today. What she's learned and what we can learn from her experience to better look after our teams and people in our community. We talked about going first in servant leadership and being a generous leader. The importance of authenticity and direct communication. I hope you enjoyed today's episode as much as I did. Let's get started. Alana, thanks so much for joining us on the Easy Agile Podcast today. It's great to have you here.
Alana Mai Mitchell:
Thanks so much, Sean.
Sean Blake:
Before we jump into our conversation, Alana, I'm just going to do an acknowledgement to country. We'd like to acknowledge the traditional custodians of the land from which we're recording today, the Watiwati people of the Tharawal speaking nation, and pay our respects to elders past, present and emerging. We extend that same respect to all Aboriginal and Torres Strait Island peoples who are tuning in today.
Sean Blake:
Well, Alana, there's so much to talk about today. The background is, we used to be colleagues in the financial services industry. We bumped into each other again out of the blue at Agile Australia '21 Conference, just at the end of last year, which was a great conference. We thought we'd have you on the podcast because you've got so many different stories to tell, but I thought maybe we could start this episode by talking about your career journey and how working with Agile Teams has weaved into your career trajectory.
Alana Mai Mitchell:
Yeah, sure. Agile really came into the forefront right back in 2013. I always remember my first Agile training. We had a team day, where I was working at the time. We had an external facilitator come in because the Agile framework was something totally new to financial services at that time. We played Lego. We had each of our wider team was divided into smaller teams, like scrum teams, all this new terminology. Then we were building island and we had an island each and the product owner was feeding user stories in from the customer. Partway through we were building, I think, a rocket launcher and then no, we didn't want to rocket launcher anymore.
Alana Mai Mitchell:
We wanted to tweak it. We had to adapt to things on the fly. I always remember that experience because it was so transformative, just having such a direct and collaborative way of working with people on a project. To this day, of all the Agile trainings and experiences that I've gone through, it's always the ones that are really interactive that I've remembered the most and gained the most and taught them, like learnt them myself as a participant and then taught them to other people as well.
Sean Blake:
Along the way, do you think, you've been through all these training sessions and you've been working with teams on the ground. What have you found from Agile, which is a big topic, but what have you found to be the most transformative and the most helpful from the way that these teams used to do things to the way that they do them now?
Alana Mai Mitchell:
I would say communication. What I found was, because I had the contrast with both, I've worked in Water Force style projects and Agile projects as well. I think the biggest part is the amount of effort and rigor that we would go through reviewing requirements and have those be delivered into technology. Then it go quiet and you not hear from technology until they come back with something and they're like, "I've got a baby." You're like, "What kind?" The difference with Agile is that you are able to co-create them.
Alana Mai Mitchell:
You're creating with your customer or your end user, if you're working with an internal user, and then you are also working with technology and finding out what kind of constraints technology has or what kind of ideas they have as well. You have that ability to communicate with the dev. Sometimes your devs are on-shore, often cases they're offshore. We're all remote now, so it doesn't make as much difference as it did when we were in the office. You can really just pull away a lot of the process that gets in between people and have conversations. That's what I really think is the most transformative part.
Sean Blake:
Great. Yeah, so that communication. Do you feel like the communication throughout COVID and working remotely has been more challenging? Are you one of those people that find those face-to-face communication skills, you really prefer the face-to-face or has remote been okay for you? Because I know some people have struggled. Some people have found it easier to be on Zoom all the time.
Alana Mai Mitchell:
Well, I mean, when I go in the office and we have that brief time where we were back in the office, I had a smile on my face the whole time. Because I just love seeing people and I'd go around and walk over to my team and say, "Hey, how are you going?" Just catch up with them. I think the one piece that's missing for me in the remote working whilst there's greater flexibility, you can do multiple things at the same time. You focus a lot of your work. You can get a lot more done quicker. I do find that informal relationship building, you need to actually schedule in time or pick up the phone out of the blue and connect with someone.
Alana Mai Mitchell:
Whereas in the office, I would just find that because people were there and I don't know, you might be having lunch at the same time or going downstairs for something at the same time or even the corridor conversations that happen after the meeting where you can just chase someone or ask someone a question or they chase you and you just get things done. It's just different. I'd say it's more, the catch ups are more scheduled and formal, I find in a remote work setting.
Sean Blake:
I feel the same way. I feel the small talk and the talk about the weekend on Zoom is much harder for me and much more tiring to try and sustain that than in person. It becomes more naturally. I really have to make a big effort, especially on one-to-ones with people in the team when I'm trying to check in on their health and wellbeing and how they're going at work. I just find that much more exhausting than what I do in person. I think it's just those nonverbal communication skills and you can see people's body language easier when you're in the office.
Sean Blake:
Someone's slumped at their chair for six hours out of a seven-hour work day. Then you're like, "Oh, something's wrong." If you know that you've got to get on Zoom and try and pretend to be happy and that everything's okay, then you can fake it a little bit easier. Of course, there's loads of benefits to remote work, as you say. That human element personally, I find it's much more challenging to replicate using digital tools. Maybe there'll be more innovation that comes, but the time will tell on that.
Alana Mai Mitchell:
Yeah. On that, I wanted to add some of my friends in the technology space. Talking about the metaverse and how at the moment you and I are having this conversation through screens. I'm in my space, in my house, and you can see my painting in the background and I can see that you've got a podcast set up. One of my friends was talking about how, he's an architect, and so he was thinking about how we create digital spaces. When we meet digitally, if we were meeting as our avatar, what kind of space would facilitate better conversation? That blew my mind when he was talking about that. I was like, "Oh, I hadn't even thought of that." Absolutely, you could meet in a virtual space because we're doing what we've got with the tools that we have today, but the tools can change.
Sean Blake:
I guess it's almost certain they will change. I can't see that Zoom will be the market leader forever. I'm sure there'll be things that come along very soon that will try and replicate some of those physical experiences that we miss so much of being in the office and having those social experiences together. Alana, I'm wondering about the teams that you work with now or in the past, those Agile teams, do you have any tips for people who are new to Agile teams or maybe they're coming in?
Sean Blake:
They want to improve their communication, whether they're remote or in office, and improve their organization's Agile maturity, but they're just finding it a bit of a struggle. Do you have any tips for people who are just, they're butting their heads up against the wall and they can't seem to make progress with some of those patterns and habits that you talked about, like taking requirements away and not knowing what's happening for so many months or years before you hear something back from technology? How do you actually start to influence that culture and behavior, if you're new to Agile?
Alana Mai Mitchell:
I'm going to take a slightly different approach on that to answer your question. Because the thing that came to mind for me was when I in Outward Bound, which is a remote wilderness organization in 2012 in the US. I was instructing there. One of the frameworks that they use is William Glass' Choice Theory. Choice Theory talks about that we have five needs, and I'll put myself on the spot. Well, I'll mention some of them, because I can't remember all of them. There's like need for fun. Some people have a high fun need. Then there's like need for power, like feeling powerful. There's like, love and belonging, is another important need. There's two others, which I can't recall right now. I think when you are coming out of a situation, from a perspective, you've tried a couple of times when you're approaching it, and not getting anywhere, I would have a look at what needs am I, myself looking to get met out of this communication.
Alana Mai Mitchell:
Then on the flip-side, what needs is my communication partner or the team that I'm working with? What is the most important need for them? As we were talking about remote working, like the fun need. People love to have fun and you can actually have fun at work. It doesn't need to be separate. Thinking about like, if you have a high fun need, and you also notice your team has that as well. How can you address that in your communication style or bring out some kind of activities that can bring that to life? I would always go back to what are my needs and what are the needs of other people that I'm working with? Because when you're working with different teams, they have different agendas, they have different goals. If you can figure out what you have in common, it's a lot easier to bring another team or people in those team on the journey, once you figured out what the common ground is.
Sean Blake:
That's great advice. Think about it from their point of view, rather than just what you need and your own agenda and try and adapt to your approach to them. That's really good. I saw this quote recently, Alana, which reminded me a little bit about your mental health journey, which we'll talk about more in a moment. The quote was about, when you're looking for a new role or a new job, you shouldn't just look for a great company to work for. You should look for a great manager to work for, because the influence and your experience as an employee, working for a manager, is often so much more important than and influential than just picking a great or a well-known company to work for. Have you found that to be true in your own career?
Alana Mai Mitchell:
Oh, yeah. I have found that some really phenomenal leaders. In a previous organization that I was working in, I like to keep learning and growing all the time. In previous roles, sometimes I get bored. It happens. That's really valuable to organizations because I'm constantly looking at where to improve things. I had a time where my manager was focused on other things and learning and development wasn't as important. Then I had a lady named Christina come in and Christina was like fire. She was just, "This is what we got to do." Open to change, really clear communicator, she's from the US. She's really direct in a compassionate way and she's really progressive as well. I found because of her influence in the organization.
Alana Mai Mitchell:
Also, through my willingness to put my hand up and say, "I'm willing to participate." Which is, for the people who are tuning in, it's not just about the leader creating the opportunities for you and saying, "Hey, present to this general manager forum or executive general manager forum." Or whatever it is. It's also about you saying, "Hey, I'm willing and I'd love to." And communicating what you are after. We met on that path and I had some of the most, stronger success working with Christina. I was fortunate at that the culture was also really great. The immediate team culture needed to shift as well, which is part of why Christina came on board, and the company culture is really good.
Alana Mai Mitchell:
I would say on the point on like manager over culture is that when you are someone who is progressive and you're wanting to shape the culture for the better, you're going to find cultures that need a little attention or need a little work or things that aren't quite as performing as well as they are. With the sales perspective, opportunity plus. If you go to a culture and everything's amazing, you're sure you can make it a little bit more amazing. Really, when you have the support of your manager, who's, you see these initiatives and they're going to say, "Okay, go for it. I've got this GM forum coming up that you can present at, or let's find your sponsor. Let's find your mentor." That the two of you working as a team can be at the forefront of the new culture, which impacts the rest of the culture.
Sean Blake:
Interesting. I don't know if I've ever been in a culture that's perfect and overachieving and too good, but absolutely you can get too comfortable and complacent in roles and you can almost just be a little bit shy from putting your hand up for those opportunities. Do you think there's many cultures out there that are too good? How do you assess the quality of a culture before you accept the role and start working in that team?
Alana Mai Mitchell:
Oh, good question. I always asked, what's the vision and how does it relate to this role? I want to hear it from the hiring manager before I join a company. What I'm looking for is I'm asking that question to multiple people. I'm looking for a congruence, about the hiring manager sees a similar story as to what their peer, who's maybe interviewing in the second interview or their leader in the third interview. I'm looking for those things to match up, because that's telling me there's consistency. It's just, I'm getting the same story. That they're also communicating well. That would be a sign to me. Yeah, that's about what I do.
Sean Blake:
That's good. Good tip. Alana, you have a quote on your website, which talks about your mental health journey. It says, "I have totally recovered from five mental health breakdowns across six years, where doctors once talk would me, I would be homeless." That sounds like a lot of hardship and a lot of sweat and tears and pain over many years. Do you want to walk us through a little bit of that journey and what you've learned about yourself through those experiences?
Alana Mai Mitchell:
Oh, yeah. Thanks for pulling that out from the site, Sean. In 2013, I started to notice that things weren't right. I wasn't feeling myself. I sought help from a counselor, career counselor. Because I thought, "Is it my career?" I said, "Am I not in the right job?" I spoke to a psychiatrist and a psychologist and they did a little bit of an investigation, but no one really got to what was going on. Then I made some quick decisions in my career, which I look back on and I think, "Wow, I really was in the throes of it and not thinking clearly at all when I made those choices." I found myself, about November 2014, in between roles. As someone who was previously really ambitious, like high-achiever, chronic high-achiever without having a role and a career prospect at the moment back then was a big deal.
Alana Mai Mitchell:
I had what was called a psychotic episode. Essentially, that was like me, believing deluded thoughts and not having a really strong grip on reality, having some story going on in my head that wasn't true at all. It ended up because I was taken by ambulance to hospital. Then still at that point, people didn't really know what was going on. I was a in mental health ward and came out from that, started on medication, which improved things. I thought, and this is part of why I had the multiple psychotic episodes, is that I thought that the stress of being in between jobs or stressful situations at work, I thought they were the triggers for the psychotic episodes.
Alana Mai Mitchell:
I would take the medication for a while, get better temporarily, think everything was normal, stop the medication. Then six months later I would have another breakdown. Then that happened over six years and I realized towards the fifth and final, so that was when I was running a coaching business that had a few clients at the start and then we didn't have any clients at all. I essentially ran out of money and got into debt. Then when the doctor learned about my financial situation, he said, "You're going to be homeless." I was so offended. I was like, "How dare you." I was like, "No, I will not. I will not." I look back now and I'm so thankful for him sharing that with me, because he provided me with a choice. Something to push against and choose another way. He activated my will, from me going from being offended to being thankful, where I'm at today.
Alana Mai Mitchell:
I charted my way out of that. Now, I have well-managed schizophrenia and I take medication. I'll be taking medication for the rest of my life. It's part of who I am. I don't experience like, some people have a lot of appreciation for, because I know that they're in their mental health journey. It's not all smooth sailing, even after they have an answer of a diagnosis. It still can be challenging in there's up days and down days. For me, I'm consistent. It's been now coming up to four years since the doctor and I had that conversation in the hospital. Life is just incredible since then.
Sean Blake:
That's great. I'm so happy to hear that. Thank you for sharing your story with our audience. I think it's really important, isn't it? To be vulnerable and to share the truth about things that have happened in the past. Do you think that there's something that we can learn? With the people that you work with now, do you have a clearer understanding or are you looking for signs of people in your life who might be struggling with some of the similar issues and what can we do as people in our own communities and working with teams to look out for each other and to better support each other with some of these mental health issues front of mind so that we can be more supportive?
Alana Mai Mitchell:
I always listen for and check in with how the team is doing and it's not just, you ask how are you, and you're listening for more than what they say. If they say they're good, how are they saying it? We had that conversation before about the remote working and it's different. To come to the, are you okay, and we have the, are you okay days. Someone asked me in the office where we were actually working together. They're like, "Are you okay, Alana?" I couldn't answer her. It's not always as simple as getting a no, sometimes it's, you don't get a response. Then the alarm does go off. I really think taking in all the points of interaction that you have with someone and aligning to, is that consistent with how do they were, is there something different, check in with them, how is it going? If you're having a conversation, great. If they're sharing with you, even better.
Alana Mai Mitchell:
If they're not, you can always just check in with yourself and being like, "Is it something you need?" As to, why are they not sharing or is that something that's going on with them as well? The other piece I wanted to tie it, bring it back to the Agile leadership piece and from the conference that Agile Australia that we were at. I really see that building trust with teams is so key. We're in this remote working environment or hybrid working environment, depending on what office you're in. It really is important to build trust with your team. One of the quickest ways you can do that is by sharing vulnerably with what you have to share. I don't mean going for exposure and putting yourself in vulnerable situations where you are uncomfortable with what you share.
Alana Mai Mitchell:
It's disclosure, so it's something that you're 100% comfortable within yourself, and you've accepted it within yourself and you share that with your team in openness. When you do that, you see that your team also, they hear it and they mirror it as well. You go first and they share. The mental health example, I shared that on LinkedIn. I've shared it in situations with my team. Then I've been invited to talks and I've had people approach me. It really builds without having to go through a lot of, I ask this thing of this person, do they deliver it above and beyond expectations when I ask for it? How many times do you need to go through that process before you trust someone versus you, coming out and creating an environment of trust through of vulnerability? I do caveat that it's like not oversharing, it's sharing what you're comfortable with at that point in time, and that might change as you go on.
Sean Blake:
Interesting. Does this apply to leaders as well? I know that you've spoken about being a generous leader in the past, and that reminds me of servant leadership, which is another kind of Agile phrase that you hear come up quite a lot. This idea of going first, disclosing what you're comfortable with to your team, even as a leader, showing vulnerability is really important. I know in my experience, if you can share some of the honest and harsh realities of what it's like to be in your position, then your team are more empathetic with the challenges that you have.
Sean Blake:Because a lot of people assume that when you are in a position of leadership and responsibility, then things are easier because you can just delegate or you've got budget to solve some of these problems, but it's not actually the reality of it. The reality of it is you struggle with things just like anyone else. By sharing and disclosing things with people at all levels of the organization, then that helps to build empathy and a bit more care and support no matter what level you're at. Are there other things or habits or qualities of a generous leader or a servant leader that you've seen or that you try and model or encourage?
Alana Mai Mitchell:
The big one that stands out for me is authenticity. Really knowing yourself, knowing what your leadership style is, knowing what your challenges are, what your strengths are, what you're working on and being authentic about that. When you feel something, sharing what you feel, not having to feel like you need to say it a different way or sugarcoat it, being able to speak your mind in a way that's direct and compassionate. We're not going for like arrogance, and we're not going for wishy washy. We're going for direct and compassionate, then share what's in your heart, so authenticity. Those are the leaders that you, I'm so glad you brought up empathy because when you're vulnerable, empathetic, and authentic, those are the leaders that really stand out for you and me.
Sean Blake:
That's great advice. Authenticity, direct communication, build empathy. All right, thanks for sharing that.
Alana Mai Mitchell:
You're welcome.
Sean Blake:
Alana, how did you decide that you wanted to write a book about some of your experiences and can you tell us about how your book, Being Brave, has changed your life and how you think about sharing your story?
Alana Mai Mitchell:
I naturally have a lot of things going on. I love projects. I love it, that's why I'm in projects. Because I love setting a goal and reaching it. The company I was working at had done a number of workshops and I got to a point where I didn't have as many activities going on. I was like, "Oh, that's really interesting. I don't have as much stuff going on." This was just at the start of the pandemic in 2020. A friend, a really dear friend of mine said, "Try meditation. Try meditation daily." I meditated each day and I had been surrounded, my network is very much of a coaching network. I know a lot of coaches and they had written their own books as well. I was on the radar and I was meditating and I got the idea to write a personal memoir about my story.
Alana Mai Mitchell:
It's really interesting that even in through that process of doing a lot of personal development work and going through the process of writing the story, there were still some things in that, that I wasn't quite comfortable owning yet. It's been, since I wrote the book that I've accepted that. In a book, if people read it, I talk about psychotic episodes. I don't talk about schizophrenia because it was all later when I was asked to do a media thing about schizophrenia, that I was like, "Okay, yep. Time to own that." I feel like the book at a point in time had me accept all that had happened with unconditional love and then to still, modeling that piece of going for disclosure and not exposure. Still, I had my fragility on what I wasn't ready to disclose yet. Since then, that had progressed further.
Sean Blake:
That's awesome. That therapy you're sitting down to write the story actually helped flesh out the story itself and you came to terms with some of those things that happened. What has been the reception to the book?
Alana Mai Mitchell:
Most people, when they pick up the book, it's a short book, so some people even call it a booklet, because it's 11,000 words. It's short. They say, "Wow, I read that in an hour and a half, in one sitting. I couldn't put it down." someone had said, "It's the story of the famous rising from the ashes." They can take a lot of inspiration from it. The point of the book and a lot of what we're talking about vulnerability is going first as the leader. You set an example that others can follow in, so that will flow into their lives as well. The book is set out with a story and a few questions at the end that people can go through for their own insight.
Sean Blake:
Great, awesome. Alana, is there anything else you'd like to share with our audience before we start wrapping up the episode today?
Alana Mai Mitchell:
I did, because I know this is about Agile more so, and that's a really important topic to your audience. I did write and have a think about after that conference we went to, Agile Australia, about what is beyond the Spotify model? Because the Spotify model is very, word is spoken about it at the moment with the crews and the tribes and squads of course, and the chapter lead models and all that they have, which I'm sure everyone tuned in would be really familiar with. I started to think about, what are the things that are relevant beyond the Spotify model? What's next? If your organization is at a point where you've already at your job at some of that, and you're looking for what's next. I did write an article about that. It's on LinkedIn, and I'll give it to you. If you want to, you can put it in the show notes.
Sean Blake:
That's awesome. We will definitely do that. Where can people go to find out more about you? Where can they buy your book or visit your website?
Alana Mai Mitchell:
My site is www.alanamaimitchell.com. On there is more about my story. There's a few things about coaching, which may be relevant. I'm not coaching at the moment, I'm more focused on my career in financial services. Then the book is on Amazon and it's in English and also in Spanish. There's the audio book and also the print book and the eBook.
Sean Blake:Awesome. Well, Alana, thanks for disclosing what you've disclosed today and sharing your story with us. I've learned a lot about your experiences, and I've got a lot to think about, to reflect on, how to be a more generous leader. Thanks for spending time with us and being part of the Easy Agile Podcast.
Alana Mai Mitchell:
You're so welcome. Thanks for having me on the show, Sean.
Sean Blake:
Thanks, Alana.
.png)

