Easy Agile Podcast Ep.8 Gerald Cadden Strategic Advisor & SAFe Program Consultant at Scaled Agile Inc.

"Having gone through a cloud migration at Splunk, Greg share's some insightful key learnings, challenges and opportunities" - Chloe Hall

Greg Warner has been involved with the Atlassian ecosystem since 2006 and is a frequent speaker at Atlassian events. Greg has worked as a senior consultant for a solution partner, supported Jira and Confluence at Amazon, and in his current role at Splunk, executed a cloud migration to Atlassian Enterprise Cloud for over 10,000 of his colleagues.

In this episode, Greg and Chloe discuss the cloud migration journey:

📌 The mental shift to cloud migration and how to think beyond the technical side

📌 How to navigate the journey without a roadmap to follow

📌 The four pillars to success for your cloud migration journey

📌 Finding the right time to migrate & thinking about future opportunities    beyond your migration

📌 The unexpected value that can come from a cloud migration

+ more!

📲 Subscribe/Listen on your favourite podcasting app.

Thanks, Greg and Chloe!

Transcript

Chloe Hall:

Hey everyone and welcome back to the Easy Agile Podcast. So I'm Chloe, Marketing Coordinator at Easy Agile, and I'll be your host for today's episode. So before we begin, we'd like to acknowledge the traditional custodians of the land from which I am recording today, the Wodiwodi people of the Dharawal-speaking nation and pay our respects to elders past, present, and emerging. We extend that same respect to all Aboriginal and to Australia Islander peoples who are tuning in today.

Chloe Hall:

So we have a very exciting guest on the podcast today. This guest has been involved with the Atlassian ecosystem since 2006 and is a frequent speaker at Atlassian events. He has worked as a senior consultant for a solution partner, supported Jira and Confluence at Amazon and at his current role at Splunk, executed a cloud migration to Atlassian Enterprise Cloud for over 10,000 colleagues. So welcome to the Easy Agile podcast, Greg Warner.

Chloe Hall:

How are you?

Greg Warner:

Good, and thank you for having me.

Chloe Hall:

No worries. It's great to have you here today.

Greg Warner:

This is one of my favorite topics. We talk about cloud migration and yeah, I hope I can explain why.

Chloe Hall:

Yes, that's exactly what we want for you because I remember when we met at Team 22, you were just so passionate about cloud migration and had so many insights to share and I was very intrigued as well.

Greg Warner:

To give it a bit background about myself.

Chloe Hall:

Yeah.

Greg Warner:

I haven't always been a cloud person. So you mentioned before about being involved since 2006. I was involved early days with when Jira had the several different flavors of standard and professional, when you'd order an enterprise license for Atlassian and they'd send you a shirt. That was one of the difference between one of the licenses. So based a lot in the server versions, over many years. I looked at the cloud as being the poorer cousin, if you like.

Greg Warner:

I'd been to several Atlassian summits and later Team events where there was always things of what was happening in cloud but not necessarily server. I participated in writing exam questions for Atlassian certification program for both server and DC. For me, in the last 18 months, two years now, to make this fundamental shift from being certainly a proponent of what we do doing on server in DC to now absolutely cloud first and that is the definite direction that we as a company have chosen and certainly why I'm so passionate about speaking to other enterprise customers about their cloud migration journey.

Chloe Hall:

Wow. So what do you think it was that you were like, okay, let's migrate to the cloud, as you were so involved in the server DC part of it? What was it that grabbed your attention?

Greg Warner:

I joined Splunk in 2019 and it wasn't all roses in regards to how we maintained Jira and Confluence. It wasn't uncommon to have outages that would last hours. For two systems that were just so critical to our business operations to have that, I was kind of dumbfounded but I thought, hey, I've been here before. I have seen this. And so it was a slow methodical approach to root cause our problems, get us to a version that was in long-term support, and then take a breather.

Greg Warner:

Once we got to that point where we didn't have outages, we kind of think of what the future would be. And for me, that future was exactly what I'd done before, what I'd done at Amazon, which is where we would move all of our on-prem infrastructure, Jira, Confluence, and Crowd to public cloud, whether it would be a AWS or GCP, something of that flavor. I'd done that before. I knew how we were going to do that to the extent that I'd even held meetings in my team about how we were going to stand up the infrastructure, what the design was going to be.

Greg Warner:

But there was probably one pivotal conversation that was with our CIO and it was in one of those, just passing by, and he's like, "Greg, I've seen the plans and the funding requests." He's like, "But have you considered Atlassian Cloud?" Now, the immediate personal reaction to me was like, we are not going to do that because I'd seen the iterations. I'd seen it over time. I'd worked for a solution partner. I'd worked with customers in cloud, never really thought we could be enterprise-ready. So my immediate reaction was not going to do that. I said, "I'm not going to answer that question right now." I said, "I don't know enough to give you an answer."

Greg Warner:

And I'm absolutely glad I did that because I would've put a foot in mu mouth had I given the immediate response that was... So yeah, I took that question, went and did some analysis, spoke to our technical account manager at the time, and really looked at what had been going on and where was cloud today? Where was it in its maturity? And the actual monumental thing for me was that I think it's actually ready. People make excuses for why they can't do it, but there are a bunch of reasons why you should. And if we look at us as a company, with our own products that we are moving our own customers to cloud, and we are using cloud services, like Google Workspace and Zoom and a variety of SaaS applications. What was so different about what we did in engineering that couldn't go to cloud? And that was like, okay, I think the CIO was actually asking me a much bigger question here.

Greg Warner:

So the result of that was yes, we decided that it was the right time for Splunk to move. And that is a monumental shift. And I know there's a lot of Jira admins out there that are like, if you do this, you're putting your own jobs at risk. The answer is no, you're not. And even within my team, when we had we'd discussed this, there was emotional connection to maintaining on-premise infrastructure and were we giving our own jobs away if we do this? There's all those... No.

Greg Warner:

And there have actually been two people in my team that got actually promoted through the work of our cloud migration that otherwise wouldn't have because they could demonstrate the skills. But that's kind of like the backstory about how we decided to go to cloud. And I think as we are thinking about it, there is a mental shift first. Before you even go down the technical path about how you would do it, change your own mind so that it's open so that you're ready for it as well.

Chloe Hall:

Yeah, I love that. It's so good. And I think just the fact that you didn't respond to your CIO, did you say that?

Greg Warner:

Yep.

Chloe Hall:

That you didn't respond to your CIO straight away and you weren't like, "No, I don't want to do that." You actually stepped away, took that time to do your research, and think maybe cloud is the better option for Splunk, which is just so great and really created that mental shift in yourself. So when you say that your employees, like everyone kind of has that beef that, oh, we're going to lose our job if we move from on-prem to cloud and those employees ended up getting promoted. How did their roles change?

Greg Warner:

When we moved from on-prem to cloud, you no longer have to maintain the plumbing, right?

Chloe Hall:

Yeah.

Greg Warner:

You no longer have to maintain all the plumbing that's supporting Jira, Confluence, BitBucket, whatever is going to move. Now we thought that was the piece that's actually providing value to the organization. And it wasn't until we went to cloud, we actually realized it wasn't. Like what we can do now is different. And that's what my team has done. They've up-leveled.

Greg Warner:

So in the times since we moved from Jira, Confluence on-prem to cloud, we now get involved a lot more with the business analysis and understanding what our project teams want. So when someone from engineering is requesting something that has an integration or a workflow, we've got more time to spend on that than are we going to upgrade? Are we on the current feature release? Is there a bug we have to close? Log for J as a prime example where the extent of where we covered was logging a call with the Atlassian enterprise support and then telling us, "Yep, it's done."

Greg Warner:

Whereas other colleagues within the ecosystem that I spoke to spent a week dealing with that, right? Dealing with patching and upgrades. So the value for our team in the work we do has shifted up. We've also done Jira advanced roadmaps in that time. So we've been able to provide things we would've never got to because we're too busy to the plumbing, to the extent now that we have a very small footprint of on-prem that remains and that's primarily FedRAMP and IO5. It's not quite certified yet. It's going to get there. So we have a very small footprint and I'm the one who has to do the upgrades and now you look at it like, oh my god, that's going to be this couple-week tasks we going to do where I could do all this other better work that's waiting for us in cloud. You don't realize it until you have it removed how much you used to do.

Greg Warner:

And so we used to do two upgrades of Jira year and two upgrades of Confluence a year. We put that down to about a month's work of each. By the time you do all of your testing and you're staging and then do that. So you're really looking at four months of the year you were spending doing upgrades. We don't have that anymore. It's completely gone. And so now we make sure that we do things cloud first. We don't bring across behaviors that we were doing on-prem into cloud. So that's probably one thing we learned was that don't implement server DC in cloud.

Chloe Hall:

