Easy Agile Podcast Ep.23: How to navigate your cloud migration journey

"I had the pleasure of sitting down to chat with Dominic Price from Atlassian. It was so enjoyable to reflect on my time working at Atlassian and to hear Dom's perspective on what makes a great team, how to build an authentic culture and prioritising the things that matter."

- Nick Muldoon, Co-CEO Easy Agile

Transcript:

Nick Muldoon:

What I was keen to touch on and what I was keen to explore, Dom, was really this evolution of thinking at Atlassian. I remember when we first crossed paths, and correct me if I'm wrong, but I recall it was like late 2014, I think.

Dom Price:

Yeah, it was.

Nick Muldoon:

Scrum Australia was on at the time, and you're at the George Street offices above Westpac there, wherever, and we had Slady in the room, there was yourself. I think Mairead might have been there, I'm not too sure.

Dom Price:

No, probably not. I think it was JML's engineering meeting, engineering relationship meeting.

Nick Muldoon:

Right.

Dom Price:

Involved in the

Nick Muldoon:

Hall of Justice, right? Not Hall of Justice.

Dom Price:

Not Hall of Justice. Avengers.

Nick Muldoon:

Avengers. When was the last time you were in Avengers?

Dom Price:

A long, long time ago. A long, long time ago.

Nick Muldoon:

You've been working from home full-time since March, right?

Dom Price:

Yeah. Although, actually for me I can work from anywhere for three and a half years.

Nick Muldoon:

Yeah, fair enough. Okay.

Dom Price:

The shift for me was missing the work element. I'm missing the in-person work element because being on the road a lot, having that one day or two days week in the office, there's connective tissue, I didn't realize how valuable that was. Going five days work from home is not a great mix to me.

Nick Muldoon:

No, not a great mix for me either, Mate. I was the one that was coming into the office during lockdown. I was like, "Oh." It was basically an extension of my house, I guess, because I was the only one that was coming in. But I could turn up the music and I could get some work done without-

Nick Muldoon:

Yeah. All right. Back in late 2014 when we first crossed paths, we're at JML's engineering meeting, and that was before JML had gone to Shopify.

Dom Price:

Yes.

Nick Muldoon:

We were talking about all things. I remember talking about OKRs, which was the Objective Key Result framework that we were using at Twitter that I think Atlassian was looking at for the first time.

Dom Price:

Yeah, we'd been flirting with for a while.

Nick Muldoon:

Flirting with for a while. What was Atlassian using at the time? What was VTFM?

Dom Price:

There was two things we had at the time. VTFM which was Vision, Focus Areas, Themes, and Measures, which was our way of communicating our strategy, our rolling problem strategy. But then off the back of that we had what I would call old school KPIs. Right? We'd pick goals, right, we'd pick ways of measuring those goals, but very KPI-focused and very red, amber, green scoring focused. When we were small, it worked okay. It didn't scale particularly well because it became punitive. If you were green and you hit your score, you got ignored because you were always meant to, and if you were amber or red and you missed by anything, you got punished. Right? It's like, "Please explain." You got the invite to the head master's office.

Dom Price:

We wanted a way of getting stretched into there and also be more outcome-focused, because I think when we scaled KPIs, we got very output-focused like, "What did you do this week? What's the thing that you shipped?" Actually, the thing that we forgot about, and I think it was by accident, it wasn't bad intent, but we forgot about what's the outcome or impact we're trying to have on the customer, because that happens after the event. OKRs were a way of putting stretch in there and building the idea of moonshots and big ambition. But then also, refocusing us on, what is the impact we're trying to have on the end customer, not just what's happening in the sausage factory?

Nick Muldoon:

With that end customer perspective though, did you get that with the VTFM?

Dom Price:

No. Actually, the first year we rolled that OKR, that was part of the problem. We had the VTFM because that stayed, right? That was like the sacred cow for the first year. That stayed, and we just had OKRs underneath. Yeah, and we're like, "Well-

Nick Muldoon:

So you're mixing them together.

Dom Price:

... which ones do we report? The measures in the VTFM because that's our Atlassian level plan, or the OKRs, which is the things we're actually doing and the impact that we're having. You're like, "Well, both," and you're like, "Well, they don't meet. There's no cascade up or down, left or right, that had them aligned properly." The year after we actually phrased ... we got rid of the VTFM, and we now have our rolling 12-month strategy phrased as OKRs.

Nick Muldoon:

Right. Okay. At that time, Dom, back in 2014, when you were flirting with OKRs, as you said, was the VTFM that you were working to replace, was that company, department, team, individual, or did it just stop at the team?

Dom Price:

Yeah. That's where it didn't really scale, right? The organizational one made sense, and again, when you're smaller, it's a lot easier to draw the linkage between your team or your department and the company one. As we scaled, what happened was we'd have a company level VTFM, and then each department would go and build its own. The weird thing is, and again, this works for a phase, and then you realize it doesn't, is we don't create value up and down the org. We create value across the organization, and so building these VTFMs in departments was honing our craft. But it was doing it at the detriment of how you work across teams.

Dom Price:

I think that it's one of those things that at the time, we didn't realize. If I had a crystal ball, it would have been great. But it seemed like the right thing to do. Engineering had a VTFM. So did Design, so did Product Management, and you're like, "You know we only ship one experience, right?" I don't care if engineering's perfect and design's not because that's letting the customer down because this one experience that we shipped. There was this whole sort of arbitration where we'd build them vertically, and then try and glue them together horizontally, but they'd all been built in isolation.

Dom Price:

Then When it comes to trade offs, and every business has trade offs, whether you admit it or not, when you're like the best laid plans literally stay on paper, right? That's where they exist, then reality kicks in one day after you've built the plan. When reality kicks in, what trade off are you going to make? Are you going to do the trade off that delights the customer, maybe compromises you? Right? then how do you do that internally? Are you going to help Design and Product Management and load balance that way, or say, "Well, yeah, I'm an engineer and we're fine. It's Design's fault. How we'd adapt everyone is Design's fault." We quickly realized that a vertical model brought about some unintended consequences and some odd behaviors that weren't really the kind of behaviors we wanted as Atlassian.

Nick Muldoon:

Back in that time, Dom, in 2014, 2015, did you have the triad then with the product design and later for each of those groups?

Dom Price:

In physical people, yes.

Nick Muldoon:

But in-

Dom Price:

... modeling, no.

Nick Muldoon:

No. Okay. How did that come to fruition, that triad where they were working as one in harmony to deliver that customer experience?

Dom Price:

I think essentially, it's one of those brilliant mistakes when you look back. We're really good at reflecting, and you do a few reflections, and you suddenly see the pattern, and you like, "Hey, our teams that are nailing it are the ones where we've got cognitive diversity and the balance of skillsets." Not where we got one expert or one amazing anything, but actually, you're like, "Yeah, actually -

Nick Muldoon:

If look at some of these patterns-

Dom Price:

Yeah. You're like, "Hey, I just saw that design." They get the product manager in a headlock and have a valid argument at a whiteboard. You're like, "I actually like that. That's what I like, the meeting where there's consensus and violent agreement." Maybe that's the wrong signal, right, that the right signal is this cognitive diversity, this respectful dissent. You see that, and we're like, "Hang on, we have the realization that engineers build great usable products, and product managers are thinking about the whole sort of usability and along with the designers. Viability, you're like, "Oh, we need all three. All three of those need to be apparent for a great experience." You're like, "Cool. Let's double down on that." Right?

Dom Price:

We started to hone in a lot more on how do we get the balance across those? How do we understand the different roles? Because we didn't want to become homogenous. You don't want those three roles to get on so well they all agree. You also don't want to violently disagree all the time, right? A little bit of disagreeing commits great. If they're always in disagreement, then that comes out in the product. How do you find the things that they stand for, and how they bring their true and best selves to each phase? Right? If you think about any given product or project, there are natural phases where their skillsets are more honed, right? In the phases for us, part of managing design is often a lot better with the ambiguous and a whole lot of stuff. When it comes to building, I'm probably going to listen to the engineer more, right?

Nick Muldoon:

And you're handing it over to delivery.

Dom Price:

Yeah. But then also, it's like, well, it's not the ... If you think about delivery time, I think we'd sometimes think of it as the relay race. I think that's incorrect, because everyone's still going to see the relay race. Once I've run my lap, I'm done, right? But in product development, it's not because when I hand over the baton, I still have a role. Even if it's in build phase, the product manager and the designer still have a massive role. It's just that they're co-pilots and the engineer's the pilot, right? You don't disappear, your role changes. I think that was one of the nuances that we got as we started to bring in the right skills, the right level of leadership, the right level of reflection to go, "How do we balance this across those phases, and how do we be explicit on what role we're playing in those different phases?

Nick Muldoon:

Okay, that's interesting. I'm going to want to come back to that when we turn our attention to the customers in the Agile transformation landscape more broadly. But one thing that has got me thinking about with respect to this balance is the fact that Atlassian had the discipline to hire for a triad, right? If I think about, I think this was around 2013 at Twitter, and in one of our groups, we had pick a number, but there would have been 200 people, and there would have been less than 10 product managers. I think we actually had a ratio of like 20. It was something silly like 26 engineers to a product manager. It wasn't even a design counterpart necessarily for each of the product managers. The balance was way off, and it wasn't very effective. Was there a time at Atlassian where there was this reflection? Because I'm just trying to think, in my time at Atlassian, I don't think we had maybe a great balance. I think there was a much heavier in engineering than there was in design and product.

Dom Price:

Yeah, it's one of those things that if it's not there, you don't miss it. Right? It's weird, right? It was a lot of it before my time, but when I listened to the story, it's like even design as a discipline when I started in 2013 was a very small discipline. I think even then, it was kind of like a hack to the notion where it was like, "Oh, yeah, we got some designers. They do the pixels, right? They make stuff look pretty." .

Nick Muldoon:

They do T-shirts and they do like .

Dom Price:

Who knows, right? But it makes us look pretty, right? They drink craft beer, and they sit on milk crates. We had this archetype of a designer, and then you like, "Oh, actually, once you start to understand user experience, the integration points, design languages, design standards, and the experience, once you get your first few designers who say, "Here's how our products fit together," and this is the experience from a customer lens, you're like, "Oh, I'm not sure I'm a fan of that." It wasn't badly designed, but nor was it particularly well-designed. Once you start to make some improvements, then you start to measure customer satisfaction, and you make that experience more seamless, you suddenly see the value.

Dom Price:

I think for Atlassian, I think we started as an engineering company. We added product management, and then begrudgingly added design. Interestingly, in my time there, the most recent thing we've added is research.

Nick Muldoon:

Yeah. Okay.

Dom Price:

Fascinating evolution for us again to go, "What do you mean, research? I'm a product manager. I know everything about the industry in the section of the competition." They're like, "But do you know anything about the customer, and the job to be done at the top tasks, or how they experience, and thinking about things like accessibility, thinking about how our products integrate with other products, thinking about not just from a competitive landscape, but what's the actual job to be done, and what are the ways people are trying to do that, and the drop off points.

Dom Price:

Research has become a new muscle that we had the exact same experience with. First time you roll it out, people are like, "Oh, we don't need that. It's overkill." You're like, "I see, it's really quite good." Hard to integrate because you're giving me findings I wasn't expecting, and then there was a shift both for designers, but also for the product managers to go, "Oh, I can use a resource now because you're this independent group that can help me understand, not just my product and iterating on my products, but a level up, what's the thing that my products trying to do? Who am I competing with, and what does that experience look like end to end?" It's a completely different lens.

Nick Muldoon:

Basically what you're describing there, Dom, is you've still got the triad of the product design and leads. But now you've got this. It's a centralized kind of research team?

Dom Price:

Yeah.

Nick Muldoon:

Do they drop in for particular projects in different areas?

Dom Price:

Yeah. If you think about it, if you strip it back to plain common sense, I think over time, we got really good at explore and build. But maybe we lost a little bit of the muscle around wonder. These researches are great. The blinkers are out and they wonder, right? I'm sure they physically do this as well, but mentally, they stroll, right? They go quite broad, and when they come back with their insights, you're like, "Wow, that's given me a really good broad perspective." I'll give you a quick example where we're working a lot, and we always are on accessibility. It's easy to look at your current products and start adding stuffing. Right? That's the logical way of doing it. Or you look at your competitor's products, and how do you become a pair or a peer? Easy.

Dom Price:

What our research team did was they actually got a whole lot of people with different sight and mobility issues, and said, "We're going to now get you to use our products and go through some key tasks." They're already using it, but it's like maybe they're on a screen reader, or maybe they can't use a mouse, they can only use keyboard shortcuts. You suddenly see the experience through their lens, and we record it, and it's tracking eye sight and line of sight using all the actions. You've got this level of detail there where you're like, "Well, I know we're trying to build empathy, but actually seeing that experience firsthand is completely different than trying to think about it."

Dom Price:

You just seeing it through the lens of this person. The research team did weeks and weeks and weeks of research with different users, different backgrounds, different disabilities, different products and different tasks to give all of our teams the sense of what is it like as the actual person. Here, you can actually walk in that person's shoes, or it feels like you are.

Nick Muldoon:

If you're a product manager and a designer, and you're ... Because it sounds to me, Dom, like that sort of investigation or exploration that you're describing there with respect to mobility-impaired or sight-impaired people, that's something that it might be hard for me to bring that into my OKRs for our product. For that triad, how do I have ... I'm trying to push forward and chase down monthly active users, or cross-flow, or whatever it happens to be, and that's much more long-running. It's like it's a long-running thread that's just going to stay open for 18 months while we think about this stuff and have these conversations. Does that research group, do they actually have their own OKRs, and are those OKRs annually?

Dom Price:

Yeah. Yes and no. We do mostly OKRs across design, research. We now have a ways of working team. They tend to be shared OKRs or more cross-functional, are cross-functional to shared. The cross-function as in we have the same objective, but different key results.

Nick Muldoon:

Yeah, okay.

Dom Price:

If you think about accessibility as an objective, the research team, their key result is about having the latest greatest research and insight so that we can learn and understand. You're like, "Cool, that's your task." Right? The design team, your OKR is to take that insight and turn it into some designs, usability, and then you can actually go along the value chain, and each different person in that value chain has a different OKR.

Nick Muldoon:

Okay. Still today though, there's no OKRs at an individual level, right? It's all team, group-based?

Dom Price:

We have odds and sods. I've dabbled with it a little bit. Sometimes I think I've always got individual OKRs. The question is whether I share them or not. I think if you think about the majority of knowledge workers, they will have individual goals, "I want to learn a new skill, I want to acquire a new "

Nick Muldoon:

Honing the craft.

Dom Price:

Yeah, right? Whether you write that down and it benefits you or not is not up for debate. When it came to writing them down in a collective, having a single storage of them, any kind of laddering, I think the cost of that is higher than the benefit. Right?

Nick Muldoon:

Okay.

Dom Price:

We strayed away from saying everyone then must have individual OKRs, and then ladder, whatever, because it ends up getting very, very cumbersome, and actually very command and control. What we've done instead is really say to our leaders, and this is leadership by capability, not by title, but saying to our leaders, "This is part of a conversation you should be having on a regular basis with your people around growth, and how you're inspiring them, and how you're motivating them. How are they developing and evolving? What are the experiments they're running on themselves? Right? How are they with other people? What are their challenges, and how can you help them never get those challenges? What are their points of amplification that you should be calling out with them to turn the dial on that? Right? What are their superpowers that we should be really encompassing, right, and nailing?" That's part of a leadership conversation. Does that need to be written down and centralized? No. To me, it becomes a zero benefit to documenting that.

Nick Muldoon:

It's interesting hearing you describe that. That's very much learning and development-focus. If I think back to Andy Grove's High Output Management, my understanding of that at an individual ... of OKRs and an individual level was always with respect to your customers. What am I going to do for my customers? But you've actually framed it, what am I going to do for myself that's going to allow me to be in better service to my customers, maybe next financial year?

Dom Price:

Yeah. It's a secret. I'm guessing this is shared by Atlassian, but this is definitely my view of the world, and I've shared this with enough people now where they understand. You can't be a great teammate if you're not turning up your true best self. You got to take a step back. There's this whole weird narrative around the humility of being a teammate where you're like, "I'm a martyr, and I'll take one for the team." It's BS, because if you're not in the right zone for that team activity, you're not giving your best, right? You're actually the anchor that brings the team down. You step back from that and you say, "Well, how do you be the best?" Because not all work is teamwork. There's a lot of deep work and individual tasks and stuff that needs to be done. You're like, "Right, I need to be the best version of me. Well, what's that mean?"

Dom Price:

It means that before any meeting, I need to have done my tasks, or before any meeting, I need to have done my pre-meeting, right? If we're meeting as a team and we have this synchronous activity, what are the things I need to do to be best prepared for that synchronous activity to deliver the most value? How can I get the most out of that teamwork? How do I turn up and be present? How do I turn up with respectful dissent and challenge, right, and provocation? That requires me first to be an individual. Right? I think one of the dangers in a lot of work environments right now is people have lost the understanding of what it is to be an individual, what your key leadership style, your learning style, how do you turn up? Right? How do you critique? How do you take feedback? All these things that make you you, you need to know those and be aware of them before you can be great in a team environment.

Dom Price:

It's not just the tasks. You need to know you. If you're a great individual, and you've honed that, you can then be a great teammate, and if you're a great teammate, you can deliver great outcomes for your customers. Anything else is an accident, right? We've all been in accidental teams, which has delighting a customer, and we've sat there and gone, "Really not sure what I did to that guy. I'll take it. I'll take the pat on the back. I'll take the kudos, and the bottle of wine, and the congratulations. Not really sure I amplify that. I don't know. If you don't know, you probably didn't. Right? That's not humility. You're probably just a passenger. I think the danger in growth environments is there's lots of passengers who they're a passenger to lots of success, and after a while, they're like, "I'm amazing." You're like, "You're not. You've just been in the right place at the right time repeatedly."

Nick Muldoon:

I got to process that.

Dom Price:

Let me give you an example. Right? A couple years ago, I was in New York with a mate of mine, Sophie. She's unofficially mentored me and helped me a lot of the years, right? I'm talking to her about trying to scale me, and I was really angry about some stuff, and thankfully, it was late afternoon in New York. She bought me [inaudible 00:25:30]. We smashed a drink and we chatted away, and she's one of those people that just calls BS on you, right? I'm like, whinge, whinge, whinge, whinge, whinge. She's like, "Oh, cool." She's English as well. She's like, "So I'm guessing you're just going to whinge about it and hope it goes away." I'm like, "All right, fair point. Little bit, my English came out. I actually hoped that maybe even if I did whinge long enough, it would actually disappear." She's like, "That never happens, does it? What are you going to do about it?"

Dom Price:

We chatted when she gave me this challenge, and she's like, "You're not evolving." She's like, "You're adding stuff in, but you're full." She's like, "Cognitively, Dom, you're full." My challenge was I was reading all these business books at the time, and I knew lots of stuff, but I didn't feel any smarter. I wasn't doing anything with it, and it's creating this frustration spiral. She gave me the exercise, and you've probably seen this, the four Ls. She got a bit of paper, and she's like, "All right, write the four Ls down. Reflect on you as a leader. This is selfishly purely about you as a leader. Last 90 days, what have you loved? What have you done personally?"

Dom Price:

I'm like, "Oh, no, no, no, no." She's like, "Not like, because we're not doing likes here, right? We're not being soft. Loved, and own it. Actually, superpower, do more of it." We did that, very uncomfortable few sips of wine. Then she's like, "What's your loathe and what's your longed for?" I had lots of long fors, long list of those, but no loathed. She's like, 'All right, here's the problem. The long for, you're sprinkling in in the 25th hour of every day. No wonder you're not doing well at it, because you never giving it the ... You're not giving yourself any space, or time, or freedom to actually experiment. You're not growing. You're not getting better. You're just adding stuff in." I'm like, "Fair point."

Dom Price:

We went through, found some loathe. She's like, "Right, you're going to remove those. Who are you going to tell those habits, or rituals, or whatever, who are you going to tell that you're removing those because they need to hold you accountable? Because they'll slip back in really easily." I found someone, pinged them. She's like, "Right, the longed." She's like, "I need to let you know that when you add them in, you're going to be crap at them." I was like, "I don't want to be rubbish at anything. I'm a leader. I need to be a superhero. I need a cape, and I need to fly in, and everything must be perfect first time." She's like, "No, the first time you added a longed for, the chances are you'll be rubbish at it. Find someone who has that muscle and let them help you practice it, and you'll get better at it over time."

Dom Price:

Then the fourth L was what have you learned? What experiment did you learn yourself last quarter? What did you learn about yourself?" She's like, "Right, go and tell as many people as you can. That'll build a place where you're learning and networking environment for you." I did it, and then I did it again 90 days later. There's a few times when the power of rationalization kicks in, and I just BSed myself because really easy to do. Then other times where I've got really deep and analyzed on it, and it's enabled me every 90 days to evolve, right? Now, the moral of the story, and this is where we tie individual to team, the number of leaders I know in big businesses driving transformations, but they're not changing themselves. What behavior are they rolling with? They're rolling with the behavior of, "I'm fine. You're not. You all need to change," which is-

Nick Muldoon:

Yeah, role modeling status quo.

Dom Price:

Yeah.

Nick Muldoon:

Yeah. That's interesting. I've certainly heard of the love versus loathed exercise. I like that you, or that Sophie extended it to longed for and learned. I think that's really beautiful, and I'll take that. With the loathe in particular, were there things on that list that you had to delegate or you had to hire someone to do? Because there's things that I think about that I loathe with respect to the business, and typically, they're things about orchestrating, paying suppliers, or whatever it happens to be. How do I address that? I bring the bookkeeper into the business that-

Dom Price:

Yeah. The little game that we played is you're not allowed to outsource it until you drop it. Right? The idea is, you're going to find a way of dropping it first, because maybe it doesn't need to exist, right?

Nick Muldoon:

Okay.

Dom Price:

Because you've worked at big companies, and you walk around a big company, and you're like, "That person there, they only exist to do a task that someone probably could have automated or got rid of," but they didn't have the time. Also, they put a warm body in the way. Then you add another warm body, another warm body, and you suddenly realize you've got thousands of warm bodies keeping this deck of cards stacked together, and if one card falls, the entire thing comes tumbling down. I removed stuff that I was really uncomfortable removing stuff. I was like, "This is so important." It wasn't. My blinkers were just off, right? Then she's like, "We'll stop doing." She's like, "It's not life or death." She's like, "No, thanks, Dom. Well, you're not a surgeon, so stop doing something, and listen, and see what happens when you stop doing it." I'm like, "Oh, no, but these are really important. People will be angry. I'm a very important person." You remove something and no one bloody notices. You're like, "Why have I been doing this?"

Nick Muldoon:

Why was I doing it? Yeah.

Dom Price:

Yeah. Then I-

Nick Muldoon:

Can you-

Dom Price:

One of the big examples for me was meetings. This wasn't a delegate or [inaudible 00:30:24]. This was me just being a control freak, and turning up in meetings where I wanted to be there just in case. We looked at my condo, just a sea, I use Gmail, right, the sea of blue of all these meetings, double booked, triple booked. She's like, "Right." She's like, "Imagine you've got to set yourself a goal of getting rid of 15 hours." I'm like, "What? It'd be easy to create a time machine that adds 15 hours a week. I can't remove 15 hours of meetings. I'm a very, very important person." Then we played this game called Boomerang or Stick. I declined every single meeting, and I sent a note saying, "This is either a boomerang," in which case it comes back, or if it's a stick. When you throw a stick, it doesn't come back. The boomerangs, I want to know what the purpose of the meeting is, what my role is in the meeting, and what you're going to hold me accountable for.

Dom Price:

Two thirds of the meetings didn't come back. Right? The ones that did, I honestly admit to you, I was playing the exact wrong role in virtually all of them. It was funny because I get these emails back and they're like, so one of this meeting I was in, they were like, "Your role is the decision maker." In the next meeting I was like, "I need to apologize. I thought I was the protagonist." Every time they were suggesting something, I'm like, "Well, you could do that, or these three things." I was sending them into a complete spiral, and they were like, "You're a terrible decision maker." I'm like, "No, I'm a good decision maker when I know that's my job because this isn't your title. Your title stays-

Nick Muldoon:

Ah, Dom.

Dom Price:

... the same, right? Your title stays the same, but your role's different in every environment, every engagement, your role is different. We don't call it out, we just assume. Once we clarified those assumptions and realized I've got them all wrong, the meetings I was in, I was way more effective in. Two thirds of them didn't come back. Either the meeting [inaudible 00:32:09], or it didn't need me in that. If you think about it, and me and you know this, our most precious resources are time.

Nick Muldoon:

Time. Yeah.

Dom Price:

Why are we giving it away for free or for negative cost? Right? I'm like, "No, I'm growing all that stuff back."

Nick Muldoon:

Liz and I have been having this conversation for a while now about statistically speaking, I've probably got 50 years left on earth, based on how long a Caucasian Australian male lives. But I've probably only got 40 good, usable years left, because then you kind of like atrophy and all that.

Dom Price:

Yeah.

Nick Muldoon:

Yeah. Liz and I have been going, "Well, if we've only got 40 summers left, what are we going to do with 40 summers?" It's a really good exercise to bring you think real quick, what do you want to be spending your time on?

Dom Price:

Yeah. Absolutely. It's the same thing. You can do that at a meta, macro level for life, and I think you can do it on a annual quarterly basis. With work, there's so many things that we just presume we need to do, and both the four Ls and just my attitude has enabled me to challenge those and go, "Well, I just say why an awful lot right now." So it's like, "I'd like you to come to this meeting." I'm like, "Oh, cool. Why?" They're like, "I don't know. I'd like you there." I'm like, "But why? Because if you can't explain to me what you want me to do, then you probably don't need me there."

Nick Muldoon:

Five whys, right? Five whys.

Dom Price:

But also the reason I'm often asking them why is I'm like, "You do know I'm a pain in the ass when I do come to the meeting, so just I want to double check to you, you really want me there. Because if you converged on an idea and you want to ship it, don't invite me. All right, I'm the wrong person." Just challenging on that and getting that time back, and then using it for things that are way more valuable. I rebalanced my portfolio just like a financial advisor or a market trader rebalances a financial portfolio every quarter, I did the same thing with me. If I don't, then what I'm saying is when I don't do that, I'm saying the version of me last quarter is more than good enough for them for next quarter. What I'm saying is-

Nick Muldoon:

Yeah, which is never the case, is it?

Dom Price:

Yeah, I'm saying the world's not changed. The world stayed flat, right, and everything's going on a flat line. That's not the case. If I'm not evolving myself at the same pace as Atlassian or our customers, then I've become the anchor by default. I'm the anchor that slows us down.

Nick Muldoon:

Tell me, what portion of your time today are you spending with customers? Because I know over the years in our conversations, I think about a lunch we had at Pendolino, you, Dave, and I, probably two and a half, three years ago now, but we were talking a lot about Agile transformations at the large end of the spectrum. How much time are you spending with customers today, and what are those conversations like?

Dom Price:

Yeah. I'm probably over the 50, 60% mark right now, but mainly a rebalance again. When COVID hit, the conference scene disappeared, and so I'm like, "Cool, I get to reinvest that time. I could reinvest it internally at Atlassian, and I did do it where we're evolving our ways of working internally and driving some change there. I got involved in that, made sense. But I was like, "Hey, our customers are struggling." First of all, we need to understand how and why they're struggling, and then if we can help them, find a way of helping them. It's funny how the conversation really changed from quite tactical, yeah, 18-month plans and presumed levels of certainty, to going, "Hey, the world's changed. The table flip moments just happened. Our business model has been challenged, our employees are challenged. We're having these conversations about people, wellness, and actually, we've said for years we care about our people, but now we actually have to. What does that mean? All the leaders just trying to understand the shift from peacetime to wartime-

Nick Muldoon:

To wartime.

Dom Price:

... to time peacetime. I think that it's funny that the transition from peace to wartime, I think the shared burning platform, the shared sense of urgency, I think a lot of these transition, they're okay. I wouldn't say they're amazing, but they weren't awful given that mostly the Sydney in Australia haven't manage through wartime. Right? We've had an amazing economic success for a long time. The harder bit, the way more complex bit is going from war to new peace, because new doesn't look the same as old peace. Right? It's a very different mindset to go-

Nick Muldoon:

Who is-

Dom Price:

... about managing in wartime is I don't need approvals because it's a burning platform. We just drive change, just do it, just do it. New peace is different because we're like, "Well, how long's this going to last for? What are the principles I want to apply? How do I build almost from a blank piece of paper?" Very different mindset.

Nick Muldoon:

Was that Ben Horowitz with the hard thing about hard things where he talked about war versus peacetime leaders?

Dom Price:

I've read it in a few things. The most recent one I read-

Nick Muldoon:

Hear different places.

Dom Price:

... in was General Stanley McChrystal. He wrote Team of Teams.

Nick Muldoon:

Okay.

Dom Price:

He did one on demystifying leaders and how we've often put the wrong leaders on a pedestal, and there's some great leaders out there that just didn't get the credit because they were way more balanced. But yeah, there's a few different narratives out there on it.

Nick Muldoon:

With the latest that you're meeting with, I guess, well, one, are they using something like the four Ls that Sophie shared with you?

Dom Price:

Yeah, that's become a lot more popular, I mean, certainly with C-suite and the level down, even board members, actually. When I share that, there's this kind of moment of reflection of going, "Yeah." It's because I get them with the irony of going, "Question one, are you driving a transformation?" They're like, "Yes." You're like, "Cool. Are you transforming yourself?" "No." By the way, reading a Harvard Business Review article on Agile doesn't mean you're evolving yourself. That means you're educating yourself. That's subtly different. We've all read the article. It doesn't make you an expert, so sit yourself down. That is the first moment of getting them bought in.

Dom Price:

Then the second one is just saying to them, "Just be honest right now, what are the things you're struggling with?" For a lot of leaders, it's this desire that they get the need for empathy, vulnerability and authenticity, they get it because they've read it. They understand it, they comprehend it, they find it really hard to do. Right? A lot of them are leaving as a superhero leading through power and control. They've led through success, but they're not led through a downturn and a challenging time, and they're just questioning their own abilities. There's a lot of, I don't even want to call it imposter syndrome, I think there's a lot of people just saying, "I think my role as a leader's just changed, and I don't know that I understand the new version." That's quite demoralizing for a lot of people. It's quite challenging.

Dom Price:

The irony being is that the minute they look to that and talk about it, they've done the empathy, vulnerability, and authenticity. They've done the thing they're grasping for. But instead, they're trying to put this brave face on it. In a lot of organizations, I've seen a lot of ruinous empathy. A lot of people buffering from their team, like, "Nick, I don't want to tell you that bad things are happening in the company, because I don't want you ... I think you're already worried, because I won't tell you that," without realizing that you fill in the gaps, and you think way worse things than I could ever tell you. The information flow's changed, and then for a lot of leaders, the mistake I've seen on mass is they have confused communication and broadcast. Right? Communication is what I hear and how I feel when you speak. Broadcast is the thing that you said. Because of this virtual world, there's lots of loom, and zoom, and videos, and yeah, we're going to broadcast out.

Nick Muldoon:

Broadcast a lot. Yeah.

Dom Price:

But we're getting to listen for the response.

Nick Muldoon:

This has to be a very challenging time for a number of leaders today, but 2018 or 2008, there were a lot of leaders back then that probably, I presume, picked up a lot of scar tissue around GFC. How many of the leaders that you're chatting with today would have picked up scar tissue through the GFC, and they're still finding this kind of a feeling, at least, like it's uncharted territory?

Dom Price:

Well, and that's, I think, the byproduct. I was going to say problem. The byproduct of the Australian system is we've dodged the bullet in 2008. Economically, we did not get the same hit that the rest. The stock markets got a little hit, and a whole lot of other things took a little bit of a dip, but nowhere near that the size or magnitude of the rest of the world. Both through the mining boom, yeah, the banking sector, a whole of other tertiary markets around tourism doing well at that time, you're like it was a blip, but it wasn't a scar. I think that's where there's a lot of countries have got that recent experience to draw upon, like, "Here's how we do this. Right? Here's how we bunker down. Here's how we get more conservative. Here's the playbook for it." I think a lot of countries haven't got that playbook, so they're getting at it, right? They're doing it on the fly. I think there's that.

Dom Price:

But also I think this one's just different. The global financial crisis was a financial and market-caused issue, right? This is a health pandemic-caused market downturn. I don't think we've got a playbook for that, because we don't know the longevity of it. -

Nick Muldoon:

If you-

Dom Price:

Go on.

Nick Muldoon:

Yeah. No, sorry, Dom, I was just going to ask, if you cast your mind back to GFC, were you anxious going through GFC? Have you been anxious this year?

Dom Price:

No. I wasn't anxious at all through GFC because it felt like ... I did a recession in the UK a long, long time ago, and so I've been through that downturn. I've worked in companies that had downturns, even if the general economy was fine, and industries that had shrunk, where at the end of each quarter you're like, "Right, we talk about the books. Who are we letting go? What projects are stopping?" It was always the taking away, not the adding. I've been through that. The thing that made me anxious about 2020 was, this is the first time I think we've had this level of uncertainty. It's funny because a lot of people talk about change fatigue. I actually think humans are quite good at change. I think we actually do that quite well. But uncertainty, we are terrible with.

Dom Price:

It's weird how when we get uncertainty, how different people respond in different ways. Some like to create a blanket of certainty and wrap it around them like, "Now, here's what I know, and this will come true." You're like, "Maybe [inaudible 00:42:16]." I like your blanket, it's comfortable. But it's not necessarily real, right? It's not going to shelter you from the things that we genuinely don't know about. This is where agility has become key, or nimbleness has become key because if I look at the leaders in the companies that are listening, they're actually attentive to their customers and listening, they're the ones that are evolving really quickly, because they've got ... not only have they got the nimbleness as the muscle, but they're listening to cause correct. The ones that have ... think they've rolled out agility in the last few years, but never added the customer bit, they've got small, fast, nimble teams just running around in circles.

Nick Muldoon:

They're not heading in a particular direction. Yeah.

Dom Price:

Yeah. They are clueless, right, because without that overarching like, "Why are we doing this? And that customer that we care for, we still care for, how's that customer's world changed? Right? Because if that customer has changed, how can we change with them?" A lot of companies haven't done that yet, and I think it's some are holding the breath and hoping for the best. Some are just too fixated on, "But we have a plan, and if we stick to that plan," I read a book somewhere that said, "If you stick to a plan, you'll be fine." You're like, yeah, the world just shifted around you. Your plan might not be as relevant.

Nick Muldoon:

It's making me think, Dom, about the Salesforce transformation, Agile transformation in 2006. That was one of the big bang, I think it was one of the early big bang Agile transformations that took place. I don't know if it was Parker Harris or how it actually played out, but the leaders of Salesforce basically said, "You're going to change to Agile. You're going to give this thing a go. Otherwise, all is lost." There's been other examples. I think shortly after, LinkedIn did their IPO. They pulled the end on call, they stopped everything to rework how they work. Is 2020 one of those years? Are the best companies going to take advantage of this as an opportunity to retool how they work? Then the other companies are just going to kind of atrophy and slowly decline over the next five?

Dom Price:

I think the best ones probably built some of the muscle already, the ones that are now reacting, right? I think if you are aware of the market, all COVID's done is put an accelerant on the stuff that was changing anyway. Right? Yes, it's not ideal, but it's stuff that was happening regardless, right? I think we really had five or 10 years to equip ourselves, and we got given three months instead. I think a whole lot of companies that saw those patterns emerging, changing people habits, technology, practices, ways of working, customer demand, experience demands, you put all those together, that's why Agile transformation has been a massive hit for the last three, four, five years, right? The ones that were prepared for that are awesome. The ones that responded quickly, that are like, "Brilliant, don't let a crisis go to waste. What can we do?" They'll do well. The ones that have dug their heels in and are being stubborn ,saying the world will return to normal and it's just a matter of time, they're the ones that I fear for, because that atrophy that may have been a slow decline, I think that becomes a cliff. Right? Because in a consumer-

Nick Muldoon:

Slow decline, and then they just fall off the edge at some point.

Dom Price:

consumer world, consumers spending goes down, sentiment goes down, and relevance suddenly becomes really important. Is your product relevant to your customers? The people that understand that, and then have agility in how they deliver it, that's a winning combination. I think the interesting, I was talking to a friend about this on the weekend because they were like, "What's the difference between the successful ones and the not successful ones?" It's hard to pinpoint a single reason. But the one that stands out for me is the Agile transformations that have been people-centric are the best. A whole load of them were tool-centric or process-centric. I will send all my people on a training course. I'm going to make you agile, I'm going to give you some agile tools. Go. You're like, "Did you change their mindset? Did you change their heart? Did you change the things that they're recognized for, their intrinsic motivations? Did you change those things?" Because if you didn't, their inner workings are still the same, right? You've just giving them some new terminology.

Nick Muldoon:

I think that's a really, really, really good point. I go back to if I cast my mind back to the first Agile conference that I went to over a decade ago, the conversation back then was very much around training the practices, teaching the practices to your people, and then it evolved into a tooling conversation. But again, teaching the practices and software are just tools, and it was probably 2013, 2014, I guess, when the modern Agile movement came out, and they were talking a lot about psychological safety. Go back to where we started the conversation, right?

Dom Price:

Yeah.

Nick Muldoon:

Psychological safety, bring your whole self to work, and that will free you and enable you to do something tremendous for your customers. Give me a sense of the customer conversations that you've had throughout 2020. What percentage do you think have psychological safety, truly have that psychological safety?

Dom Price:

Yeah. I have to remind myself that psychological safety isn't an all or one, right? It's a sliding scale. I would say it's improved, where it's done with authenticity. The danger is, it becomes a topic where people are like, "I was working from home. There's an increased chance of stress, it's a whole of a change. Things are going wrong. Oh, I know what, let's just talk about psychological safety a lot." You're like-

Nick Muldoon:

That's not it.

Dom Price:

... "There's no correlation between talking about and doing." Right? It becomes the topic, right, the fashion, right? Just like wellness and mindfulness have become fashionable to talk about, doesn't mean we've got any better at it. And so that-

Nick Muldoon:

But isn't that the thing, Dom? Agile was the fashionable thing to talk about, and so we talked about it, but nothing really changed in a lot of these organizations.

Dom Price:

Yeah. It's not dissimilar with psychological safety. What has happened though is over time, the leaders that are truly authentic, vulnerable, build that environment where you can bring your best self, and they appreciate the respectful dissent, but they will still, at the right time, disagree and commit. They're like, "Nick, I heard your view. Thank you for sharing. Our only decision at this point, we're going down Path A. I know that you're in Path B. We're going down Path A. When we leave this room, we commit to A." I hear you. You want me when we're coming to A, and here's the signals we'll assess to make sure it's the right path. If it's not, we'll course-correct. Those people are thriving in this environment, and more people want to work with them. What this environment has done is it's shone a massive light on the difference between managers and leaders. Managers manage process and they like control. Right? Leaders are about influence and people.

Nick Muldoon:

Do you think, so the fact that people are working remote and working from home, that's made it easier to see who the leaders are.

Dom Price:

Yeah, it's shone a light on-

Nick Muldoon:

Because the managers are just trying to count time.

Dom Price:

Yeah, count time, but they're also thrashing around busy work, because they're like, "I'm the manager. I need to show that I'm doing something. I would manage tasks in and around the office, and what I meant some people to do. If we're autonomous, and they just do it, then what's my role?" You suddenly start seeing business. This noise comes out of them, which isn't, "Here's an outcome I achieved, or here's how the team's doing on team cohesion or bonding." They're not talking about about big meta level things. They're sharing these transactions with you, and you're like, "I assumed you're always doing the transactions. Now, you're showing me them all. It's a bit weird." Right? It's just a behavior, right? We must have a process for that. Well, what's the process? You're like, "Actually, what about the process of common sense?" Right?

Dom Price:

If you think about pre-COVID, most organizations that would allow people to work from home once or twice a week had a giant process and policy about how you apply to work from home that one day a week and everything, and then suddenly they're like, "Well, actually, we can do that. Everyone's going to go work from home." But now things have settled down a bit, the process police and the policy police are coming back again going, "But what about, what about? We pay Nick to do 40 hours a week, and what if he didn't do 40 hours?"

Nick Muldoon:

40 hours a week.

Dom Price:

Who cares? Nick delivered his outcomes and his customers are over the moon. As long as he's not doing 80 hours and he's not burning out, doesn't matter? Right? The idea of 9:00 to 5:00, Monday to Friday as a construct is being challenged. The idea of you needing to sit at a physical desk for eight hours a day to do your work, when actually at least half of your tasks you can do asynchronously, that's been challenged. But for the managers who want manage process and control, they're like, "But if Nick can work from anywhere, and we trust him to do the right work, what do I do? I'm his manager. You're like, "You could inspire him. You could coach him, mentor him. You can lead him, you can help him grow, you can do a whole lot of stuff. Just don't manage his tasks for him. He's quite capable of managing a to-do list." It's challenging that construct again. For a lot of people, that's uncomfortable because that's a concept that we've just stuck with for years.

Nick Muldoon:

This is going to lead to a lot of change. I guess I've been thinking with respect to remote, Dom, I've been thinking much more about the mechanics of remote work and logistics around pay scales, and geographic location, and pay, and all this sort of stuff. But you're really opening my eyes to a whole different aspect. There are, in many large organizations, there are a lot of middle managers, and if these roles are no longer valuable, what do all these people do, and how do we help them find something that they love and that they long for? Because presumably they've not longing for-

Dom Price:

Yeah, that's the thing.

Nick Muldoon:

... task management.

Dom Price:

Yeah, yeah. They're probably not deeply entrenched in that as being something they're passionate about, right? It's just like they found themselves in this role. This is the interesting thing. If you look at rescaling, I've been looking at rescaling for a few years as a trend, right? How do we look at the rate of change in both technology, people practice, whatever else? That means that we're all going to have to rescale, right? The idea of education being up until the age of 21, and then you're working 45 years doesn't exist, right? So lifelong learning. You look at that, and you go ... Amazon did a great example last year. Bezos and Amazon put aside a billion dollars to retrench a thousand people that they were going to dispose. Right?

Nick Muldoon:

Yeah, yeah, yeah.

From their warehouses, right?

Dom Price:

Yeah, yeah. They're on automation to displace those people. What was came out recently and said, there's I think, it's like 1,500 people who will be displaced because they're going for fully autonomous distribution centers. They're looking to retrain those people and redeploy them elsewhere. You're like, "Cool, how are we doing that?" The reason I mentioned it is I think we assume it for low skilled, high volume tasks, because that's associate what we've associated with technology disruption in the past. But if you think about it, there was I think about a year and a half ago, McKinsey had a report called The Frozen Middle Layer. It was about how this frozen middle layer was going to thaw and be exposed, right, as these middle managers. There's thousands of them. That phrase, the middle layer, COVID just poured the icing on that. Right? [inaudible 00:53:26]. They're all going, "What? Me? No, no, I've only got 10 years left in my career. Let me sit here, manage a few tasks. I'll take inflationary pay rise every year. I won't cause any trouble." You're like, "I don't know. You can retrain here."

Dom Price:

These people haven't been engineered to think about retraining before. They've been engineered to think about comfort and conservatism and safety. I think we need to appreciate that they still have value in the workplace. I just don't think it's the old value. For them, the four Ls-

Nick Muldoon:

This is going to be a huge shock to this frozen middle layer, as McKinsey called it. I think about so we're Wollongong, Port Kembla. We're in a working class, steel town, and over the course of, pick a number, over the course of 25, 30 years, 20,000, 22,000 people have been let go from the steelworks and they're been told to retrain. I'm sure a portion of them do, but a lot of them that are older, like you're talking about someone that's in their 50s that's got 10 years on their career, right, they probably just took early retirement, and maybe they found something else to do in the community, whatever it happens to be. What are the structures that we provide for this huge crew of people to get them re-skilled in our businesses so that we don't lose the tacit knowledge and get on to the next thing? How's Atlassian thinking about this?

Dom Price:

It's also about front-loading it, right? We have to hold our head in shame as a general society, how light we leave it. When I hear stories about those steelworks closing down, and you're like, "Why are we surprised by that? Why are we surprised when Holden stopped developing cars in Australia? Really? But really, you're surprised?

Nick Muldoon:

We saw it coming.

Dom Price:

Yeah.

Nick Muldoon:

We propped up the car industry in Australia for 35 years.

Dom Price:

Yeah. You put tariffs on anyone importing to make your own industry look good, and then those tariffs go away, people are looking for cheaper. Unfortunately, we signed up for a global economy, right? It's a borderless business model that we're in, and whether you like that or not, it's what we signed up for. The reality is instead of reacting each time this happens when it's normally too late, how can we respond? How can we use these brilliant algorithms and data managing to go, "Here are world economic forum future skills, here are large employers, here are other skillsets about people." You try and give that out, and you're like, "These are the ones most at risk, and they're at risk over the next 18 months." Cool. Start retraining them now, but not when they're out of the job when they go, "Well, now, I'm out of my job. Now, what do we do?" You're like, "I don't know. Buddings? I don't know."

Dom Price:

We've got way more data and insights than we probably give ourselves credit for. I think one element is front-loading it, and the next one is saying, "How do we not recreate this problem again?" If you look in the US right now, the largest employer, not by company, but by job type is driver.

Nick Muldoon:

Okay. Yeah, by role. Yeah, yeah, yeah.

Dom Price:

By role, right? So Uber driver, truck drivers, manual drivers, people behind the wheel driving a vehicle. Where's billions of dollars worth of investment going in, Google, Amazon and every other? Right? Autonomous vehicles. You're like, "Cool."

Nick Muldoon:

Autonomous vehicles. Get rid of all those people?

Dom Price:

If I-

Nick Muldoon:

What are we doing to reskill those people?

Dom Price:

Yeah. Or even better, what are we doing in our education system to say, "How do we help people coming through the education system be more resilient with their future skills? I don't like the idea of being able to future-proof people. I don't think we've got a crystal ball, so let's part that. But how do we make people more resilient in their skills, well, all the skills we think will be required? World Economic Forum do great research every few years and publish it, and then I look at the education system, and I'm like, "That was built in 1960. We're tuning kids out that if you talk to.

Nick Muldoon:

Hey, hey, hey, Dom, okay, okay. I'm getting anxious at the moment. Let's end on a high note. What are things that make you optimistic for the next decade? All right? In 10 years time, how old are you going to be in 10 years time? Like 45 or something?"

Dom Price:

52.

Nick Muldoon:

52?

Dom Price:

Yeah.

Nick Muldoon:

Okay. Oh, yes.

Dom Price:

Getting old.

Nick Muldoon:

Yeah, okay. Yeah, okay. Okay, so when you're 52, what are you looking forward to over the next decade? What's exciting?

Dom Price:

There's a couple of things we need to realize, right? Very first thing we need to accept is our future is not predetermined, it's not written, and it's not waiting for us. Right? We design it and define it every single day with our actions and inactions. As soon as we have that acknowledgement, we don't sit here as a victim anymore and wait for it to happen to us. We go, "Oh, oh, yeah." Then like, "We have to decide on the future. No one else does. We collectively do." That's the first step. You're like, "Oh, I've got way more say in this than I ever realized." The second one is, we need to drop a whole load of stuff around productivity, and GDP, and all these things that we've been taught are great measures of success, and just be happy and content in life. If you've got four years left, I've probably got 30 something years left, I want to enjoy those 30 years. I have no vision of being buried in a gravestone somewhere with, "Dom was productive."

Nick Muldoon:

Dom, this is great. What we've got to do for society over the next 10 years is get society out of KPIs and into OKRs.

Dom Price:

Yeah.

Nick Muldoon:

Right?

Dom Price:

And get a balance out of going, "How ... This is what I've learned from COVID, right? You know this, I did 100 flights last year. I did a few at the start of the year and trip to the UK in the middle of COVID. But I've not traveled since June. Now, admittedly, the whole work from home thing, I'm going insane a little bit, but the balance of life, like sleeping in my bed every night, hanging out with friends, meaningful connections, right, actual community. I've lived in the same apartment for three years, and it took COVID for me to meet any of my neighbors, and it took COVID for me to meet the lovely ladies in the coffee shop downstairs. I'm like, "I've lived above you for three years, and it's only now you've become a person." Right?

Dom Price:

There's so much community and society aspects we can get out of this. The blank piece of paper, if you imagine this as a disruption that's happened to us, and there's no choice, and we can fight against it, that the options we have to actually make life better afterwards. Whether it be four-day working week experiments, or actually working from anywhere means that a whole other disabled, or working parents can get access to the workforce. Funny, if you get more done. Unemployment in the disabled community is 50% above that of the able-bodied community, not because of any mental ability, just because it's hard for them to fit .

Nick Muldoon:

Logistically. Yeah.

Dom Price:

You've just changed that, right, with this crazy experiment called COVID. If we start to tap into these pockets of goodness, and actually, we sees this as an opportunity to innovate, right, and I hate the P word of pivot, but forget pivoting, to genuinely innovate, what might the world look like, and how can we lean into that? How do we get balance between profit, and planet, and people, and climate, and all those things? If we do that, we've got a chance to build this now and build a future we want that we're actually proud of. I think the time is now for us to all stand up because it's not going to happen to us ... Or it will happen to us. If we choose to do nothing, it'll happen to us. It doesn't need to. I'm really excited because I think we're going to make some fundamental changes and challenges to old ways of working and old ways of living, and we'll end up happier because of it.