Yeah, that's so great. It seems like it's opened up a lot more opportunity for you as well. So I think something that I kind of want to look into and understand a bit more is that people focus a lot on the technical aspect of the cloud migration. What other aspects do you think need to be considered?

Greg Warner:

Certainly people. I mentioned at the very front here the mental mindset and that really started with my team, to get their mind around how we're going to do this cloud migration. There isn't necessarily yet a roadmap that says these are all the steps need to take to get ready for your cloud migration. So we had to invent some of those and one of those two was, what did we want to get out of the cloud migration?

Greg Warner:

I speak to other Atlassian customers. You talk about they're running a project, the project is the cloud migration, the start and the end is the cloud migration day. No, completely wrong. The cloud migration actually has a beginning, a middle, and an end. What you're talking about here, about this first changes is in the beginning, and that should be we're moving to cloud because it should be fundamentally better than what we have today.

Greg Warner:

If it's not better, there's no value in doing the activity. So we started with a vision and that vision was that all of the core things had to work from day one and they had to work better. So create issue, edit issue, up to issue, that just needs to work. There should be no argument whether it does or does not. That needs to work and work better. Create a page, edit a page, share a page. That stuff needs to work in Confluence without any problems. We also need to make sure that there are people in the organization who this could be a fundamental change of how they work, depending on how much they work with Jira and Confluence. So appreciating that there is some change management and some communications that needs to be ready as you do your cloud migration to ensure that your vision is going to work, but also acknowledging you will break some things. You're not going to be able to do a cloud migration and shift you from A to B without nothing.

Greg Warner:

It will go wrong. So we were aware of that and for that, what I would always tell people was that we're really fixed on the vision of making it sure it's better than it was today, but flexible on the details, how we get there. We will probably find different ways as we go along because things will change. Cloud changes itself. You'll discover things you didn't know before. There was a Jira admin that made a decision 10 years ago, you now found that. So yeah, very, very fixed on that vision that day one that we had to have this unboxing experience that when people got to use Jira and Conference Cloud for the first time, they could see why we'd spent so much effort to make sure it was polished and things just worked. And as you went a bit further out, there might be things to do with apps that might not be quite the same.

Greg Warner:

That's okay. And then further out, things you just ultimately can't control. And for that, we had 76 integrations of teams that had written automations from all over the company. We're never going to get to find out what they do, but we knew that some of those would probably break. And so just dealing with some change control and allowing those people to know this is coming, what the rest endpoints will be, how to set up their API keys. We did a lot of that, but we did have one integration that broke and that integration broke because the entire team was on PTO or leave that week. We can't avoid that one. But it was good to see other teams actually jumped in because they'd been involved in updating theirs to go help fix that. So that was okay. We had one integration that we really gave the white glove support to and that was for... We have a Salesforce to Jira integration that's a revenue-generating integration.

Greg Warner:

We gave that a lot of attention to make sure that just worked. But the 76 others, we provided a runbook. The runbook was essentially teams, you do things like this. So they knew how to change and update to the new system. But yeah, certainly the beginning, middle and end. The beginning is all those shifts that you're going to have to change and probably some history about design decisions. The middle is in fact your cloud migration and the end, middle to the end is everything you do with it afterwards. So that's where the real value comes from in your cloud migration. It's once you're in, what can we do with it?

Greg Warner:

And we are towards the end of that now. There have been things that I couldn't have planned for that people have done. So we did your advanced roadmaps, saving the forest there, but also we're encouraging our staff to extend the platform. That used to be really difficult and we've worked with Atlassian to understand what should that look like? And we've settled on using it Atlassian Forge. And so now we have our first app this week, in UAT, in Atlassian Cloud to solve business problems that we have. That's a custom Atlassian Forge app. And we're encouraging our engineers to build those and so they can extend and get that real value through the cloud migration.

Chloe Hall:

Yeah, wow. You've come so far and it's nice to hear that you're towards the end of it and all the opportunities are coming with it and you're seeing all the value. It's all paying off as well. I think I just want to go back to that moment where you talk about there isn't essentially a roadmap outlay. There isn't someone or something to follow where it says this is where you need to start. These are the steps to cloud migration. And I think a lot of people, that's what they fear. They're like, we're not sure exactly where to start. We're not sure what roadmap we'll follow. How do you navigate that in a way?

Greg Warner:

So I get back to that when I talked about the vision. We said we're fixing the vision flexible details. Early on when we signed for cloud migration, it was in the first week after we'd signed for it, that same CIO asked me, "Greg, what's our date? When are we moving? Because you've sold me that this is so much better. Where's the action? When are we get this?" And we took a good six weeks after we signed to actually understand the tooling that's available. So for Jira, there's really two options. There's the Jira site import and the Jira cloud migration assistant. And on Confluence side, there's one that's called the Confluence cloud migration assistant. Better kind of understand how those technologies work. And for a couple weeks there, my team actually considered if we did the migration ourself, we could probably save the company a bunch of money and we would own it.

Greg Warner:

We would know how this thing worked. We got about four weeks in and decided that was a terrible idea. Do not do that. Any enterprise customers I talk about that say we're going to do it ourselves, do not do that. Do not do that. And part of the reason is that there's really four pillars to success for your cloud migration. Jira migration, Confluence migration, apps, and users. And we did not know how to do apps and users and we probably could have gotten away with Confluence and Jira. But we said, look, this is something that we actually need to have a partner involved. And so we did ask for partners to provide their way of doing it, knowing what they knew about us. And we did provide as much detail as we can. We had two partners actually provided completely different methodologies how to get there.

Greg Warner:

So this is that flexible on the details, but we really had to make a decision on what worked for us. So when it really came down to Jira, would we do a big bang approach and just switch it over in the course of a weekend or did we want to do cohort by cohort over time? And we decided for us, because we are a 24/7 organization that's supporting our customers, doing the big bang switchover, that was the best way to do it. So that's one of the reasons we chose the partner we did. But that partner didn't necessarily have a roadmap of where they want to go. But we did then explain what we want to get out of this. That was the first thing, was about it needs to happen on a weekend. So that then filters down what your choices are. The ecosystem apps part is really important to make sure that one, there may have been apps installed in your system that have been there for 10 years and you're not sure why they're there anymore because it was four Jira admins ago.

Greg Warner:

Nobody knows what's there. But if they don't have a cloud migration pathway, you really should consider they're probably going to hit their end because there is no equivalent. So you can rule them out. Identify the ones that do have a business process with them. And for that, Salesforce for us, we had to find a cloud-first connect that would work. So that meant that we knew that was going forward. But really, I think the key thing that we invented that we didn't know about was that we created this thing called an App Burn Down. And that's where we looked at all the apps we had. We had about 40 apps. We said, okay, which ones are not going to go to cloud? Which ones don't have a migration pathway? Which ones are going to replace something else? And so we started to remove apps over the course of about three months.

Greg Warner:

So people would see that we're starting to get away from on-prem design decisions and old ways of doing things. But we also said, but once we get to cloud, this is the pathway out of it. So that we said, look, we're going to turn this app off but you're going to get this one instead, which is the cloud-first app. So people could see how we're going to make the jump over the river to get there. But it meant that we would, over time, identify apps that weren't used. If we turned them off and nothing happened, it's fine. But also we did come across some where they were critical to a business use. And so if we didn't have an answer for those yet, it gave us time to find one. And with your user base, typically it's your colleagues, that's going to be your most critical customers. They're going to ask, okay, you're turning it off. When do I get the functionality back?

Greg Warner:

And by doing that App Burn Down over time, that does buy you time to then have that answer. So it's a much easier conversation than I'm simply turning off functionality, I don't have an answer for you yet. There are things like that. It wasn't necessarily a roadmap, but working with a solution partner is absolutely the right way to go. Don't try and do it yourself. They also work with Atlassian and they have far better reach into getting some of these answers than you can possibly ever have. And I have on at least three different occasions where our solution partner did go and speak directly with an ecosystem partner to find out what's the path forward. How can we make this work? So it is good. The migration is really a three-way collaboration between yourself, your solution partner, and Atlassian. And you all have the same goals. You want to get to cloud and it does work really well.

Chloe Hall:

Wow. Yeah. So sounds like hope everyone got that advice. Definitely don't take this on your own. Reach out to solution partner. And I really like how you said you went to two different solution partners and you found out what their ideas were, which ways they wanted to take you, so you could kind of explore your options, work out what was the best route for Splunk. And it's worked very well for you as well. Having that support I think as well. Yeah. Sorry, you go.

Greg Warner:

The choice of the partner is really important and it's probably one of the earliest decisions that we made to get that one right. And I remember several times thinking about, have we got the right people on board? Did we speak to... And it was an interview process to the extent that when we had our final day after we'd been working with Atlassian and with our partner for six months, one month after our migration was completed and we're all done, we had one final Zoom call with all of us and took a photo and did that. But it kind of felt like a breakup, to be honest, because we'd been in each other's faces for six months and working. We're now all saying goodbye. We might not see each other. It was like the weirdest feeling. But it did work. And so yeah, it is a real fundamental choice.

Greg Warner:

Just take the time, make sure they understand what we want to do, make sure you understand how they're going to do it. But yeah, if we have done it ourselves, we would've got ourselves all caught up in knots, wouldn't have been a successful migration or so. I'm a technical guy. I want to solve it. I want to be like... But I think the actual right answer was no, you don't need to know how this works 100% because you're going to do this hopefully just once. And so focus on the real business value things about dealing with stakeholders and the change and making design decisions that are really important for you because you're going to own those probably the next decade rather than worrying about how do I get my data from A to Z?

Chloe Hall:

Yeah. It definitely would've felt like a breakup for you because you would've been working side by side for so long, dealing with so much. Are you still in contact with them or...

Greg Warner:

Yeah, we had this fundamental thing we always said is we're always, if there's a problem, we're always cautiously optimistic, we're going to solve it. We did engineering challenges that we went through, but I did say right early on is, the ecosystem is only big and we're all going to bump into each other at some point. So yeah, let's make sure that we're still friends at the end of this. And I didn't realize how important that was until later when I was in New York for Christmas and I arranged to meet the project manager that worked for us. She lives in New York, so how about I meet you so... So we met each other at the hotel and she's like, "I have never met a customer outside of work to do this." Yeah, I gave the story about it felt like a breakup, but she did say that at the beginning you said we'll be friends after.

Greg Warner:

Yeah it is because it can be really hard. I've been on the consultant side where you kind of have to have some hard conversations and sometimes... You want to make sure that everyone understands the problem. You're trying to make it better so that at the end of it, you can still be friends like that. That is the thing. There probably will be engagements later on that you might need them again. So you want to make sure that you have your choice of best in breed partner to choose from. You have those relationships. They understand what you want to choose. So yeah, it is really important to choose the right partner. Don't necessarily based on price but choose the partner that's going to work for you, understands what you're trying to get out of your cloud migration and they'll be there in the future when you need them for another cloud migration or a much more gnarly project. Try and be friends at the end of it.

Chloe Hall:

And definitely it's good that you have that friendship now because they have that understanding about your business and what you want and the value of it. So if you do need help again, it's a lot easier to bring them on board straight away. So now that you've performed a cloud migration and you're coming towards the end of it, do you look at the process any differently to when you were at the very beginning?

Greg Warner:

Yeah, I thought we were just executing a data migration just yeah, on-prem to cloud.

Chloe Hall:

Yeah.

Greg Warner:

Pretty straightforward, nothing big. I was pleasantly surprised as we're making some of these decisions as we went along, that it was more than that. There were business processes that we could improve. There was the beginning, the middle, and end. I didn't realize that until actually after the end. So when we did our cloud migration, it was actually the week before Thanksgiving in the US. It was November 19. And even that decision was made in just going for a walk at lunchtime. When should we really do this? And I kind of came down again, spoke to my project manager and said, "How about we do this in the cloud migration the week before Thanksgiving?" Because 50% of our workforce is located in the US and a large proportion of that will be on leave or PTO before.

Greg Warner:

So by doing it over a weekend before then we're ensuring that... Like when you open a new restaurant. You don't want to have all of your tables full on the first night. We knew that we were going to have everybody using Jira and Confluence day one after a migration because we're going to break some stuff. They actually turned out to be really exceptionally good idea. And I encouraged people to find... Look at your data and work out when is low time to do this? I've been involved in Jira and Confluence for a long time and just thought it's task tracker and it's a wiki. There's nothing there that I don't really know about. But one of the decisions we made was actually that when we completed the data migration and it was ready to go, I always said if we waited, do we get a better result? And the answer was no.

Greg Warner:

We should make this available to people now. And so we opened it up on a Sunday morning in the US, which was starting to be business hours in Australia. We started making teams aware that they can now go ahead and use Jira and Confluence. And it was the feedback that we immediately got from those teams that were starting to use Jira service management in cloud for the first time, about, "Wow, this is so much better than it was on-prem." And people said, "I can actually see the attention to detail you've made on fields and descriptions and the changes you've made." And it started to impact people's workday that this was better than it was. I didn't expect that to come back. And so I have a montage that we share with the team of all these Slack messages from people saying, "This is really good. This is much better than we had before."

Greg Warner:

What I didn't also realize is that when we moved from on-prem to cloud is the data that we had became more usable and accessible. Hadn't planned that. It seems obvious now, but when we put it in cloud and it has all the security controls around it and now no longer has the requirements of things like VPN to get access to it, people could build new things to use it to be able to interact with your issues, to interact with pages. And so we started with 76 integrations and over space of three months now we had this big jump in the first three months up to about a hundred something and now we're going to Forge And what it means is people who have had this need to be able to get to the data can now get to it. I didn't see that coming. I just thought we were just server cloud. But yeah, having a more accessible has led to improvements in the way that our teams are working but also how they use it in other applications that just simply wasn't available before.

Chloe Hall:

Yeah. Wow. That's great. And it's good that you were able to receive that feedback straight away from the teams that you had in Australia. I think that's really good and it sounds like it's created such a good opportunity for you at Splunk as well now that you're on cloud.

Greg Warner:

Yeah, it's certainly a business leader that can propel you forward and I eagerly come in now and look at what are other teams going to do with it. And so when we had the first team that said they want to build a Forge app, I'm like, Sure. We should not discourage that at all. Extend the platform. That's why we spent the money and time to do it. What can you do with it now? And we did certainly make Atlassian aware on the product side, like how we're using it and where we'd like to see improvements. If you look at the server DC comparison, I used to be that person that would look at the new features in cloud and ask that question about, when is that new feature coming to on-prem? To going to being that customer who's now, I have that feature today, right? And I'm using it because we don't wait for it.

Greg Warner:

So you mentioned about things you didn't plan from the roadmap. There are design decisions that I talk to enterprise customers that I need to make aware of about. One of them is to do with release tracks. In enterprise cloud, you can choose to bunch up the change to cloud and then they get released periodically every two weeks, every month. When I looked at that, came back to one of our principles about don't implement server in cloud, why would we do that? Atlassian has far more data points on whether this works for customers at scale than we do. So why would we hold back functionality? So as a result we don't do release tracks. We let all of the new functionality get delivered to us as Atlassian sees fit. And the result of that is our own engineering staff, our own support staff who use Jira, get the notifications about new products and features and this is fantastic.

Greg Warner:

Again, why would we implement server, which is where you would bunch up all your changes and then go forward? The other thing too about our cloud migration journey is don't be blinked that you're just doing a cloud migration today and then the project ends. There are things you need to be thinking about as you go along, but what's the impact in the future? So for us, we have multiple sites. Enterprise customer have multiple sites. So there are design decisions that we've made so that we can, in the future, do cloud to cloud migration. You will move sites. Your organization could be bought or could be buying companies. So you do mergers and acquisitions. And so as part of that, we have some runbooks now that talk about using the cloud-to-cloud tooling so we can move a Jira project from a site here to a site there, how we'd move users here and users there.

Greg Warner:

And that actually came about through the assistance with our TAM, not focusing just always on the cloud migration date but also what's that look like six months later? What's it look 12 months later? So that you don't perform your cloud migration and then lock yourself in a corner that later on now I have to unwind something. I had the opportunity to fix it. So yeah, I do encourage migration customers to also think six months, 12 months beyond their cloud migration. But what could also happen and then speak to your solution partner about design decisions today that could affect you in the future.

Chloe Hall:

Yeah. So you definitely need to be thinking future-focus when you're doing this cloud migration. I know you've addressed a lot of the opportunities that came out of the cloud migration. Was there anything else that was an unexpected value that came from it that you wanted to share?

Greg Warner:

The other value is make it more accessible. We have seen people use it in different places that we hadn't thought about. So some of the things that we were doing before, we had to have a company-owned asset to get on the VPN and just things like that. That actually restricted people in where they could do work. Whereas now we've, as long as you've got a computer or mobile device connected to the Internet, absolutely you can use a mobile device support, you can get access to it. Approvals that used to be done on a computer are now done on a mobile device. Those things. But I think the integrations has been probably been the one thing I'm most... We're not the catalyst. We kind of pushed it along but seeing people get real use out of it and using the data for other purposes. We have seen people build some microservices that use the data from Jira that we couldn't do before. Again, you're just unlocking that potential by making it more usable and accessible.

Chloe Hall:

After going through the whole migration journey and, like you said, you're coming towards the end of it, what were the things that stood out to you that you're like, okay, they didn't go so well? Maybe if I was to do this again, how would I do this better next time?

Greg Warner:

So I get back to that day one unboxing experience. You know you want to give it that best experience. And we delivered that for people in Australia and APAC as we opened it and they got to use Jira for the first time and it worked fine. And that is mainly the result of a lot of emphasis on the Jira piece because we said, we know this is going to be hard. It's got workflows, issue schemes, notifications schemes. This is going to be hard.

Greg Warner:

So we started that one really early and then probably about 60% down through our migration journey, we started on Confluence. We thought how hard can Confluence be. It's a bunch of spaces and pages. It can't be that hard. We actually hit some migration challenges with the engineering tooling with Confluence, which meant that the Confluence UAT was delayed. The Jira UAT was fantastic. Ran for a month. We found some problems, got fixed, got answers. We were really confident that was going to be fine.

Greg Warner:

And then we hit this Confluence piece. We're like, wow, this is going to be a challenge. And there was at least one time I could think of. It was a Saturday morning at breakfast where our solution partner sent me a Slack message about, I think we've got a problem here with some tooling. What are we going to do? Towards the middle of the day, I was kind of scratching my head. This could be a real blocker. We actually worked with Atlassian, came up with the engineering solution, cleared that out. That was good to see, like in the space of 12 to 24 hours, there was a solution. But what it meant was that it delayed the Confluence UAT and it made a week. And there was something we found to do with the new Confluence editor and third-party apps right at the end of that week. And we had to really negotiate with our stakeholders to make this go ahead.

Greg Warner:

Because again, if we'd waited, we'd get a better result. No, we really should go. We know that there's this problem. It's not system-wide but it affects a small group people. So we did it. But for about a hundred people they have this really bad Confluence experience because of this thing. And so for me, I couldn't deliver on that thing I promised, which was a day one experience that was going to be better than what it had before.

Greg Warner:

Now we did work with Atlassian and app vendors to get some mitigation so it wasn't as bad on day five. It wasn't day one but it wasn't perfect. But I would certainly encourage people to make sure that you do treat Jira and Confluence with as much importance as each other. They do go together. When I did our cloud migration, we did it on a weekend and I remember coming back after dropping my kids at school on Tuesday and sitting in the car park. I was like, wow, we actually pulled that off.

Greg Warner:

If we'd propose to the company to move your company email system and your finance system on a weekend, the answer would be no because it's too big a hat. But what we'd said is we're going to move all of our Atlassian stack in a weekend, which really is two big systems, Jira and Confluence. So if I had the time again, we would've started Confluence much, much earlier and then we wouldn't have the need to rush it at the end. And that really did result in a bad day one experience for those people. We have worked with Atlassian since then. We're getting that resolved. We know other Atlassian guys have the same problem. I would start early and don't underestimate the complexity that could happen. There will be some things outside of your control.

Greg Warner:

I talk about this Confluence problem and the migration tooling, which is actually do at scale. Not every customer will see it. We saw it, I conducted customer interviews when we were doing our solution partner decision and the customer actually told me this. Like I should have started Confluence because we had this problem, we wasted some time, and we did it. I even have my notes. But it wasn't until later, same problem, you even had the answer and they told you and you still waited. So I'm spending a few minutes on this podcast talking about it because it happened to me. It's probably going to happen to the next person. So if I could do one thing and that is just encourage you to start it earlier. You're going to end up with a much, much better migration and hopefully can deliver on that day one experience that I couldn't do.

Chloe Hall:

Yeah, no I'm so glad that you've shared that with the Easy Agile audience as well because now they know and hopefully the same mistake won't keep getting repeated. Well, Greg, my final question for you today, and I don't know if you want that to be your answer, but I think it's really good just for the audience, if there's one key takeaway that they can go away with them today from the podcast, what would be that one piece of advice for everyone listening to start their migration journey?

Greg Warner:

The first thing to do is to prioritize it. So if you're an Atlassian customer that's using on-prem Jira or Confluence and you don't have a timeline and you don't have a priority to your cloud migration, start there. Open up the task, which is start to investigate Atlassian Cloud and choose a date. Because yeah, there will come a situation down the track where you might be asked by your CIO and so it's better to have an answer prepared already. I would encourage people to start to look at it because it is the future. If you look across the industry, people are moving to SaaS. It's really a question. Do you want to maintain and be that customer wondering when that feature's coming to cloud or do you want to be that customer in cloud who has it today? We have seen a monumental shift to when we moved to cloud in functionality, availability, all the good things that cloud delivers. And it's one of the biggest promoter... The person that used to write exam questions for servers now saying go to cloud.

Greg Warner:

Absolutely. So when I've spoken to other enterprise customers, particularly at Team, I said like, when do you plan your cloud migration? I was like, wow, we're going to start it in three years. I'm like, three years? You need to go back to the office next week and start like 12 months because yeah you will... There is absolutely a competitive advantage to doing it. And it's not just me being now as biggest cloud opponents. We see it, we see it every day and for me, this is one of the most influential projects I've been involved in with Atlassian since 2006. This one here is going to have a long-lasting effect at Splunk for a long time and I'm happy to speak to yourself at Easy Agile and others about it and here at their cloud journey because I want to go to Team next year. I want to make sure we have these conversations in the whole way about, I got that one thing. It's either I started my Confluence migration earlier or I actually put in a timeline of when we should start our cloud migrations.

Chloe Hall:

Yeah, beautiful. That is some great advice to take away, Greg. And so honestly, thank you so much for coming on the podcast today. You have provided some brilliant insights, takeaways, and also because there is no roadmap, I feel like your guidance is so good for those who are looking to start their cloud migration. Yeah. We really appreciate you sharing your knowledge.

Greg Warner:

All right. Thanks for having me on. Thank you for listening.

Chloe Hall:

No worries.

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

‍

"I loved having the space to talk about common interests - all things technical documentation & information architecture" - Henri Seymour

On this episode of The Easy Agile Podcast, tune in to hear Henri Seymour - Developer at Easy Agile speak with Matt Reiner - Customer Advocate at K15t.

Henri & Matt are talking all things technical documentation (we promise this episode is way more interesting than it sounds! 😉)

✏️ Considering technical documentation as a product
✏️ The value of well written documentation
✏️ Why you should be digitally decluttering often
✏️ Information architecture

So many golden nuggets in this episode!

Be sure to subscribe, enjoy the episode 🎧

Transcript

Henri Seymour:

Hi, everyone. This is the Easy Agile Podcast. We've got an episode today with Matt Reiner. I'm your host for today, Henri Seymour, developer at Easy Agile. And just before we start the podcast, I'd like to acknowledge the traditional Australians of the land on which I'm recording today, the Watiwati people of the Dharawal nation. Pay respect to elders past, present, and emerging, and extend that respect to any Aboriginal or Torres Strait Islander people listening to this episode.

Matt is an experienced content strategist with a history of working in the computer software industry, skilled in agile scrum framework, related tools, communication, technical writing, video production, customer interaction, strategic planning. And he's here today to talk with us about writing and specifically technical writing and documentation. Hi, Matt.

Matt Reiner:

Hi. It's great to be here. Yeah, I'm Matt. I'm into all sorts of content things. And one of those is technical writing, which is, I think more interesting than it sounds. I guess you'll have to decide by the end of the podcast, if you think so.

Henri Seymour:

Technical documentation experts. So when you talk about technical documentation specifically, what do you mean by that?

Matt Reiner:

Well, I feel like that term is actually in the middle of a big change right now. In the past, technical documentation was very strictly like, "Okay, we're a team, we're making a thing, a product." Maybe it's an app, maybe it's, I don't know, a go-kart and we need to have a user manual for that. Technical documentation was someone sitting down and writing down, "Okay, here are all the knobs and switches and here's what they do. Here are all the features. Here's maybe why you would use them."

So putting together that user guide, which traditionally was printed material that you would get with the product. But it's become a lot more over time, partially with the internet, because we can just constantly iterate on content like many of us do with the products that our teams make. And then also we are seeing it in new forms. Maybe it's not a printed piece, in fact, most people do not want printed technical documentation anymore, they want it online. Or even better, they want it right in context in your app when they're using it, they can just get the info they need, and then get on with it.

That's what technical documentation is. It's supposed to be there to help you do the thing that you really care about and then get out of the way so that you can do it.

Henri Seymour:

Do you have a description of why good technical documentation? Not just having it, but having it at a good quality in a way that really helps your users, is so important to product users.

Matt Reiner:

Well, I suppose we all find those points in our day or in our journey that we find ourselves in where we want to accomplish something, but we don't know how to do it. So a lot of us have really gotten very used to jumping on Google and saying, "Okay, here's this thing I want to do, how do I do it?" And good technical documentation is there with the answer you need, the explanation you need. Because really ultimately all of us are smart people who should be empowered to do the thing we're passionate about.

And technical writers and communicators who are really all members of our team. People who sit down to create good technical documentation uses few words as possible to get a person on the way they're going. And that's like, when it happens its just like, "Glorious," not to the user. They don't even know that it happened, they didn't even know that they read your writing. But to the writer, it's like, "Yeah, I did it, I did it. They don't even care what I did, but I did it." And now they're doing the thing that really matters.