Nick Muldoon:

Don, I'm super jazzed, man. Thank you. I really appreciate your time today. That's a great place to finish it up.

Dom Price:

I hope some of those things come true.

Nick Muldoon:

Okay. I hope some of those things come true, right? I feel like the things that are in our power, the things that we can directly affect, takeaways for me, I've got extending the love and loathe into the love, loathe, long for and learned. I think that's great. I also like the boomerang versus the stick with respect to your time and what's on the calendar, and just jettison the stuff that is, well, it's not helping you, or the teams, or anyone else. Yeah.

Dom Price:

You could do it like [inaudible 01:01:33]. If it ends up being important, you can add it back.

Nick Muldoon:

Sure.

Dom Price:

[inaudible 01:01:38].

Nick Muldoon:

The big takeaway from this conversation for me is that it's in our hands. The choice, we make the decisions. It's in our hands. I think about, was Mark Twain, whether you think you can or whether you think you can't, you're right.

Dom Price:

Yeah. Yeah.

Nick Muldoon:

You might as well think you can and get on with it.

Dom Price:

Yeah, yeah, give it a red-hot stab and see what happens.

Nick Muldoon:

All right, cool. Don, thanks so much for your time this morning. Really appreciate it.

Dom Price:

It was great chatting.

‍

In this episode, we dive deep into the challenges of aligning teams with strategic goals across organisations of all sizes. From fast-growing startups to large enterprises, teams everywhere struggle with the same fundamental issue: translating high-level objectives into actionable work that drives real value.