Henri Seymour:

That's great understanding one of the major differences of like, I've written something and I don't want my user to be spending time on it. I want as little time spent reading this as possible.

Matt Reiner:

Yeah, yeah, yeah. You can have great pride in your work, but one of those metrics that a lot of people look at for websites is time spent on page. So sometimes you can fool yourself into thinking, "Oh wow, they spent 10 minutes on my page. That means my documentation's really good." But also that might mean that it's not very good and they're having to reread it over and over again. So the true metric is, did they get to the thing they really cared about? And unfortunately, it's hard to measure.

Henri Seymour:

You mentioned now that with the advent of the internet and giving you the opportunity to iterate on those docs in a way that you wouldn't be able to with printed documentation. That iterative thing brings the agile process of iterate on something that you already put out and improve it in the same way that as a developer I do for products. Can you tell us more about that iterative agile sort of process?

Matt Reiner:

Oh yeah. Yeah, it's so true. Documentation used to be back in the waterfall standard, more typical product project management days, documentation was a major part of it. You'd start this project by writing these massive documents of, "Here's what we're going to set out to do. And here's all the considerations, and here's how everything's going to connect up." And that did work really well for a lot of hardware. Which was the thing that we made for a long time. Just everything that humankind made was hardware often, as groups anyway.

And then all of a sudden this whole software thing comes along and we're trying to build that like it's a physical thing. And we get to the end of this two-year software project and people are like, "Yeah, that's not the thing that I wanted." But we're like, "Oh, but we go back to the beginning and look at that documentation, and that's what you said you wanted." But now with the internet and with just agile development, we really need to move away from this place where we start with a pile of documents. And then we develop another pile of documents as our, I don't know, development guidelines.

And then our test plans, and then finally we end up with user documentation. Instead, these days, documentation should really just grow from a very small piece of content throughout that whole agile development cycle into that final user documentation. Because it doesn't matter what we set out to make, it matters what we make. Nobody he wants to read about what we thought we would make, that's straight up fiction. And it's probably not an interesting read. It's really that final user guide that comes out of the agile process, but that's a big change, but it's a good one.

Henri Seymour:

I love that idea of just like, this is gradually growing. There is no specific start block and end block. It's a process. And you mentioned the opportunity to iterate on those documents. Do you have any advice for after you've published digitally your technical documentation from iterating on what you've already got there, improving that over time?

Matt Reiner:

Oh yeah. I know every agile framework is different, but they all have that feedback phase, where... And really that's throughout the whole process, but we do need to dedicate some time. So, there's a lot of different things we can look at. For example, I don't want to say basic, a standard one that we should be looking at is, you should have a help center, where you can implement something like Google Analytics so you can see just, what are people looking at? How long are they looking at it?

Another really good one is, you have to set it up separately in Google Analytics. What are people searching for on your site? You can also use Google... used to be Webmaster Tools. I think it's called Site Tools now, but you can see what were people searching for on Google before they came to your pages. That's all really, really valuable stuff. Then you can get more advanced. You can look at pointer tracking, apps that you can embed on there, which you get some pretty wild stuff.

But then you also, you want to consider having a forum at the bottom of each page like, "Was this helpful? Was it not helpful? Oh, it wasn't helpful? Tell me why. Oh, it was helpful? Tell me why." Just like a YouTube creator, they look for that feedback. That feedback is essential, the thumbs up. In fact, it's very controversial, YouTube just announced that they're going to hide the thumbs down numbers, but a lot of creators are like, "No, no, no don't do that because that communicates the value of this video that is out there."

So there's a lot of those signals. And then there's just really soft signals that, it's hard to know if people are using the content or not. Because you may never hear. Especially, if it is one of those things that they just get in and get out, you're not going to hear anything about that. But the feedback phase, it's really great to... Anytime you're getting feedback on your product that you're making, try to get your documentation out there as well. Because that's the time where people are open to exploring your product and giving feedback.

So why not explore that same documentation, the related documentation to see, "Okay, is this actually helping these people do the thing that they want to do? Or should we improve it just like we do with the product?"

Henri Seymour:

No, that's a really good, comparing the, we've just released a product. Give us feedback with doing the same thing with the documentation. Because that's when it's going to reach its peak use before everyone's got the hang of it. We've just done this feature release, let us know how you go using it, and the documentation is in a sense part of it, especially for more complex products.

Matt Reiner:

Exactly.

Henri Seymour:

Do you have any background in the customer support side of things? We do customer support in-house as well as their documentation. So we're trying to improve the documentation to lower the support load on our team. Do you have any background in that... Can you solve it?

Matt Reiner:

Yeah. Well, yes and no. It's interesting. I work at K15t now, I used to be a customer of K15t's, so that's actually how I met the team. And that was also how I met documentation in the first place. At my last job, they brought me in to administrate this system called Jira. And I was like, "I don't know what that is." I told them, "I thought I could do it." And I figured it out, it was this little thing called Jira On-Demand, which is now Jira Cloud. And I introduced Confluence On-Demand to the company as well. And wow, I broke Jira a lot of times.

Luckily it wasn't like mission critical at the time, we were still really figuring it out. But it was through Atlassian's documentation on Jira that I really learned like, "Wow, there is tremendous value to this content here." And then I discovered, "Okay, how is Atlassian creating their documentation? Oh, they're doing it in Confluence. They're writing it in Confluence. They're using these apps from K15t." And so I started using those apps, and then I talked a lot to K15t customer support, just questions and how do I get this started?

And we also do our support in-house, so it's really great. So maybe as a customer, I overused it, I don't know. I should ask some of my colleagues if they got sick of me. But the benefit was very clear because they would send me, "Oh, here's documentation on this. And here's the answer to this question or here are the considerations you should keep in mind." And actually several of our teams now, we're really looking at, especially, for those features that are very robust, people have questions.

So it's like, how can we enable them to help them help themselves? And putting those resources out there is one thing, making sure that Google can find them, well, is another. But that is a really important thing, especially, since as a product team, when your user base grows, so does your need for support. It's just... I don't want to say it's exponential, but it's in line with each other. And so, one of the ways you can mitigate that is, making sure you have good design so that your product is easy to use. And then another is you need to have good content all around that entire experience so that you don't have to keep hiring more and more support people.

Or your support people can specialize and really focus on those deep entrenched issues, and then the documentation should help with the rest. But the secret sauce there is tricky. It's hard to write the perfect content to deflect the cases. That's everybody's dream.

Henri Seymour:

Even if it is just not all of them, but some of the common use cases start to get deflected away from support because people can self service. It does make a difference. And I really understand the idea of Jira documentation as well. Easy Agile works on Jira and it's... Jira is an incredibly complicated product at this point, and I imagine it probably was also complicated when it was Jira On-Demand. Because it's so complicated and so detailed, there's no way to make that easy to understand for a user without that documentation. There's no getting around that one.

Matt Reiner:

Yeah. I think there should be a club for the people who have broken workflows too many times in Jira. But yeah, I mean the documentation saved me many times and I would have to put out a... Well, it was a HipChat message at the time. May it rest in peace and I'd have to say, "I broke Jira, give me a minute. I got to go read something." Not the way you want to learn Jira, but it's an option.

Henri Seymour:

It is. Sometimes you learn things by breaking things. That's-

Matt Reiner:

That's right.

Henri Seymour:

Really seems like my experience in software so far. You try to break the things that people aren't currently using and that's about all you can do.

Matt Reiner:

Exactly.

Henri Seymour:

So K15t has recently published Rock the Docs. Can you tell us a bit more about this project?

Matt Reiner:

Yeah. Rock the Docs, actually, it came out of a lot of that information that I got from K15t. Customer support, I got from K15t documentation, I got from Atlassian documentation. And then some of the stuff I figured out on my own, or some of my colleagues at K15t did. Essentially like, what are the best practices for creating really good content in Confluence? And it really started with a collection of guides on how to create technical documentation content. It's geared toward like making a public help center, but really it's for any kind of content that you want to be like evergreen, longstanding content to be able to help people.

So we initially talked about all sorts of things like structuring your content, content reuse, managing multiple languages, which can be tricky in Confluence. Collaboration, publishing your content outside of Confluence in one way or another, managing versions of that content. So, that's the start of it. And then we saw a lot of positive response with that and we had more general questions like, "Okay, but what are the best ways to get feedback in Confluence?" Or, "How do I make a template or a good template or how do I make a good diagram in Confluence?"

And so we've grown that content to focus on just all sorts of general Confluence things. Because we found that there's a lot of information out there on how to do something. Atlassian documentation really helpful, but there wasn't as much, I'm like, "Why would you do it? And why would you do it this specific way?" And we've been working with Confluence for over 10 years now. Like I said, I've been with Confluence since the crashy early cloud days. It's grown up so fast, it's beautiful.

But we just know we've done a lot of stuff with Confluence, so it's been a real privilege to share that both in like these written guides. And then actually recently we've started publishing a series to our YouTube channel as well, all about Confluence best practices.

Henri Seymour:

That's great. It's real interesting to hear how that started as a smaller project than it turned out to be, because you could see the value in it and the use in it. We've discussed Confluence a few times now and K15t builds apps that use Confluence as a documentation source. Can you tell us more about what makes Confluence useful for building technical documentation? What sort of tools and approaches that make it useful in this context?

Matt Reiner:

Yeah. Confluence is by nature open, which is not the way technical writing tools are built. In fact, I remember the first time I went to a technical writing conference and someone asked me, "Oh, what tool do you use?" Which is like, what technical communications people talk about, because we're all nerds in that way. And I was like, "Oh, I'm doing it in Confluence." And they didn't really want to talk to me after that because they didn't think I was a serious tech writer. And I was like, "Oh no, no, no, no, this is all happening."

At that point, Rock the Docs didn't exist. So I couldn't be like, "Go over there and see how it works." But the biggest difference is most tech writing tools are just totally locked down. You have two licenses for your two people who are trained professional tech graders, and then everybody else, there's no access. You don't touch it. Maybe your tech writers will send you a PDF and you have to go through the God awful process of marking up a PDF to tell them like what to correct. Or, I've heard of teams printing out the content and people penciling in what needs to be changed.

The review processes are just out of this world insane. And those tools don't fit terribly well with agile processes because it's like, you build the thing over here, and then here's the two tech writers over here in their separate tool. And at some point we'll be like, "Okay, this thing's done. Would you write about it?" So with Confluence, the benefit of using Confluence is, it's accessible to everyone on the team and even people outside the team. And that's incredibly by an official because we've seen with agile, but we're also seeing in this technical communication and in information design field, that teams are less and less looking for those specialized individuals who are trained tech writers.

Which that's an oxymoron because half of us, we don't have degrees in tech writing, we fell into it for one reason or another. But now teams are starting to see, "Hey, I can be a code developer and an information developer. I might not write the final piece of written content that is seen by our customers, but I might write the first draft." Confluence really opens that up for everyone. And especially with like at mentioning and inline comments, review processes are just so fast.

Actually, the reason that I switched to Confluence at my last job, was my product manager threatened me and said, "I will not mark up another PDF. Go and find a good tool that we all want to work in." And that's where we landed on Confluence. It's about bringing the whole team into the writing process instead of having it be this separate thing. Because when it's a separate thing, we lose track of it. And content, we forget how important it is to our product, to the customer life cycle, to... God bless customer support, who really, really need that content to be good and accurate.

And it needs to be seen by the real experts who validate, "Yeah, okay, this is correct. This will actually show people how our product works." And Confluence is like the heart of that.

Henri Seymour:

No, it's great to hear how that all comes together to build the documentation as a team. Can you speak more to the different roles in, specifically in software development and the different roles you're looking to get involved in your documentation process? We are working on building our specific app teams here at Easy Agile as we're growing at the moment.

Matt Reiner:

Yeah. That's such a good question. Well, what-

Henri Seymour:

And how do you incorporate... Sorry, this is more specific to my question. How do you incorporate that technical writing process as part of the work of an agile software development team?

Matt Reiner:

Well, first, it starts by rethinking priorities because most teams are like, "Documentation down here, testing and then everything else above." So generally, those two things should be moved up. And actually, the content around our product is... I don't want to sound over traumatic, but if we don't have information, we don't have a product. I don't care how much code you write. If we're not explaining it to people, if we don't have good UI text, if we don't have good in-app help, it doesn't exist. It's not a useful tool, it's just a set of mathematics that humans can't interact with.

So content is essential, so it's really important that we elevate it to the position where everyone on the team recognizes that the content experience that our users have is the product experience they have. So it needs to be part of the product development process. So then the next step, which I know you're talking about team structure, but the next step is really everyone on the team needs to know they're a writer, and they're a good writer. And that's important because a lot of people have never heard that. They've never heard that they're a good writer, and they probably have never heard that they're a writer.

I remember going through university, my writing classes were the things that I didn't pay attention to. I was doing mathematics, and Java programming, and statistics. Even that seemed more important to me, not the writing classes. And then sure enough, it turns out everyone has to write. We all write. So knowing that that is a role that everyone fills is really important. And then when it comes to actually team structure, you need to have individuals who are willing to cross the streams, so to speak. If you're bringing in someone who's focusing on test engineering, they need to realize that the test plans they're writing are very similar to a lot of user documentation that needs to be written.

They're writing task topics, or task instructions, do this, do this, do this over and over again. That's documentation. They could be contributing in that way. Engineers, as I mentioned, they could be drafting the first copy of a lot of what are called concept topics. So areas of documentation where you explain concepts, because they already know what those concepts are. In fact, if you look at the root of a lot of agile development teams, they're using epics and user stories and acceptance criteria. And all those map perfectly into the documentation you needed to create for that new feature you're working on or feature you're improving.

So really, it's essential to have everybody recognize, we are all already creating documentation, so we can contribute. And then of course, you really do want to have at least one probably native English speaker. Maybe not native, but someone who feels confident in their English or whatever language you're authoring in. English is typically the cheapest one to translate to other languages, so that's what people go for often. But that person's the person who takes everything everybody's written, gets it to the right style and tone. And then gets it out there. That's what we are seeing be successful.

Like our teams right now, we don't have any legit tech writers. We have product managers writing. We have product marketers writing. We have engineers writing. Some of the best documentation I've ever read was from one of our German-speaking engineers. I was like, "Peter, this is an amazing guide. You got to get out of this Java and get into English, man. It's great. It's great." So he's done a few, which I really love. But yeah, it's about jumping out of your typical roles and realizing, we're all documenting this stuff, anyway.

Henri Seymour:

I love the focus, especially with your German-speaking colleague. The focus on, it's not just that you must write the documentation because you know how the product works and we need that written down. It's, you are capable of writing the documentation, you can do this. You have that added barrier of safety with somebody who's got the language proficiency that they're going to massage it and edit it at the end.

So, before it gets anywhere, anything that you do is going to get filtered out if it's not working. But you don't need a specific tech-writing background to write the docs.

Matt Reiner:

No, absolutely not. In fact, there's an entire community of what... They call themselves documentarians called Write the Docs. And that whole community, that whole group is focused on, it doesn't matter what you do, it matters that you care about writing the docs, contributing to the content. And that's been a big shift, I think in the industry, where people thought we're separate. But now it's like, "No, no, no, we are all able to do this." And once we can respect the contributions that each of us can make.

And then also, I have that protection of somebody else is going to have their eyes on this, which even my writing, I'm like, "I don't like to send it out until someone else has seen it." Because I make spelling mistakes and typos all the time. I really want to have another colleague look at it. Even if they're not native English speakers, because they catch my typos pretty often. That feeling of togetherness, it's the same way that we feel when we ship out a project or a product.

Whether you did the testing for it, or you wrote the code for it, or you did the product marketing for it. It's like, "It's our baby. Let's send it out and see what happens." Content's the same way.

Henri Seymour:

Yeah, part of my daily role and [inaudible 00:28:03]... We don't have QA team separate from developers. Our developers also review our code and it's that sense of, "I wrote this thing, but I have one or two other people who've refined it, who've made sure that it's good enough quality. They've got that fresh eye, so they'll see the spelling mistakes, they'll see the minor little errors that I've just been looking at it too long to notice anymore."

I found the documentation writing process has some parallels in there like, "Here's my thing. I'd like some feedback on it before it goes out into the real world."

Matt Reiner:

Yeah.

Henri Seymour:

That's great.

Matt Reiner:

Yeah, absolutely. Yeah.

Henri Seymour:

All right. Can you talk a bit about the difference between the customer-facing documentation that we've mostly discussed so far and internal documentation?

Matt Reiner:

Yeah. There are some differences and there are some major similarities. So this very... It sounds very technical and ugly. The term information architecture, it's really important with any kind of content, internally and externally. And really that's like, if you're a developer you're familiar with XML, you're familiar with structuring things in that way. Our content needs to work the same way. And that goes for internal and external documentation. So, many of the things that they use, writers, when they write a page or an article in the newspaper, they'll use that Pyramid approach, where they put the broad bits of information at the top. And then they slowly focus in on the topic and give more and more information about it.

But you want to make sure that if somebody only reads the first paragraph, they're getting a rough idea of what the information is. And that's really important for successful Confluence pages and spaces. People should be able to start at the top level of the space, understand what the space is about, and then be able to navigate down into the thing that they really want to learn about into the page itself. Which should then be using headings and subheadings and bullet points to get, again, just disseminate that information and break it down. Because everybody skims.