Our guest Andreas Wengenmayer, Practice Lead for Enterprise Strategy and Planning at catworkx (the #2 Atlassian partner worldwide and #1 in EMEA), shares his 11 years of experience helping organisations bridge the gap between strategic vision and team execution.

Want to see these concepts in action? Andreas and Hayley hosted an interactive webinar where they demonstrated practical techniques for strategic goal alignment using Easy Agile Programs. Watch the recording here→

About Our Guest

Andreas Wengenmayer is the Practice Lead for Enterprise Strategy and Planning at catworkx, one of the leading Atlassian Platinum Solution Partners globally and the #1 in EMEA. With over a decade of hands-on experience helping enterprise teams scale agile effectively, Andreas specialises in bridging the gap between strategy and execution. His work focuses on guiding organisations through complex transformation programs, optimising portfolio planning practices, and helping teams adopt frameworks like SAFe with clarity and purpose. Known for blending pragmatic insight with systems thinking, Andreas brings stories from the field - ranging from fast-moving startups to complex, multinational enterprises.

Transcript

Note: This transcript has been lightly edited for clarity, readability, and flow while preserving the authentic conversation and insights shared.

Recognising the signs - when teams aren't aligned

Hayley Rodd: Awesome to have you here. So I'm going to start with a bit of a reality check. We've worked in organisations across the spectrum from really fast-growing startups to really big enterprises. From your experience, when you walk into a PI planning or quarterly planning session, and I'm sure they're pretty hectic, what are the telltale signs that teams aren't truly aligned on what success looks like?

Andreas Wengenmayer: That's a great question - one I hear frequently. You can imagine, especially post-COVID when teams returned to in-person planning sessions. Back in 2017, we'd have huge arenas with hundreds of people in one place. People are happy to see each other, excited to chat with colleagues from different locations. This became even more pronounced after COVID, when everyone was working from home more frequently. That's a good sign - the mood is positive.

But you also notice some teams under pressure. They'd rather be working on actual deliverables. They know they have to be there, and it takes two full days to complete all the planning. Meanwhile, they're carrying a mental backlog - technical debt, unfinished work from the previous PI, catching up on delayed items.

This is what I often observe: teams get bogged down discussing minor details. People debate specifics, and you can see they're frustrated about something deeper - but they're not addressing the root cause. This creates its own negative momentum and can derail otherwise solid planning sessions.

Teams get bogged down discussing minor details. People debate specifics, and you can see they're frustrated about something deeper - but they're not addressing the root cause. This creates its own negative momentum and can derail otherwise solid planning sessions.

Sometimes you have to step in and ask what's really underneath. What's the actual cause? People say, "Yeah, I have to be here because that's the format, but I'm not engaged." Maybe it didn't work well in the past and there's lingering skepticism.

The prevailing attitude then becomes: "This isn't really collaborative. Leadership plans from the top anyway. The outcomes are predetermined - here's the plan, just make it work and update your boards." When people feel they can't meaningfully contribute or influence direction, they simply go through the motions.

My favourite example happens at the end when teams must formulate their objectives. It becomes a box-checking exercise - create something that satisfies the coach or Release Train Engineer so everyone can "get back to real work."

What good alignment actually looks like

Hayley Rodd: You've touched on so many things there. I can imagine walking into that room and feeling the pressure. People getting caught up in minor details rather than talking about root causes, or not asking the five whys to get to that root cause. You also touched on getting buy-in across the organisation. When people are really nailing it, when alignment is really there, what does that room feel like?

Andreas Wengenmayer: Yes, I've fortunately experienced those environments, and they're actually more common than you might think. When companies genuinely commit to grassroots planning, truly investing the time it requires, and ensure teams aren't overwhelmed from the start with everything marked "priority zero," you create the foundation for successful planning.

When companies genuinely commit to grassroots planning, truly investing the time it requires, and ensure teams aren't overwhelmed from the start with everything marked "priority zero," you create the foundation for successful planning.

You can see it immediately in people's body language and interactions. The energy in the room is palpable. If people appear resigned or intimidated, afraid to speak up, that's typically a red flag. The opposite creates magic.

Think about high-performing teams, like being a Scrum Master with an exceptional group. The best teams aren't just collections of highly skilled individuals in specific roles.

The best teams are those who communicate openly, genuinely enjoy each other's company, maintain positive energy, and actively support one another. This dynamic enables remarkable achievements. Maybe someone knows a contact in another tribe, release train, or department who can provide crucial answers and facilitate communication. Communication is absolutely fundamental.

That collaborative spirit is the hallmark of truly effective teams.

Hayley Rodd: Absolutely. We would know it in our day-to-day work, right? If your teams aren't communicating, if they're too overburdened as you said, it's not a good place to start. But if you can get that starting point right, if you can get that communication right, so many things will flow after that.

Andreas Wengenmayer: Absolutely. Looking back at any planning cycle, the real test is: did you plan the right things? You only know at the quarter's end whether you estimated capacity accurately.

Here's the crucial question: How does your organisation respond when goals aren't met? Do stakeholders focus on finding solutions? Do team members feel safe asking probing questions and seeking answers? Or does the blame game begin, searching for scapegoats?

How does your organisation respond when goals aren't met? Do stakeholders focus on finding solutions? Do team members feel safe asking probing questions and seeking answers? Or does the blame game begin, searching for scapegoats?

When you're permitted, encouraged, even, to be genuinely open and honest, you become much better at assessing realistic capacity. What makes stakeholders universally happy is predictability. You want confidence that your plans will actually materialise, that your commitments will be fulfilled.

Success breeds success, creating a positive foundation for the next PI. It's a continuous cycle that can spiral upward toward excellence or downward toward dysfunction.

The startup vs. enterprise spectrum

Hayley Rodd: Let's talk about the two ends of the spectrum. You've got a lot of experience, so I love hearing about this. Small companies will often say, "We're agile, we can pivot quickly, we don't need formal goal setting." Then enterprises are going all out on OKRs, cascading objectives, saying they're aligned because they've got those things in place. Yet both struggle with the same core problem. What's really going on?

Andreas Wengenmayer: You're absolutely right. I've been in agile projects since 2014, 11 years now, and I've seen a lot of companies pre-COVID, post-COVID, different sizes.

Starting with the really small ones, startup companies - what's really astonishing is that some very small startup companies tend to become overly complex, which is amazing. Some want solutions that are way too overblown. Basically, they need a sailing boat, but they're thinking about ordering an aircraft carrier.

Some startups want solutions that are way too overblown. Basically, they need a sailing boat, but they're thinking about ordering an aircraft carrier.

Maybe that's part of startup CEO culture - where everyone's a CEO on LinkedIn, and they think, "We're corporate, we have to be like that." They mostly get to their senses in the end, but small companies tend to be overly complex and overblown when it comes to technology, tooling, and organisation.

On the other end, large corporations sometimes seem to try their best to become truly agile - living the values everywhere. Still, it's a challenge. In most cases, there's some kind of hybrid planning going on. There's still a roadmap, which is good, but at some level, some people still stick to classical approaches, have some waterfall going on in the back.

I personally have never seen, for example, a full SAFe organisation where it's done truly at every level. There's a good balance and it should be healthy, but it all comes down to execution.

I feel like mid-sized companies are often the healthiest when it comes to that.

There's a balance of method and tooling, but you still need a solid understanding of goal setting and tracking. This includes pivoting when goals aren't right and learning from how you did things in the past. The gap between management and teams isn't that huge, and it's easier to bridge.

Avoiding death by KPI

Hayley Rodd: You've touched on so many fundamental things around getting the method and tooling right, but also that cultural aspect. I love the insight around mid-size organisations often striking that balance well. When we're thinking about the enterprise risk - which could be "death by KPI" or OKR, do you agree? Can you paint a picture of what that looks like and how it actually makes teams less focused?

Andreas Wengenmayer: Absolutely. There is such a thing as "death by KPI." KPIs are important to get a clear picture - you do need metrics, and there's merit to it. But as always, it's about choosing the right KPIs, the right metrics.

My favourite example is comparing story points across teams or ARTs. You measure velocity, and I have to repeat again and again: it's only individual to one team. You shouldn't compare it to another team or across tribes or ARTs - that doesn't work because you're creating the wrong incentives.

You see what will happen: "Well, okay, my stakeholders want higher amounts of story points. Let's estimate the stories bigger." Of course, that's a continuous loop, but it doesn't give you anything. Story points as a metric are just guidance for a team to get a better feeling for estimations.

You see what will happen: "Well, okay, my stakeholders want higher amounts of story points. Let's estimate the stories bigger." Of course, that's a continuous loop, but it doesn't give you anything. Story points as a metric are just guidance for a team to get a better feeling for estimations.

You want predictability - you want to meet a certain range. So it's not a great KPI when it comes to monitoring progress across teams. They have better KPIs in place.

Other metrics tend to create what I call bureaucracy. If you spend too much time creating reports, you have less time to create anything of value.

Hayley Rodd: I think there's so much in what you're saying about people being realistic and honest, open to pivoting or changing a goal if it's not the right one. Admitting to that is really difficult because no one wants to admit that what they set out to do is failing. But understanding that failure can sometimes be a benefit - you can learn from that. There's so much in that cultural aspect, right?

Andreas Wengenmayer: Absolutely. Coming back to goals rather than KPIs - KPIs are like being on a boat in your control room. You see what the engine is doing, the temperature - those are KPIs. Goals, on the other hand, are the course that you set.

KPIs are like being on a boat in your control room. You see what the engine is doing, the temperature - those are KPIs. Goals, on the other hand, are the course that you set.

You could be a small company like a startup - you're in a canoe, you're rowing. Or you're a large company - you're like a big freighter. Still, if you don't set the right course, the right goal, you will never reach your destination. Your team can be as proficient and perfectly working as they could be. If the course isn't right, hopefully you have enough provisions on board to survive a long journey.

Where organisations get stuck in goal setting

Hayley Rodd: Where do organisations typically get stuck? Is it defining the goals, communicating the goals, or translating them into action - that execution point you made before?

Andreas Wengenmayer: It could be basically any one of those. If you have a smaller or mid-size company, it's easier to communicate - you don't have to bridge as huge a gap. But still, you have high-level goals that have to be translated into real work. Real value is created in the teams.

If you have a high-level goal that's highly abstract and sounds good on paper - "increase customer satisfaction," "create better products," "make the world a better place" - people still have to understand: What does that mean to my daily work? If I'm a developer, what's my stake in that? How can I contribute?

If you have a high-level goal that's highly abstract and sounds good on paper - "increase customer satisfaction," "create better products," "make the world a better place" - people still have to understand: What does that mean to my daily work? If I'm a developer, what's my stake in that? How can I contribute?

That's when communication and breaking down goals becomes really important. Breaking them down the right way, having them visible and transparent, and creating that feeling of contribution. You make it visible that you're not just working for yourself or your team, but you're really contributing. You understand what you're working on and why you're doing it. Purpose is critical.

Bridging the strategy-to-sprint gap

Hayley Rodd: That's a really good segue into the next question about translating strategic vision into team-level objectives that people can grab onto and execute. Leadership will often say something like "increase customer satisfaction," and teams are left going, "What does that mean for me in my sprint this week?" How does an organisation bridge that gap between the high-level leadership view and what we can do in our sprints as a team?

Andreas Wengenmayer: First of all, you as company management need to take the time. There have been, and still are, a lot of approaches with company values, putting posters on walls, creating marketing. Those are all values - that's what a company is like. Then you link it with your products, services - great services, customer satisfaction. Okay. Then comes the real challenge: we want to succeed and create the next service, software solution, or product.

The goal is clear on a high level, but how do we break it down? That's when the real work comes into play - breaking down the goals into smaller pieces.

It's like building a LEGO space station when I was a kid. You have the picture on the box in the beginning - 'Oh, that's what we're going to build.' Then you have to start putting together all the small pieces. You need a plan, you need the little pictures of the steps. You start with the big picture, then you're breaking it down one piece at a time. You create different parts, and they come together at the end. Same goes for goals.

It's like building a LEGO space station. You have the picture on the box in the beginning - 'Oh, that's what we're going to build.' Then you have to start putting together all the small pieces. You need a plan, you need the little pictures of the steps. You start with the big picture, then you're breaking it down one piece at a time. You create different parts, and they come together at the end. Same goes for goals.

Hayley Rodd: Nice. A colleague of mine often says you eat an elephant one bite at a time - similar thing, right? When you see that big goal, it's really overwhelming. But if you can break it down into those chunks and smaller pieces, it becomes so much more manageable and achievable. People can get behind that vision.

Managing moving targets

Hayley Rodd: In fast-moving environments, goals often shift. We're agile, we're always moving. How do you help teams stay connected to a moving target without either ignoring changes or constantly thrashing around?

Andreas Wengenmayer: Back in the nineties and early 2000s, there was a computer game that wasted a lot of time in offices where you were shooting at geese in Scottish Highlands. It was a big phenomenon because people were trying to get the next high score.

If you think of moving targets, it's a bit like that. Imagine you're doing your work - whether you're a hunter or developer doesn't matter - but you approach, you take aim, and the geese keep flying up. You miss the target. Same thing if you have moving goals.

It's harder to aim and approach them right. What you should avoid as a company or someone in charge is constant interference. Stick to your goals or objectives that were agreed upon during PI planning. Don't change them midterm during a PI.

What you should avoid as a company or someone in charge is constant interference. Stick to your goals or objectives that were agreed upon during PI planning. Don't change them midterm during a PI.

That doesn't mean you can't learn from mistakes or wrong goals. You can adjust them, but you have to adjust them in the right place and time, which is during planning. Of course, if something security-related comes up, you have to act, but it has to be agreed upon, and you still have to communicate it and create understanding.

Keeping goals visible and actionable

Hayley Rodd: Even when goals are well-defined, keeping them visible and actionable throughout a PI is tough. What practices or tools have you found most effective for maintaining connection between daily work and high-level strategic objectives?

Andreas Wengenmayer: Good question. Having the goals present at all times helps a lot. If you just meet for planning, have your goals set, and never look back during the PI, it doesn't do you any good.

That could be a piece of paper on the wall like we had back in the day - and still could be if you're working in the office. Also, choose the right tools to track the goals and create acceptance for tools. Really use them. Look into them - whether it's an OKR tool or some other solution, even PI objectives. Are we still on track?

What really helps is if it's not static but shows progress, and especially shows the link of what you're contributing - like what you achieved in your last sprint and how it plays into the objectives or goals, progress moving ahead. There's always a good feeling - everybody loves a green bar moving ahead or a checklist.

What really helps is if your tool is not static but shows progress, and especially shows the link of what you're contributing - like what you achieved in your last sprint and how it plays into the objectives or goals, progress moving ahead. There's always a good feeling - everybody loves a green bar moving ahead or a checklist.

It helps keep the vision and goals present.

Hayley Rodd: When I was a teenager in my final year of high school here in Australia, I wanted a specific score on my final exams. I had a big poster in front of my desk that I sat at for hours every day studying. Looking back, I didn't know what I was doing - I just wanted to visualise my goal, and I didn't know the psychology behind it. But I'm happy to report I got that mark and above.

I think it was as you were saying - that constant reminder, that piece of paper worked for me. In organisations, we're looking for something a bit more complex sometimes, but I like your "keep it simple" advice. It doesn't always have to be super complex. It can just be a checklist, progress bar, or piece of paper - something that helps you feel connected to the goal and reminds you of it often.

When good work doesn't align with goals

Hayley Rodd: Have you seen situations where teams were delivering lots of work - good work, but it wasn't clearly contributing to company goals? What tends to cause that disconnect?

Andreas Wengenmayer: Yeah, that happens quite a bit. I can think of one example with very technical teams, like in semiconductors. Very smart people - everyone has a PhD in physics, material science. Awesome, smart people who tend to love their job. They're awesome, but they're also perfectionists who can still improve things and want to make them even better.

If you're in the business of producing machines used to produce semiconductors, for example, it's a complex task with a complex supply chain or value chain. You're creating lithography machines to create wafers used by other companies, and in the end, you have a customer planning the release of a new phone.

Your customer waits, the end customer waits, and you have to deliver on time. Sometimes this creates a challenge because teams still want to improve and make it even better. That's when economics come into play - the view of the big picture. You still have to communicate it. You shouldn't discourage such a great team, but you need to get the bigger perspective back to the teams and create acceptance instead of saying, "Hey, stop what you're doing, it's good enough." You don't want that. It all comes back to transparency and communication.

On the other spectrum, what you sometimes have is just too much workload on teams. Time for planning gets cut short, and if you don't take enough time to plan well, no wonder the results don't work out. It's just a lot of busy work - a lot of things getting done, but not necessarily the right things at the right time.

On the other spectrum, what you sometimes have is just too much workload on teams. Time for planning gets cut short, and if you don't take enough time to plan well, no wonder the results don't work out. It's just a lot of busy work - a lot of things getting done, but not necessarily the right things at the right time.

Hayley Rodd: If you don't do that planning at the start, you're setting yourself up for misalignments. If you're not communicating that plan regularly, you're setting yourself up for that busy work and people getting distracted. It's just so common. That planning part is so fundamental to getting it right.

One piece of advice for frustrated leaders

Hayley Rodd: We're on the home stretch now. If you could give one piece of advice to an engineering or product leader who's been frustrated because their teams seem to be going through the motions of PI planning or quarterly planning without real buy-in, what would it be?

Andreas Wengenmayer: I can resonate with that so well, and many can. I'd say: take the time to find out what's really going on. Investigate the root cause. It's like if you have a house and you're trying to fix a crack in the wall - you can look at the crack and do some superficial fixing or use a thick layer of paint, but you still have to find out what's causing that issue. Maybe something deeper.

You mentioned the five whys - that can be one way, but you have to have some understanding of the right way to approach people. You don't want to put anyone on the spot. Looking for a scapegoat doesn't help anybody.

We need to look at what's behind it, what's causing it. It all comes back to investing enough time for planning, but doing it with purpose. Not doing the whole planning like theatre, where everybody acts their part - that doesn't do you any good.

It all comes back to investing enough time for planning, but doing it with purpose. Not doing the whole planning like theatre, where everybody acts their part - that doesn't do you any good.

People have to understand why they're doing it. There has to be purpose and understanding - enough time, no distractions, and a positive atmosphere where everybody can contribute and be open.

You don't want people saying nothing because they don't dare to criticise or say no.

The connection between goal clarity and team motivation

Hayley Rodd: What's one thing you wish more organisations understood about the connection between goal clarity and team motivation?

Andreas Wengenmayer: We could get back to the boats we mentioned before. You want to arrive at your destination. If you're not clear about the destination, or maybe some people in your rowing boat don't want to go there, they might not join the rowing. If your crew is not invested, it will take you longer to reach a destination, or you won't get there as well.

It's the same thing. Motivation is key, and I don't talk about superficial motivation that just annoys everybody. Motivation is a positive environment where people rely on each other. They really like spending time with those people.

"Hey, I really like to go to lunch with you and talk to you" - not "I'd rather be home and not talk to anybody." You're not annoyed if your teammate asks you a question; you're happy to help. You're feeling safe that when you have a problem or question, you will get help.

That creates the right kind of motivation - that positive environment, and that can make a lot of things happen. It comes back to openness and transparency, not as buzzwords, but to get the clear picture. As a stakeholder, you get the correct current state because you get true answers.

I've seen strange situations in major corporations where people really didn't report what they were working on or show the right results. I've seen complete shadow Jira environments - one for internal use and one for external use with customers. There can be huge misalignments because people didn't dare to show real progress. In the long term, it will backfire. If you don't have trust in your environment, in your company, you will have a hard time.

I've seen strange situations in major corporations where people really didn't report what they were working on or show the right results. I've seen complete shadow Jira environments - one for internal use and one for external use with customers. There can be huge misalignments because people didn't dare to show real progress. In the long term, it will backfire. If you don't have trust in your environment, in your company, you will have a hard time.

Wrapping up

Hayley Rodd: There are so many key themes coming up throughout our conversation. You've talked about ongoing communication across teams, really planning with purpose, getting that context and buy-in to help with motivation, and allowing for radical candour - being really open if something's not working and being okay to call it out. So many cultural and communication elements are critical to the success of quarterly planning, PI planning, and organisations generally. Great takeaways.

We're going to end it there, but I want to end with a teaser for our interactive webinar that you and I are doing together on September 4th, which dives deeper and shows how to operationalise the ideas we've chatted about here using Easy Agile Programs and linking back to the fundamental services that catworkx provides organisations.

Andreas, it's been super wonderful to chat with you. I look forward to our webinar coming up on September 4th.

Andreas Wengenmayer: Thank you so much for having me. Looking forward to September 4th and seeing you again, talking more about tooling, boats, duck hunt, and anything in between.

Ready to transform your strategic planning?

The conversation doesn't end here. Andreas and Hayley hosted an interactive webinar where they showed how you can put these strategic alignment concepts into practice.

They spoke about:

• Practical techniques for breaking down strategic goals into actionable team objectives
• How to maintain goal visibility throughout your PI cycles
• Real-world examples of successful alignment transformations

Watch the webinar recording here →

"Thoroughly enjoyed my conversation with Jon, he shared some great perspectives on the impact of the Agile manifesto" - Amaar Iftikhar

Amaar Iftikhar, Product Manager at Easy Agile is joined by Jon Kern, Co-author of the Agile Manifesto for Software Development and a senior transformation consultant at Adaptavist.

Amaar and Jon took some time to speak about the Agile Manifesto. Covering everything from the early days, ideation, process, and first reactions, right through to what it means for the world of agile working today.

They touch on the ideal state of an agile team, and what the manifesto means for distributed, hybrid and co-located teams.

We hope you enjoy the episode!

Transcript

Amaar Iftikhar:

Hi everyone. Welcome to the Easy Agile Podcast. My name is Amaar Iftikhar. I'm a product manager here at Easy Agile. And before we begin, Easy Agile would like to acknowledge the traditional custodians of the land from which we broadcast today, the people of the Dharawal speaking country. We pay our respects to elders past, present, and emerging. And extend that same respect to all Aboriginal, Torres Strait Islander, and First Nations peoples joining us today.

Today, we have on the podcast Jon Kern, who is the co-author of the Agile Manifesto for Software Development and an Agile consultant. If you're wondering, you're correct. I did mention the Agile Manifesto for Software Development. The Agile Manifesto. So Jon, welcome for being here and thank you for joining us.

Jon Kern:

Oh, my pleasure, Amaar. Thank you.

Amaar Iftikhar:

Yeah, very excited to have you on. Let's just get started with the absolute basic. Tell the audience about, what is the Agile manifesto?

Jon Kern:

Well, it's something that if you weren't around, and I know you're young, so you weren't around 21 years ago, I guess now, to maybe understand the landscape of what software development process and tooling and what most of us were facing back then, it might seem like a really obvious set of really simple values. Who could think that there's anything wrong with what we put into the manifesto? But back in the day, there were, what I practiced under as a... I'm an aerospace engineer, so I was in defense department work doing things like fighter simulation, F-14 flat spins and working with a centrifuge and cool stuff like that. And subject to a mill standard specification, which makes sense for probably weapons systems, and aircraft manufacturing, and all sorts of other things. But they had one, lo and behold, for software development. And so there was a very large, what I would call heavy handedness around software development process. We call it heavyweight process. Waterfall was the common term back then, and probably still used today.

And there were plenty of, I would say the marketing juggernaut of the day, IBM and Rational unified process, these large, very much like Safe. Where it's a really large body of work, awesome amount of information in it, but very heavy process even though everything would, say you tailor it, it could be whatever you wanted. I mapped my own lightweight process into REP for example. Sure. But the reality was we were facing kind of the marketplace leader being heavyweight process that was just soul crushing, and from my perspective, wasting taxpayers' money. That was kind of my angle was, well, I'm a taxpayer, I'm not going to just do this stupid process for process sake. That has to have some value, has to be pragmatic. So lo and behold, there were a handful of us, 17 that ended up there, but there are a handful of us that practiced more lightweight methods. So the manifesto was really an opportunity for coming together and discovering some of the, what you might think of as the commonality between many different lightweight practices. There was the XP contingent. I first learned about Scrum there, for example. Arie van Bennekum, a good friend, he taught us about DSDM. I don't even remember what it stands for anymore. It was a European thing.

Alistair and Jim Highsmith, they had, I forget, like crystal methodologies. So there was a fair amount of other processes that did not have the marketing arm that erupted, or didn't have the mill standard. So it was really all about what could we find amongst ourselves that was some sort of common theme about all these lightweight processes. So it was all about discovering that, really.

Amaar Iftikhar:

You all get together, the principles kind of come to fruition, and let's fast forward a little bit. What was the initial reaction to the original manifesto?

Jon Kern:

Yeah, it was even kind of funny that the four values, the four bullets is as simple as it was. The principles came a bit later. I want to say we collaborated over awards wiki, but the original... If you go to Agile uprising, you can see I uploaded some artifacts, because apparently I'm a pack rat. And I had the original documents that Alistair probably printed out, because he was the one... He and Jim lived there near Salt Lake City. So it was like, "Hey, let's come here." And we like to go skiing, so let's do it here. So he arranged the room and everything. And so there's some funny artifacts that you can find. And the way that it actually came about was an initial introduction of each of us about our methods. And really I think a key, we left our egos at the door. I mean I was a younger one. Uncle Bob, some of these, he was at Luminar, I know I have magazines still in the barn that he was either the editor of, or authors of for people who don't remember what magazines are. Small little booklets that came out. So Uncle Bob was like, Ooh, wow, this is pretty cool.

And I wasn't shy because I had a lot of experience with heavyweight methods. So I really wanted to weigh in on... Because I had published my own lightweight method a few years earlier. So I had a lot of opinions on how to avoid the challenges of big heavyweight process. So the culmination as we were going out the door and after we had come up with the four values was I think Ward said, "Sir, want me to put this on the web?" And again, this is 2001 so dot com and the web's still kind of new so to speak. And we're all like, yeah, sure, why not? What the hell, can't hurt. We got something, might as well publish it. I don't think to a person, anybody said, "Oh yeah, this is going to set the world on fire because we're so awesome." And we were going to anoint the world with all of this wonderful wisdom. So I don't think anybody was thinking that that much would happen.

Amaar Iftikhar:

Yeah. So what were you thinking at that time? So how would the principles that you had come up with together, was that maybe just for the team to take away? Everyone who was there? What was the plan at that time?

Jon Kern:

I think it was a common practice. Like I said, there were other groups that would often meet and have little consortiums or little gatherings and then publish something. So I think it was just, oh yeah, that's a normal thing to do is you spent some time together and you wrote things down, you might as well publish it. So I think it wasn't any deeper than that other than Bob, I think Bob might say that he wanted to come up with some kind of a manifesto of sorts or some kind of a document because that's I think what those sort of... I was never at one of those gatherings, but you know, you could see that they did publish things. I have a feeling it was just something as innocent as, well we talked, wrote some things down, might as well share it.

And then the principles, there were a lot of different practices in the room. So some of what I would say the beauty of even the values page is the humility at the top is it's still active voice. We are uncovering not, hey all peasants, we figured it all out. No, we're still uncovering it. And the other thing is by doing it, because I'm still an active coder. And plus we value this more on the left, more than on the right. Some people might say it's a little ambiguous or a little fuzzy, but that's also a sign of humility and that it's not A or B. And it really is fuzzy, and you need to understand your context enough to apply these things. So from a defense department contracting point of view, certainly three of the four bullets were really important to me because I learned... Sure, we did defense department contracting. But it's way more important to develop a rapport with the customer than it is... Because by the time you get to the contract you've already lost, which goes along with developing a rapport with the customer, the individual.

And one of Peter Codes, when we worked with customers and whatnot, one of our mantras was frequent tangible working results, AKA working software. You can draw a lot and you can do use cases for nine months, but if you don't have anything running, it's pretty, I would guess risky that you don't have anything, no working software yet. So it really was I think an opportunity to share the fact that some people thought two weeks and other people thought a month. Even some of the print principles had a pretty good wide ranging flexibility so to speak. That I think is really important to note.

Amaar Iftikhar:

Yeah, no, absolutely. And it makes sense. Did you or anyone else in the room at that time ever imagine what the impact downstream would be of the work that was being done there?

Jon Kern:

Not that I'm aware of. I certainly did not. I remember a couple times in my career walking in and seeing some diagrams when I worked with the company Together Soft, and we'd build some cool stuff and I'd see people having some of the... Oh yeah, there's a diagram I remember making on their wall. That's kind of cool. But nothing near how humbling and sort of satisfying it is. Especially I would say when I'm in India or Columbia or Greece, it almost seems maybe they're more willing to be emotional about it. But people are, it's almost like they were freed by this document. And in some sense this is a really, really tiny saying it with the most humility possible. A little bit like the Declaration of Independence, and the fact that a handful of people... And the constitution of the United States. A handful of people met in a moment of time, never to be repeated again and created something that was dropped on the world so to speak, that unleashed, unleashed a tremendous amount of individual freedom and confidence to do things. And I think in a very small, similar fashion, that's what the manifesto did.

Amaar Iftikhar:

As you mentioned, there was a point in time when the manifesto was developed and that was almost over 20 years ago. So now the way of working, and the world of working has drastically changed. So what are your thoughts on that? Do you see another version coming? Do you think there are certain updates that need to be made? Do you think it's kind of a timeless document? I'd love to hear your thoughts on that.

Jon Kern:

Yeah, that's a good question. I personally think it's timeless and I welcome other people to create different documents. And they have. Alistair has The Heart of Agile, Josh Kerievsky's got Modern Agile.

There's a few variations of a theme and different things to reflect upon, which I think is great. Because I do believe, unlike the US Constitution, which built in a mechanism to amend itself, we didn't need that. And I believe it captured the essence of how humans work together to produce something of value. Mostly software, because that's what we came to practice from, is the software experience. But it doesn't take a lot of imagination to replace the word software with product or something like that and still apply much of the values that are there with very, very minor maybe adjustments because frequent tangible working results.

There might have to be models, because you're not going to build a skyscraper and tear it down and say, "Oh, that wasn't quite right," and build it again. But nonetheless, there are variations of how you can show some frequent results. So I think by and large it's timeless. And I would challenge anybody. What's wrong with it? Point out something that's somehow not true 20 years later. And I think that's the genius behind it was we stumbled on... And probably because most of us were object modelers, that's one of the things we're really good at, is distilling the essence of a system into the most critical pieces. That's kind of what modeling is all about. And so I think somehow innately, we got down to the core bits that make up what it is to produce software with people, process and tools. And we wrote it down. That's why I think it's timeless.

Amaar Iftikhar:

Yeah, no absolutely. I think that was a really good explanation about why it's timeless. I think one of the principles that comes to mind in a kind of modern hybrid or flexible working arrangement is one of the principles talks about the importance of face to face conversations. And in a world now where a lot of conversations aren't happening physically face to face, they might be happening on Zoom. Do you think that still applies?

Jon Kern:

Yeah, I think what we're finding out with... Remote was literally remote, so to speak, back 20 years ago. I was working with a team of developers in Russia and we had established enough trust and physical... I would travel there every month. So kind of established enough of a team, and enough trust in the communication that we could do ultimately some asynchronous work because different time zones. And me being in the east coast. 7:00 AM in the US was maybe 3:00 PM in Russia if I recall. St. Petersburg. So we were able to overcome the distance, but it's hard to beat real life. And I would often sometimes even spar a little bit with Ron Jeffries that on the one hand you could say the best that you can do is in person. But on the other hand, I could argue a little bit of some of the remoteness makes things... You have to be a little more verbose, possibly a little more precise, but also a little more verbose. A little more relaxed with... You might take a couple of passes to get something just because, I mean there are two time zones passing in the night. But that was based off of some often initial face to face meetings, and then you could go remote and still be successful and highly effective.

So I think it's important that teams don't just say that they can still do everything. And zoom is way better than 20 years ago, admittedly. Zoom gets, at least you can see a face. But nothing replaces the human contact. And I think also for wellbeing, I think human contact is important. So I would still say that the interaction aspect in the manifesto is still best served with a healthy dose of in-person. And that's kind of the key about most things in Agile. It's to me it's about pragmatism, and not just being dogmatic but rather, what might work better for us? And even experimenting with try something a little bit and see how that works. So even how you treat the manifesto, you should treat it in an Agile manner so to speak.

Amaar Iftikhar:

Yeah, no absolutely. That's a great point. On that note, as an Agile consultant or the Agile guy, what have you seen are the best practices or what works, what doesn't work for distributed teams?

Jon Kern:

Well I think the things that are most challenging that I've run across big companies and even smaller ones is that... I don't know if it's natural, God forbid if it's natural, but tendencies that I've seen in some companies to set up silos where you're the quality control, you're the UX, you're the front end, you're the back end, makes my headwater explode. Because that's building in a lag and building in communication roadblocks and building in cooperation which is handed offs from silo to silo, versus collaboration. So I've seen more of that. And I get it, you might want to have a specialty, but customer doesn't care. Customer wants something out the door. If I showed up and I'm going to pull a feature off the stack, what do you mean I can only do part of it? I don't get that. And yeah, I know I'm not an expert in everything but we probably have an expert that we can figure out what the pattern is. So I find that sort of trend, I don't know if it's a trend, but I find that's a step backwards in my opinion. And it's better to try to be more cross-functional, collaborative, everybody trying to work to get the feature out the door, not just trying to do your little part.

Amaar Iftikhar:

Yeah, a hundred percent. I think knocking on silos is a big part of being agile, or even being digital for that matter. And often the remedies for it too are there at hand, but it's a lot harder to actually be practical with it, to actually implement it in an organization, a living, breathing business where there's real people and there's dynamics to deal with, and there's policies and processes to follow. So I guess as generic as you can be, what is your thought as an Agile consultant to a business that's kind of facing that issue?

Jon Kern:

One of the things that... Adaptive is what my colleague John Turley has really opened my eyes to. I tend to call it the secret sauce, or the missing piece to my practice. And it has to do with individual's mindset and what we call vertical development. So it might sound like weird wishy-washy fluffy stuff, but it's actually super critical. And I've always said people, process, and tools for, I want to say since late nineties probably, I mean a long time. And the first I've been able to realize why sometimes I would have just spectacular super high performing teams and other times it'd be just really, really well performing but not always that spark and sometimes kind of like, eh, that was a little meh. And a lot of it comes down to where people lie on in terms of how they make their meaning and what their motivational orientation is, command and control versus autonomy.

So what we do is we've learned that we can help people first off recognize this exists, and help people with what we call developmental practices. Something that, even the phrase, you probably heard it, like safe experiments. Failure, or trying something and failing. Well if you chop someone's head off for it, guess what? They're just going to probably stay pretty still and only do what they're told, not try to... I have a super high dose of autonomy in me, so I've long lived by the, better to beg forgiveness than ask permission, and always felt as long as I'm trying to do the right thing to succeed and do the best for the company, they probably won't fire me if I make a mistake. But not everybody has that amount of freedom in the way they work. So you have to help establish that as management, and that's a big thing that we work with, with teams.

And then we also start with the class. If you've ever watched office space, and if you haven't you should, but the, what is it that you do here? So there's a great, the consultants Bob and Bob coming in, the efficiency consultants, "So Amaar, what is it that you do here?" But literally that's something, whether we're helping teams build a new product, is okay, what's the purpose? What's the business purpose of this product? What is it that you do here? What do you want to do with this product? What value does it provide? Same thing with anything you're working with as a team. And that's why whether it's software, producing some feature that has an outcome that provides value to the customer, or some product. But the point is if you don't understand that, now it's making, the team is going to have a real hard time being able to make decisions which are helping us move forward.

So if you help everybody understand what it is we're here to do, and then try to get the folks that might reflect all the different silos if you're siloed, but all the different elements. How do we go from an idea to cash, so to speak, or idea to value in the customer's hand? And have a good look at that. Because there are so many things that just sort of... Technical data often creeps into software code bases. And the same thing, we sort of say the organizational debt, the same thing can happen. Your process debt. You can just end up with, all right, we want the development team to go faster, John and company, can you come in and help coach us? We want to go agile. Sure, okay yeah. All right. We roll up our sleeves, we look around and after an initial kind of value stream look, like, wait I'm sorry but there's a little tiny wedge, it's about 15%, that's the development. And then you spent the 85% thinking about it.

Let's pretend we could double the speed of development. Which was initially the... Yeah, we need the developers to code faster or something. That's a classic. And no you don't, you need to stop doing all this bullshit up front that's just crazy ass big waterfall project-y stuff with multiple sign-offs. And matter of fact, one of the sign-offs, oh my gosh it only meets once a week, and then if you have a typo in it, you get rejected. You don't come back for another... Are you insane? You spent eight months deciding to do eight weeks worth of work. Sorry, it's not the eight weeks. So things like that, what I recommend anybody self inspect is try to... If you're worried about your team, how you can do better is just start trying to write down what does your process step look like and what is a typical time frame?

How much time are you putting value into the... Because a lot of times people batch things up in sprints. That's a batch, why are you putting things in a batch? Or they have giant issues. Well that's the big batch. So there's lots of often low hanging fruit. But to your point, it's often encrusted in, this is the way we work and nobody feels the ability to change or even to stop and look to see how are we working. So I think that's where we usually start is let's see how you actually work today. And then while we're doing that you can spill your guts, you can tell us all the things that hurt and that are painful and then we'll try to design a better way that we can move towards, in terms of working more effectively. Because our goal is to help teams be able to develop ways to do more meaningful and joyous work, really. Because it's a lot of fun when it's clicking and when you're on a good team and you're putting smiles on the customers' faces, it's hard to almost stay away from work because it's so much fun. But if it's not that, if it's drudgery and you're just a cog in the machine and stuff takes months to get out the door, it's a job. It's not that much fun.

Amaar Iftikhar:

Yeah. A lot of the points that you mentioned there strongly resonated with me, and the common pain points. It sounds like you've kind of seen it all. And by the way if you haven't seen office space, definitely need to watch it. It's a really good one. You've mentioned now a lot about of the element of the challenges that a distributed team faces. Now I want to flip it over and ask you what does the perfect distributed team look like today that lives and breathes agile values?

Jon Kern:

Yeah. I don't know if you can ever have such a thing, a perfect of any kind of team. So I would say harking back to the types of distributed teams that I've worked with, and this goes back to the late nineties. So I've been doing this for a long, long time. Only really done remote, whether it was with developers in Russia or down in North Carolina, or places like that. And I think that the secret was having a combination of in-person... If you want to go somewhere as a group, there are things you can do to break the ice, to establish some, what you might call team building type activities.

And not just, hey let's go do a high ropes course and be scared out of our wits together. But rather also things that are regarding why are we here, what are we trying to achieve? And let's talk about whether it's the product we're trying to build, and take that as an opportunity to coalesce around something and get enough meat on the bone, enough skeletons of what it might look like. Because there's good ways to start up and have a good foundation. And that's part of what I've been practicing for decades. If you get things set up properly with understanding that just enough requirements, understanding... And I do a lot of domain modeling with UML and things like that, just understanding what the problem domain is that we're trying to solve to achieve the goals we're looking for, have a sense of the architecture that we want. So all those things are collaborative efforts.

And so if you have enough of a starting point where you've worked together, you come in and, let's say you even had to go rent someplace, because nobody lived near office, so you all flew somewhere. I mean that's money well spent in my opinion. Because that starts the foundation. If you've broken bread so to speak, or drank some beers, or coded together and did stuff, and then you go back to your remote offices to take the next steps and then realize when you might need to meet again. So that's really important to understand that the value of establishing those relationships early on so that you can talk bluntly. And I have some good folks that I run a production app for firefighters since like 2006.

Amaar Iftikhar:

Yeah, very cool.

Jon Kern:

And that friend that I've worked with, we are so tight that we can... It makes our conversations, we don't have to beat around the bush, we don't have to worry about offending any, we just, boom, cut to the chase. Because we know we're not calling each other's kids ugly. We're just trying to get something done fast.

And building that kind of rapport takes time and effort and working together. And that's what I think a good successful distributed team, you need to come together every so often and build those relationships and know when you might need to come together again if something is a problem. But that I think is a key to success is it shortens the time. Because you may have heard of things like the group forms, if this is performance on the Y axis they form and they're at some performance level, then they need to storm before they get back to normal, and before they start high performing. So it's this form, storm. You get worse when you're storming. And storming means really understanding where we're at. When we argue about, I don't think that should be inheritance, Amaar. And then you're like, "Oh bull crap, it really..."

And again, we're not personal, but we're learning each other's sort of perspectives and we're learning how to have respectful debates and have some arguments, so to speak, to get to the better place. And I've worked in some companies that are afraid to storm, and it feels like you're never high performing.

Everyone's too polite. It's like, come on. And I love when I worked with my Russian colleagues. They didn't give a crap if I was one of the founders. And I'm glad, because I don't want any privilege, I don't want anything like that. No let's duke it out. May the best ideas win. That's where you want to get to. And if you can't get there because you don't have enough of a relationship, and you tend not to say the things that needed to be said because you're being polite, well it's going to take you really long to succeed. And that's a lot of money, and that's a lot of success, and people might leave.

So I think the important thing is if you're remote, that's okay, but sheer remote is a real challenge. And you have to somehow figure out, if you can't get together to learn how to form and storm, and build those bonds face to face, then you need to figure out how to do it over Zoom. Because you need to do it, because if you don't, if you never have words, then trust me, you're still not high performing.

Amaar Iftikhar:

Yeah, I kind of feel like being fully remote now is being offered as almost a competitive advantage to candidates in the marketplace now, because it's a fight for talent. But if I'm understanding correctly, what you are saying is that in-person element is so important to truly be high performing and those ideas kind of contradict each other, I feel.

Jon Kern:

Yeah. And again, having been remote since the late nineties, I've been doing this a long time. And commuting to Russia is the longest commute I ever did, for three years. I mean that's a hell of a long flight to commute there over seven times, or whatever the hell it was. Anyway, I used to say that that being remote is not for everyone, because it really isn't. I mean you have to know how to work without anybody around, and work. I mean it has its own challenges. And yeah, it might be a perk, but I think what you need to do is look at potentially what the perks are and figure out too, can I fold them into... It doesn't have to be all or nothing. And I think that can be a easy mistake to make maybe is to, all right cool, we don't have to have office space. That's a lot of savings for the company. Yeah, but maybe that means you need to have some remote workspaces for occasional gatherings, or figure it out.

But yeah, I think even... And certain businesses might work differently. In the beginning of building a product, I want to have heavy collaboration and I want to get to a point where it's almost, I feel like the product goes like this where once you get things rolling and you kind of get up, get some momentum going, now the hardest thing to do is be in front of an agile team, whether they're in-person or remote. Once things are rolling and rocking and kicking and it's like everything's clicking, you can just bang out features left, like boom, boom, boom. Yeah, okay then we probably need to be...

Unless we've got ways that we're pairing or things like that. I will say when we're together, mobbing is easier. I'm sure there's ways to do it remote, but being in a room, I don't know, it's a lot easier than coordinating over Zoom. You just, hey there's this problem, let's all hang out here after standup because we're just going to mob on this. So it doesn't take a whole lot versus anything remote, there's a little extra, okay, we've got to coordinate, and even different times zones, gets even worse. So yeah, don't get carried away with remote being the end all be all. Because I have a feeling there's going to be a... I would wager there will be a backlash.

Amaar Iftikhar:

And I'll take that back coming from the Agile, the person who does this day to day who helps teams become agile, I'll definitely kind of take your word for it. Plus with my experience too, I've seen nothing really beats a good white-boarding session. That is really hard to replicate online. I mean we have these amazing tools, but nothing quite mimics the real life experience of just having a plain whiteboard and a marker in your hand. That communication is so powerful.

Jon Kern:

Great point. You're so, right, because I had just with the one company that I was with for five years, we were doing high level engineered to order pump manufacturing sales type tool for... So it was my favorite world because it blended my fluid dynamics as an aerospace engineer, plus my love for building SaaS products, and building new software and things like that. And even having a young, we would interview at Lehigh University and we'd have some young graduates that would be working with us, and being able to bring them into the fold, and there was a room behind where my treadmill was and we'd go in there, we'd have jam sessions on modeling and building out new features. And man, you're right. Just that visceral three dimensional experience. Yeah, Miro's great. Or any other kind of tool, but yeah, it's not the same. You're absolutely right. That's a great point. You're almost making me pine for the good old days. [inaudible 00:42:04]

Amaar Iftikhar:

I think the good old days very much still exist. I think even now, it's kind of been a refreshing time for me to be with Easy Agile. I've only been here for just under two months now. And there's a strong in-person dynamic. And again, it's optional, where if people are remote or they're hybrid or they need to commute once in a while, it's a very understanding environment. But once you're in the office or you're in person, you kind of feel the effect you were describing, you're motivated to deliver for the end customer. You just want to come back. It's an addictive feeling of, I want to be back in person and I want to collaborate in real time in person.

Jon Kern:

That's beautifully said, because that's... One of the companies that we're beginning to engage with in South Africa, they're at this very crossroad of struggling with, everybody's been remote, but boy, the couple times we were together, got so much done. And you're describing the flame of, the warmth of delivering and let the moths come to the flame. I mean nurture it and then fan the flames of the good and let people opt in and enjoy it. And still sometimes, yeah, I got to say home, I got the kids or the dog, that's okay too. But giving the option I think is where we're going to head. And I believe the companies that are able to build that hybrid culture of accepting both, and neither mandating one nor the other, but building such a high performing team that basically encourages people to opt into the things that make the most sense at that time. And I think that those companies will rule the day, so to speak.

Amaar Iftikhar:

Yeah, absolutely. It's been so nice to chat with you John, and I've really enjoyed this. I want to leave the audience off with one piece of advice for distributed agile teams from you. We've talked a lot about the importance of in-person collaboration. We've talked about the principles of the agile manifesto. Now, what would the one piece of advice be when you're thinking of both? When you want the agile manifestos to be something that's living and breathing in distributed agile teams, what one piece of advice can you give businesses today right now who are going through the common struggles? What can you tell them as that last piece of advice?

Jon Kern:

Well, I think kind of a one phrase that I like to use to capture the manifesto is, "Mind the gap." In my sort of play on words, what I mean is the gap in time between taking an action and getting a response. Whether it's what do we do about the office, what do we do about remote, what do we do about this feature, what do we do about this line of code? The gap in time is, it's sort of a metaphor about being humble enough to treat things as a hypothesis. So don't be so damn sure of yourself one way or the other about the office or remote or distributed. But instead, treat things as a hypothesis. Be curious and experiment safely with different ways and see what works. And don't be afraid of change. It's not a life sentence to, you got to run your business or your project or your team one way for the rest of your life. No. Don't tell the boss, but work is subsidized learning. I never understood people who just keep doing the same thing because they weren't given permission. Just try it. So that's what my departing phrase would be regarding making those decisions. Mind the gap and really be humble about making assumptions, and test your hypotheses, and shorten the gap in time between taking actions and seeing a reaction.

Amaar Iftikhar:

Oh, that's awesome. Thank you. I really wish we could let the tape roll and just keep talking about this for a couple more hours, but we'll end it right there on that really good piece of advice that you've left the audience off with. Jon, thank you again for being on the podcast. And we've really, really enjoyed hearing you and learning from your experiences.

Jon Kern:

Oh, my pleasure. Any time. Happy to talk another couple hours, but maybe after some beers.

Amaar Iftikhar:

Yeah.

Jon Kern:

Except it's your morning, my evening. I'm going to have to work on that.

Amaar Iftikhar:

Yeah.

Jon Kern:

My pleasure, Amaar.