We need our content to be skimmable, our spaces need to be skimmable. And that kind of content also makes Confluence search happy, especially the new Confluence Cloud search, which has been greatly improved. There's a whole new elastic search base to that that's being optimized. But it's happy, it's just like with Google when we structure our content like that. So when you have a page that is just a wall of text, no headings, you're not breaking it up into pages or even spaces, nobody's going to be happy with that.

The bots aren't going to be happy with it, the people reading aren't going to be happy with it. So it takes a bit of work to structure, break up the structure of our content. It's probably all good as long as it's up-to-date, but it's really essential that we think about, how do we structure that in Confluence so that people can find it and people can skim it? And that is what seems to plague a lot of internal Confluence instances, because a lot of... Maybe the team isn't so focused on that.

It's like, "Oh, our external help center that's come coming from this space over here, that's fine. Our team space, hot mess, total tire fire." And nobody cares because they think they know where everything is. But then you start to think about, "Okay, but what about the new team member? How do they find something?" Or, "What about the team member who's been away for Paternity leave for six weeks? Are they going to remember where everything is or know where all the new stuff is?

What about folks with disabilities? Is it going to be much harder for them to navigate to the information they need? Because they're working with a screen reader and they're trying to go through a wall of text. They need headings, a screen reader relies on those headings and titles." So there's just so many considerations that really leadership of companies needs to understand, just because you have a process to do something or the information is somewhere, doesn't mean you don't have a major information problem. And maintaining all of your content in Confluence and then maintaining it well.

That is what enables people to avoid the frustrations of searching for information, losing information, having to relearn or rewrite information. I have worked at too many companies that just information sieves everywhere. I don't even want to call them silos because nobody knows where stuff is anymore either. That's what Confluence brings to things, and that's what matters with internal content pretty much as well as external.

Henri Seymour:

That's a great perspective on it. And I can see the silos, it's a really more... Just a one big pile, you can't find anything. I've been-

Matt Reiner:

Exactly.

Henri Seymour:

... at Easy Agile for more than half of its life now and I've got that sense of like, "Oh, I know I wrote this down somewhere. I know I've seen this written down somewhere." And we are making a habit, especially as we're hiring more and more people. Every time somebody's going through onboarding, they're going to be looking at all of this documentation with no previous background on it. And we want to hear their feedback on it specifically. Because if it works for them, then that's the documentation that we need for them and for everyone after them, and for everyone who's already here.

Especially, I've been at Easy Agile for almost three years now, and I've seen it grow from eight people to now we're up to high 20s, I think. We're going to cross over into the 30s by the end of the year.

Matt Reiner:

Wow.

Henri Seymour:

The growth of information that we have in our internal documentation, and I'm sure it would parallel the growth of the product documentation for a product that's been expanding for three to five years. How do you manage the documentation and the Confluence spaces as the team and the company grow and you just develop more and more pages out of it?

Matt Reiner:

That is the question since the dawn of the universe or at least the dawn of Confluence, which, what's the difference? The biggest thing is team responsibility, so knowing this is our space, this is our content. And not like in a territorial way, but this is our responsibility. Much the way we should think about our planet, we should also think about our content, keeping it groomed and taken care of, and up-to-date and accurate. And then as things change.

For example, we have a product called Scroll Viewport, which is actually what enables you to publish content from Confluence to a public health center, which is really, really cool. So with that, we had a server and data center version. We've had that for quite some time. That's what I was a user of. And then we set off to develop a cloud version, and cloud requires a whole bunch of new infrastructure, which is a lot of fun and very challenging, but it's a totally different beast.

It's not like you can just lift the server code and just drop it into cloud, which is what as a user I asked them to do for years, "why isn't this on cloud?" Now I know why. So we created a new team that started off this Scroll Viewport on cloud effort. And it was just a very scrappy project at first. And I remember the first page we got up there, it's like, "Whoa, look at this page we published." And then it progressed from there. But then at some point, we needed to bring the two teams back together. And what we could have just said, "Oh, this old Viewport space, whatever. We're just going to leave it there and then just go on with the new one."

But instead the team took time and brought the two spaces together and really went through the old content in the Viewport Server and data center space to say, "Is this all still relevant? Do we still need this?" So it's been reordered in such an amazing way. Several of our teams have gotten really good at making these spaces so that I can come in. Because I work with all of our teams, just get in and find what I need, even though I'm not working their day-to-day. I'm just so glad, I'm so proud of the team for not just letting that space languish somewhere or being afraid to delete or archive content, which a lot of people are.

It's like, "No, what if we lose something?" It's like, "No, no, no, we've moved past this. We really do need to delete it." So that's the kind of attitude it takes is, our teams to split and expand and grow, and we need conscious of that content. Because again, think of the new person, think of the person who's learning something new. Think of the person who maybe does have disabilities and is trying to get the content they need. They just don't have the background that you do. Having been with the company for half its life, you know how to dig through the thought pile to pull out just the thing you want, but they don't.

Henri Seymour:

Yeah, and I don't want to be the person that they have to ask every time they need information, "Hey, can you find this for me?" No, no. I want to build a system that means that I don't have to answer the same questions all the time. That's one of the reasons I've been doing internal documentation so much since [inaudible 00:37:36]. I've answered this question once, that will do.

Matt Reiner:

Yes. That's a really good way to motivate any contributors to documentation. "Hey, you know how you wrote that piece of our app that one time and then everybody's asked you about how it works ever since? Just document it once and I promise you can never answer it again." That's good motivation right there.

Henri Seymour:

It is. As well, we've got a team on support models, so I'm working on the store maps and personas, product development team. And that's the same team that gets all of the support requests about story maps and personas. So yeah, the better we make the product, the better we make the documentation, the less of our time every morning we spend doing that. And the more we can get back to our regular jobs.

Matt Reiner:

Exactly.

Henri Seymour:

It's been great for helping us keep in contact with the customers and what they're doing and what information they need when they're using our product. You mentioned that like it's necessary, it's valuable to be deleting an archive-based stuff, pages in Confluence from time to time. When you're looking at a page and wondering whether or not it's time to go, what sort of questions are you asking yourself?

Matt Reiner:

Well, a great one is like, look at the last modified date on that page. That's general a pretty good sign of like, "Are people even looking at it?" In fact, if you're on cloud premium and above, you can look at some great metrics on every page to see like who's looking at this thing? Is this valuable? What are the views like? Just the same way that you would look at your external website to see if your content is valuable or effective. But typically, we have a lot of debris left over from product development or team activities.

Like if you're in marketing and you have a campaign from three years ago, do you really need all of those detailed pages? Maybe keep the overall campaign page, maybe that's useful, but do you really need everything? If you're into testing, do you really need every test plan you ever created? If you're in the legal team, do you really want your legal terms from 10 years ago? Maybe, maybe, I'm not in legal. But often we have this fear of, it's like fear of missing content.

It's like, "Oh no, if I get rid of that, then I won't have it." But information, just like language, just like the way we think, just like the way our teams grow, it changes. And so we need to be aware of that. As we are changing as a team, you should expect our content to change. And part of that is shedding that old stuff. So it's always worth it, like if you're questioning it, ask another subject matter expert and be like, "Hey, I'm pretty sure we don't need this anymore, or we should revise this. What do you think?" But if nobody has any qualms, you should probably delete it.

Henri Seymour:

No, that's great. I am a big fan of decluttering, even digital decluttering. It's, I want people to find stuff and the less pile there is, the easier it's going to be.

Matt Reiner:

Yes. Because somehow bad information is less helpful than no information.

Henri Seymour:

Yes. It's like coming across a question and they're like, "Oh, I tried doing it this way." I'm like, "Oh, that way doesn't work anymore. You're going to have to do... Where did you find that written down? I'll go update out." It's-

Matt Reiner:

Yeah.

Henri Seymour:

... new people doing stuff. The best way to understand where your documentation is falling over. It's the same as you're never going to understand how your product documentation and that your product itself is failing your users until they come to you and tell you, "Why can't I do this thing?"

Matt Reiner:

Yeah. Yeah. In fact that that power of bringing in someone new on your team is so amazing. And it's almost hard to impart like first day of onboarding like, "You have fresh eyes, please use them. This is called an inline comment, please put it everywhere." I remember going through our human resources employee handbook, which we had just created not too long before I joined. And I remember them telling me, "If there's any questions, at mentioned us." And I was really afraid to do that. But we corrected a lot of things.

For example, we mentioned do these things on... What was it called after HipChat? The product that lived and died so quickly.

Henri Seymour:

I think I missed that one.

Matt Reiner:

Oh, the one that Atlassian made and then they sold it to Slack.

Henri Seymour:

Now, where do I even start on that?

Matt Reiner:

How am I... It was a great app, I really liked it. But we mentioned in the employee handbook to use that. And I'm like, "Oh, I think we're using Slack now, we should update this content." That's stuff that HR is never going to go through and catch, but your new employees can do that. New people are the best way to tell you if your processes are bad, if your content is better. Maybe not bad, but they're bringing in something new. That's why we added them to the team. And they should not be afraid from day one to ask questions, or poke holes in our already messed up or failing process.

Henri Seymour:

Yeah. And I can really see the benefit of the tools in Confluence, like that inline comment. Even if you don't know how you need that page updated or what the new version's supposed to be. It's just coming in fresh, you can go, "Oh, this is weird, or incomplete, or it might be wrong." It's just a little comment. You don't have to change it yourself, just say something. Here's a way to speak up without changing it yourself. And somebody who does know is going to be able to change it for you.

I was excited to hear you talk about information architecture. That's something I only got introduced to last year also. Do you have a general explanation of what information architecture is and why it's relevant to documentation?

Matt Reiner:

Oh, information architecture is, there are whole, people, professionals whose entire career is coming in and helping you. So I'm not one of those professionals, I just play one on TV. Really in essence, information architecture is breaking down what would be a wall of text into a pattern of information that anyone's mind can connect to. That's the real and ultimate goal, and that starts by just breaking up logical chunks. In fact, in a lot of pure technical writing, you break the content into tiny, tiny pieces, chunks or some technical communicators talk about atoms of information, really tiny pieces.

And then once you've broken that down and said, "These are separate pieces," then you assemble them together in an order that makes sense. In fact, you can also do really cool stuff with content reuse in Confluence, using include macros and the new Excerpt Include Macro is very cool in cloud, because you can do new stuff with that. But it's really about breaking apart all your content, figuring out what's the order of all of this? What's most important? What's more specific? What is important for everyone? What's important for just a few people?

And then just going down like you would with an XML structure or any other sort of hierarchy and tier that information using your spaces, your pages, your headings. And then finally bullets and paragraphs and that kind of thing.

Henri Seymour:

Thanks for getting that generally explained. Is there anything you want to mention in your work at the moment that you would be interested in getting readers onto?

Matt Reiner:

Yeah, totally. A major new effort for me, because I'm just this content explorer, I guess. I've done like technical content, I've written some marketing content. I started speaking, which I enjoy speaking. I got to speak in front of one live audience before... No, I guess a few, and then, the world's shut down for good reason. Because when you're breathing out on a bunch of people, you want to make sure that you're not potentially putting them at risk. So been doing a lot of virtual speaking.

But recently, I mentioned, we've worked on all these best practices on Rock the Docs. And so we've started this video series about Confluence best practices and it's been very exciting to figure out, "Okay, so I know how to create fairly good in Confluence, how to structure that content. Now, can we make a good video?" And it turns out, no, not at first. Made some pretty poor ones or ones that just took way too much time to make. And finally, as you do with any kind of content, we finally got a good structure, a good rhythm. And we also found what are those things people really want to hear about?

And so we've developed 16 of these now on our YouTube channel that are just out there for administrators to share with your users who are asking these questions. Or maybe these are for users directly who just want to subscribe and get these things. But it's like eight minutes of just as much information as we can pack and still speak fairly legible English. And then show just like how do you do this in Confluence? Why would you do this in Confluence? What are the things you should consider in Confluence? What are the best ways to do things in Confluence?

We've actually just started a series of live streams as well, where we're trying to look at those more in depth and then have people live listening in, asking questions and directing the whole thing. So far those have been really great and we're looking to do more of that. So the more people who pile into those, the more direction y'all get to give that content. But it's been new types of content that it's exciting to see, okay, our good written content in Confluence is coming to the real world in a new format. Which has been cool and challenging and fun and scary all at the same time.

Henri Seymour:

Yeah. That's sounds like a really exciting project. Rock the Docs is going audio-visual. And I can-

Matt Reiner:

That's right.

Henri Seymour:

... figure what... Get users on there to give you that iterative feedback that we talked about at the beginning. And so is this worth the thumbs up? Do you have comments? What else can we do? And especially in that sort of live stream webinar format, you get that direct contact with your users so you can find out what they're needing. That's that's fantastic. Probably see if I can come along with those. Easy Agile started using Scroll Viewport for cloud specifically earlier this year.

Matt Reiner:

Oh, cool. Oh, cool.

Henri Seymour:

So that's been a major improvement for us actually.

Matt Reiner:

Oh, good. Yeah. I'm just loving what the cloud team is putting out. It's so exciting and so polished and it's just like every team has that documentation space, and Viewport, it lets you put it out there and you're like, "Ah, looks so great. We're so proud of it." You can read it on any device. It's just like it's the magic that everybody wants, but no team has time. Our very few teams have time to make it look that good, so it's nice to have Viewport just do the heavy lifting.

Henri Seymour:

We've got the Confluence space, we've got the documentation. We don't have to make a website about it. It's just, "Go ahead, please make this website happen. Here's what we need on it. Here's the structure." And golly, it looks a lot better now, even just aesthetically, it looks a lot nice in the house.

Matt Reiner:

Yes. And it's nice to know that like some designer peered over the spacing between navigation items to decide how spaced out they should be. And as a writer, I can just like, I don't have to care. I don't have to care. I can throw in Confluence macros and stuff, and they just look really great when they're published. And I don't know how or why, but I'm happy. I can just keep writing. Yeah.

Henri Seymour:

Yeah.

Matt Reiner:

It would be great to have someone from Easy Agile join us for one of those live streams. Because what we're really focusing on is just like great way to do things in Confluence. We haven't jumped into Jira yet. I'm not as much of an expert in Jira, but I have thought about it because that content doesn't really exist yet. But it's not necessarily app-focused or K15t app-focused. It's just like one of the best ways you've found to do certain things in Confluence, and we're just sharing those with people alive, and it's a lot of fun.

Henri Seymour:

Yeah, that sounds great. I've got the parallel of get really into Jira and making Jira apps and Confluence is, "Yeah, we've got a Wiki. This is where we write stuff down." And it is great to have stuff like "There's the visuals on our docs page." But I don't do those. I'm busy making visuals in a Jira app. I don't want to think about that spacing. I've got my own spacing to do.

Matt Reiner:

Yeah. Yeah.

Henri Seymour:

And it really is that, I can just do the writing, I can just do product. I can do my job more because this other stuff taken care of because the experts at K15t have made that happen. And I hope that our apps can do a similar thing for their users of, this is the thing we need, we don't have to think about this. Bring in this app and it will solve a problem for us. It'll help us see what we need to and organize our information in Jira. Which is a different type of information again, but.

Matt Reiner:

Yeah, yeah. It's funny. I've talked with some people who have actually described that whole app part of Confluence in Jira as App Hell. That's a term that I've seen and I can't help but love the community because we all come up with this stuff. But app hell is, it really comes out of not understanding what a platform is partially. For example, if you're using the Salesforce platform, yeah, that's going to be app hell if you really want Salesforce to be a marketing platform. Because Salesforce is a sales platform. But then there's apps, and Salesforce happens to a sell big one. And then all of a sudden it's a marketing platform.

So that is a really interesting perspective shift for people who are used to a tool that just does one thing. Everybody thinks Excel does everything. It doesn't, we really should just use it for spreadsheets, everybody. It's not a platform for other things. Confluence is really good at these core things, Jira is really good at these core things. And then these apps, they come in to answer the questions that don't have answers and do the things that can't be done. And that's why. So is it App Hell or is it App Heaven? That's the real question. Or maybe it's maybe it's App Purgatory, I don't know. I guess the listeners gets to decide.

Henri Seymour:

The constant stream of, and yet another app needs to update. Which to be fair, I think is not a problem on cloud at this point. That's an exclusively an on-premise problem, the constant app update cycle. But we are hopefully moving towards the end of the purgatory perhaps.

Matt Reiner:

Yes. Yes. I think we're all ascending together. We're just reaching new heights all at the same time.

Henri Seymour:

Is there anything else you'd like to bring up while we talking tech docs?

Matt Reiner:

I guess, I typically go back to when I was in university, I had a manager there who told us in this on campus job that I had, "Our job is to connect people with the resources that are already around them. You're not a teacher, you're just here to connect people." And that has really stuck with me. And that is essentially what we all do. Whether we're building a product that connects people with resources or that is the resource or we're contributing to documentation or some kind of content.

We're really trying to enable people to do that greater thing, that higher level thing that is above our content, it's above our product. It's that thing that they truly care about and any part we get to play and that greater thing, that better thing. That's what it's all about.

Henri Seymour:

Yeah, that's really great perspective. That's probably also a really great thing to round off the end of the podcast with.

Matt Reiner:

I guess so.

Henri Seymour:

Yeah. Thank you very much for joining us, Matt, and for talking all things technical documentation with us on the Easy Agile Podcast.

‍

‍