Easy Agile Podcast Ep.14 Rocking the Docs
"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.
Related Episodes
Text LinkEasy Agile Podcast Ep.4 Em Campbell-Pretty, CEO & Managing Director at Pretty Agile
"We spoke in detail about scaling agile, being a SAFe fellow, discipline, the traits of effective leaders and how to trust your people."
Transcript
Nick Muldoon:
Good day, folks. Thanks for joining us for another Easy Agile Podcast. This morning, I'm joined by Em Campbell-Pretty of Pretty Agile. Em is one of 22 SAFe fellows globally and she's been doing agile transformations at scale for over a decade now. She's also the author of two books, The Art of Avoiding a Train Wreck and Tribal Unity. So, all about culture and psychological safety here, and all about obviously scaling agile release trains, tips and tricks.
Nick Muldoon:
My key takeaways that I was really jazzed about, the traits of effective leaders for scaling agile transformations and being an effective organization, trust, as in trusting their people, an openness to learning and a willingness to learn, the ability to experiment and treat things as failures if they are failures, and discipline. Em and I talked a bit about discipline today as a trait of leaders. It's a really great episode and I took a lot from it, and you'll hear my takeaways at the end and what I need to go and learn after some time with Em this morning. So, let's get started. How many weeks a year are you typically on the road?
Em Campbell-Pretty:
How many weeks a year am I typically on the road? A lot, most. It would be unusual for me to spend four weeks without going somewhere. That would be unusual. I don't travel every week, but I travel most weeks, and I travel in big blocks. Right? So, I'll go and do ... Like I said, just before the lockdown, we did three weeks in Auckland, so that was in February-March.
Em Campbell-Pretty:
We went to Auckland, we had a client in Auckland, we just stayed there. So, three weeks in Auckland, came back here, and did not return to Auckland. Returned to support that client virtually over Teams and Zoom was how that one went. But yeah. Normally between running around Australia, Southeast Asia, Hong Kong, Singapore, Manila, the US, New Zealand, yeah, not home that often, normally. This has been truly bizarre.
Nick Muldoon:
So, this is a very unusual year for someone like yourself that's flying around visiting clients all over the world.
Em Campbell-Pretty:
Absolutely. Absolutely. It's been a very strange year. It's an interesting difference on energy as well. Not flying all the time I think is good for my body. I feel the difference. I also feel the difference sitting in a chair all the time. So, I was traveling a lot, but I was on my feet most days when I was working. Now if I'm working, I'm sitting a lot.
Nick Muldoon:
You're sitting down. Yeah.
Em Campbell-Pretty:
So, that's interesting. But I don't miss the jet lag at all. I don't miss the amount of time the travel consumes at all. In fact, it's been nice. I've had a little bit of head space. I've probably blogged more this year than I have in a few years because I've just had some head space and being able to think. But I don't get to see the world either, and all my holidays got canceled. So, nevermind work. I had trips to Europe. Four weeks from now, I was supposed to be in Canada seeing polar bears.
Nick Muldoon:
Aw.
Em Campbell-Pretty:
Tell me about it!
Nick Muldoon:
I would love to see polar bears. They look so cuddly on TV. I'm not sure that that would actually be the circumstance if I was to try to approach one and give one a cuddle.
Em Campbell-Pretty:
Yeah. I don't think cuddling was involved. I was told I could bring a camera and a tripod, which means obviously I'm going to stand some distance away from this polar bear and take photos. But that will not be happening either. So, no holidays and no travel for work, and of course, being in Melbourne, not even any, let's just go to [crosstalk 00:04:15].
Nick Muldoon:
Coffee or anything like that.
Em Campbell-Pretty:
Just nothing.
Nick Muldoon:
Nothing.
Em Campbell-Pretty:
Nothing.
Nick Muldoon:
Yeah, because you've been on legit lockdown.
Em Campbell-Pretty:
Yep.
Nick Muldoon:
So, tell me then about the shift over the last 10 or 15 years in these scaled, agile transformations. Obviously today, like you described with this client in Auckland, everything's got to be remote. Presumably, not as effective. But I'd love to get a sense of what the evolution is from the transformations 10 years ago, banking, telcos, that sort of environment to the clients that you're working with today. Describe what it was like 10 years ago.
Em Campbell-Pretty:
So, 10 years ago, and it's so interesting to reflect on this now, I read Scaling Software Agility, which is a book that Dean published in 2007. Then I discovered that wasn't the latest book, so then I read Agile Software Requirements. This was 2011. I'm this crazy, angry business sponsor with this program of work I'd been sponsoring for five years that's never delivered anything, and in this cra-
Nick Muldoon:
You were the crazy, angry business sponsor?
Em Campbell-Pretty:
Yeah. Yeah, yeah. I was the crazy [inaudible 00:05:26]. I was very angry. You would be angry too if you were me. I refer to it now as the money fire. So, basically, here's my job. Right? Go to the CFO, ask for money. Give the money to IT. IT lights a match, sets it on fire. Comes back, asks me for money. I get to go back to the CFO and say I need more money. Five years. Five years. That's all I did. Ask for money and try to explain where the other money went.
Em Campbell-Pretty:
Anyway, in the strangest restructure ever, I end up the technology GM for the same group I had been the business sponsor of for the past five years. Apparently, they couldn't find anybody appropriately qualified. So, you can do it, Em. Sure. So, I'm a bit of a geek, so I read books, and I'm reading these books by Leffingwell because I'd been doing some agile ... So, I'd been doing something I'd been calling agile. Let's just go with that.
Em Campbell-Pretty:
It was interesting to me because I could see little rays of light. But it still wasn't really making anything happen, so hence the reading. These books talk about this agile release train [inaudible 00:06:46] that sounds cool. We should so do this thing. So, I set about launching this train at a Telstra in early 2012. It wasn't called SAFe, right? It was just the books and these things called an agile release train.
Em Campbell-Pretty:
Now, to look back 10 years ago, it wasn't called SAFe. People weren't running around doing this. I was not actually really qualified for the job I was in. Well, I wasn't a technology leader by any stretch of the imagination, and I decide that I'm just going to launch an agile release train. So, there were rare and unusual beasts, and I'm not sure I really understood that when I went down the path of doing it.
Em Campbell-Pretty:
I'm big on the, I read it in a book, I read it in a blog, I heard it at a conference, I'll just try it. That's very much always been my mental model. So, I read it in a book and I just tried it. Then we discover that actually, literally nobody is doing this, so it becomes Australia's first agile release train and Australia's first SAFe implementation. Oh, boy, have I learned a lot since then.
Nick Muldoon:
Well, yeah. I was reflecting on that because I dug out The Art of Avoiding a Train Wreck, right? This is one of the ones that you signed for Tegan. But obviously, you've learned a ton since then because you've managed to put together a tome of tips and tricks and things to avoid as you are pursuing these transformations. As an industry, though, well, as an industry, I guess this spans many industries, but as a practice these days, are we actually getting better at these transformations? Are there companies out there today, Em, that are still taking piles of money and setting it on fire?
Em Campbell-Pretty:
So, I think I meet people every day who hear my story and go, "Oh, my god. You used to work here?" So, I think there's still many, many organizations that have an experience that is like the experience I had back in 2010 and what have you. So, it seems to be something that really resonates with people. I guess so many of the businesses we go into now either are not agile at all or, I guess like my world was, doing something they call agile. What we find is the something that they call agile, I wouldn't say it's not agile. But it leaves a lot to be desired.
Nick Muldoon:
They're on a journey, right?
Em Campbell-Pretty:
Yeah. Yeah. Well, I guess so because they end up having a conversation with us. So, they understand that what they're doing is not enough. They understand that what they're doing isn't getting them the results that they want. I don't know that they understand why. It's interesting to me sometimes that they look to SAFe because you asked me about how's the client base changed? One of the things that's really interesting in Australia is we get far more of the small to medium sized companies now than the big ones.
Em Campbell-Pretty:
So, they're companies that consider themselves agile. But what we're calling them, the startups that are no longer startups, right? These are organizations that they're generally old 10, 20 year old startups and they're scaling and they see their problem as a scaling problem. So, that's what leads them to a conversation around the scaled agile framework.
Em Campbell-Pretty:
When we look at them through a SAFe lens, we go, "Gee, you're tiny. But okay. I can see that you can have an agile release train and it won't do you any harm. In fact, it would probably help you a lot in terms of mid-range planning," because mid-range planning just seems to be nonexistent for a lot of these organizations. Prioritization. A lot of these small organizations, very knee-jerky in terms of how they prioritize, bouncing from one thing to the other.
Nick Muldoon:
Are they reacting to the market, or are they reacting to the leaders, maybe the lack of discipline in the leadership?
Em Campbell-Pretty:
You know what? They would say they're reacting to the market. I would say they've got a discipline issue.
Nick Muldoon:
Yeah. [crosstalk 00:11:23].
Em Campbell-Pretty:
So, I read, obviously, big reader, last summer, obviously Australian summer, US winter, I read Melissa Perry's The Build Trap. Interesting book and your well respected thought leader in product management. Not a big fan of SAFe. Probably not a big fan of agile either was the takeaway I had from her book. But the thing that she does talk about that I really thought was valuable was the lunacy in chasing your competitors. So, building features because your competitors-
Nick Muldoon:
Your competitors [crosstalk 00:12:06].
Em Campbell-Pretty:
... build them, or building features to land a contract or retain a customer. So, I thought she sees all of that as lunacy, and I tend to agree. So, that was my ... I think that's quite interesting. Her perspective is you don't know if the competitor's actually having any luck with that thing that they've built. So, if you build it because they built it, you don't know. You have no idea. So, don't just build it because they've built it. It might not be doing them any favors either.
Em Campbell-Pretty:
Of course, once you start just doing random stuff for this big customer or this big client, you start to lose your way as an organization. People end up with completely different versions of their products, branches that they can't integrate anymore. It's interesting. So, when I look at that, I go, "I feel like there's a discipline issue in some of these organizations at the leadership level."
Em Campbell-Pretty:
What is it we're trying to do? What is our vision? What is our mission? What is our market? What are we doing to test and learn in that market, as opposed to just get a gun, let's do everything, grab everything? Oh, my goodness. They were doing that over there. Stop this, start this, stop this. Of course, if you're stopping and starting all the time, you're not delivering anything, and that seems to be something that we see a lot with these organizations. They're not delivering.
Em Campbell-Pretty:
I'm not saying their delivery mechanism is perfect. There's challenges there too. But some part of the problem is the inability to stay a course. Pick a course and stay a course. I'm not saying don't pivot, because that's stupid too. But being more deliberate in your choices to pivot, perhaps. Yeah.
Nick Muldoon:
Do you get a sense, Em, that there are leadership teams in various geographic regions that are more effective at this and more effective at that longterm planning and having that discipline and that methodical approach to delivery over an extended time period?
Em Campbell-Pretty:
I think regions and cultures and nationalities certainly play a role in the leadership, I don't know, persona, personality. I don't know that I could say when I've worked in this country or this part of the world that their leaders are better at forethought. I think some cultures lend themselves to lean and agile more than others. Hierarchical cultures are really, really challenging.
Em Campbell-Pretty:
That can be both a geographic thing, but it can also just be an industry thing, right? So, government can be very hierarchical. The banks can be very hierarchical. Some of the Asian cultures are very hierarchical. But some companies are just very hierarchical as well. So, who owns the company, who leads the company, all of that can play a big role in what's acceptable because so much of success in this scaled agile journey comes down to a leadership that is willing to trust the teams, a leadership that is willing to learn, a leadership that's willing to experiment, and a leadership that's prepared to be disciplined.
Nick Muldoon:
So, leadership with trusting the teams, willing to learn, willing to experiment, and with discipline. They're those four things that you-
Em Campbell-Pretty:
Yep.
Nick Muldoon:
Yeah, okay. I'll make a note of those, Em. I'll come back to those. Trust, learn, experiment, and discipline. I'm interested, I guess, this year being a very interesting, a very unique year for doing remote transformation work and coaching and consulting, 10 years ago, what was the percentage of remote team members distributed teams? Now, you've basically, I think the big banks in Australia aren't even going back to the office until 2021. Atlassian is not going back to the office until 2021. Twitter, Jack Dorsey, my old CEO, said, "Work from home forever," sort of thing. What's the takeaway for this year and what do you expect for 2021 and beyond?
Em Campbell-Pretty:
So, look. This year has been eyeopening, and look, some things are, as I would have anticipated, some things have been different. So, obviously, we're seeing entire organizations going online. We're seeing the teams are online, the PI planning's online, everything's online. That's actually in some ways opened up opportunity. So, where we've had clients who have had the most odd setups in terms of distribution, and you can make a train work where you've got teams across two locations. But we're big fans of the entire team is in Sydney or the entire team is in India. We don't have half the team in Sydney and half the team in India.
Em Campbell-Pretty:
But organizations really struggle with that because perhaps all the testers are in India and then you want a tester on every team and now you've got a problem. How do you create a complete team and not cross the time zones? So, the opportunity becomes if I can find teams that are not physically co-located but time zone friendly, I have a little bit more option. So, I can have a train that operates between, I don't know, Sydney and India. Or I can find a four hour overlap in their day, and I can insist that that team works 100% online.
Em Campbell-Pretty:
So, the big thing that we'd advise against is I don't want that team hybrid. Right? I don't want three people sitting in the office in Sydney and three people sitting in their homes in India. I want everybody online. I want an even playing field, and I think we can do that now in a way that is more acceptable than before. Because the same advice I was giving, gee, back when I wrote Tribal Unity, same advice. Right?
Em Campbell-Pretty:
So, 2016, everybody, equal playing field. If you're going to be distributed, everyone has to be online, as opposed to some people online and some people in a room. So, that's a more acceptable answer now than it was prior to this year. So, that's good. I think that's good.
Nick Muldoon:
In 2021, then, Em, you mean this is just going to play forward. I guess there's going to be a reversion of some of these companies back to the office because they've got huge real estate and workplace infrastructure already.
Em Campbell-Pretty:
Yeah. So, look. We're seeing clients closing offices the same way that you see some of the companies in the US doing that. We're also seeing parts of Australia and New Zealand with no particular COVID impact at this point actually going back into the office, and having created that example of teams that are crossing time zones, and then going back into the office and going back to that hybrid space. So, that's interesting and [crosstalk 00:20:08].
Nick Muldoon:
So, where you're back into that environment where you might have some people working together in an office that can get a cup of coffee together and then some that are stuck still at home. I guess there's not just even regional differences, right? If you've got a team member that's got a particular health situation, they're not going to feel comfortable necessarily coming back into the office, regardless of the situation, until there's a vaccine or something.
Em Campbell-Pretty:
Absolutely.
Nick Muldoon:
Yeah, okay.
Em Campbell-Pretty:
So, yeah. Look, I think it's going to be interesting. I would strongly advocate that organizations have teams that are either in person teams or online teams, and the team just either operates 100% online or the team operates 100%-
Nick Muldoon:
In the office.
Em Campbell-Pretty:
... in person and in the office, and if you have a train that has both in any train level ceremony, everybody goes to a desk and-
Nick Muldoon:
And do it online.
Em Campbell-Pretty:
... a video camera and we do it that way. I think the thing that seems to be most sticky about the physical environment and SAFe is PI planning. Nobody needs to beat. Right? That was cool. Nobody needs to beat, no one's PI planning slipped, everybody just went. They were all online. So, we'll just PI plan online. It'll be fine. We saw people use whatever infrastructure they had available to them.
Nick Muldoon:
Yeah. [crosstalk 00:21:30].
Em Campbell-Pretty:
So, I'm sure a number of people called you folks and said, "We need a tool." But some just went, "We have Google Suite, we have Microsoft whatever it is, we have this, we have that. We're just going to make it work," and no matter what they used, they made it work and they ran the events and their events were effective and they got the outcomes. The big thing that is missing is that energy. You can't get the energy of 100, 200 people in a room from an online event. But mechanically-
Nick Muldoon:
We can achieve it.
Em Campbell-Pretty:
... we can achieve it. So, we hear everybody wants to go back to PI planning in person because of the social, because of the energy, which I think is awesome. I absolutely think that is awesome, and I can see this world in which people do a lot more work from home, work remote, whatever that looks like, and then the PI planning events are the things that we do to bring ourselves together and reconnect on that eight, 10, 12 week basis. That's my feeling. Could be wrong.
Nick Muldoon:
I guess I'll be really interested to see how it plays out, and I think we should return to this conversation in 12 months, Em.
Em Campbell-Pretty:
Yeah. Oh, no.
Nick Muldoon:
I'm just thinking, what's going through my mind is one of our customers in New York, financial services company, and for one of their arts, it was 150,000 US exercised to bring their people together once a quarter.
Em Campbell-Pretty:
Yeah. Wow.
Nick Muldoon:
I'm now going, I'm like, "Okay, yes, they're doing it digitally now." That's fine. They're going to miss out on things. But if they lose the budget, do they have to fight to get the budget back? Or does the budget sit there? There's these other unknown ramifications of this shift over the course of 2020 that we're yet to see play out, I guess.
Em Campbell-Pretty:
I think you're right, and I think it would be particularly interesting for the trains that have been launched remotely. So, if the train has been launched remotely, do you ev-
Nick Muldoon:
So, not existing trains that have been working together for six to 12, 18 months. But you want to get a brand new train started. Have you done that remotely this year with some of your clients?
Em Campbell-Pretty:
Oh, we're in the process of doing it now.
Nick Muldoon:
Cool. Tell me.
Em Campbell-Pretty:
We had one, though, literally just before the lockdown. So, they did their first PI planning face to face and then immediately moved to remote working and, yeah, now working on remotely launching a train. For us, we have a playbook. It's a bunch of workshops. It's a bunch of classes. We just use online collaboration tools. We've found things that replicate the sort of tools that we would have in a physical room, and the joy of being able to read people's Post-it notes, right? This has been the absolute highlight for me, the joy of being able to read people's Post-it notes.
Nick Muldoon:
No more hieroglyphics.
Em Campbell-Pretty:
Yeah. Absolutely.
Nick Muldoon:
What is that that you wrote, Sally? Yeah.
Em Campbell-Pretty:
Everyone can say everything at once, right? So, you think about the classroom and the workshop where there's a group of people huddled around Post-its and a flip chart paper and they're still huddled in a way in their virtual huddle, but everybody can read, right? It's not that I'm not close enough, I can't read, I can't read your handwriting. There's this great equalizer is the online world. So, I think that's great. I think the challenge for the trains launched remotely is going to be do you ever get the face to face experience?
Em Campbell-Pretty:
Because if I go back over the years, one of the things we know is your first PI planning event sets the standard. So, people get this imprint in their heads of what is possible. For example, if you skip something in your first PI planning event, you just decide to, I don't know, skip the confidence vote or something weird like that, you don't do the roam of the risks or you just skip something, you never do it because you're successful without it.
Nick Muldoon:
It never gets picked up. Yeah, okay.
Em Campbell-Pretty:
You're successful without it. So, every compromise you make, and you make a series of compromises, and then you're successful despite those compromises, and that becomes a false positive feasibility. It tells you, yes, I was right. I was right.
Nick Muldoon:
I don't need to do that.
Em Campbell-Pretty:
I didn't need to do those things because I was awesomely successful and I didn't do these things. So, it's the learning [crosstalk 00:26:15]-
Nick Muldoon:
That's confirmation bias, is it?
Em Campbell-Pretty:
Yeah, that's it. That's the one. Confirmation bias. That's exactly it. Yep. Yeah, and I think there's going to be a bunch of confirmation bias in these remotely launched trains, and unless they're inside organizations where there's enough knowledge of SAFe and the physical PI planning to know that there's going to be value in bringing them together, but I can see that being a real challenge. I think trains that are launched online may never go into a physical PI planning event because of that confirmation bias.
Nick Muldoon:
All right.
Em Campbell-Pretty:
That makes me really sad.
Nick Muldoon:
I want to come back to something you said before about the leaders, and you mentioned the trust, the openness to learning and experimentation, and the discipline. I was going back over your SAFe Global 2018 talk about the seven traits of highly effective servant leaders.
Em Campbell-Pretty:
Yep.
Nick Muldoon:
Yeah?
Em Campbell-Pretty:
Yep.
Nick Muldoon:
I guess I had some questions about this, and obviously, these are four of the traits. What are the other three traits that I'm missing? Then I've got a followup question about some of the actual things that you talked about that you picked up in your trip.
Em Campbell-Pretty:
[inaudible 00:27:29] one of those four on the list I had in 2018.
Nick Muldoon:
I'll quiz you on it.
Em Campbell-Pretty:
How awkward. So, in 2018, the answer was people first, a respect for people, that sort of lens, lean thinking, manager, teacher, learner. So, we had that one. Yeah. Learner. [inaudible 00:28:00] crazy. What else did I have? [inaudible 00:28:10].
Nick Muldoon:
Yeah. Okay. I wanted to talk about that one, actually. I made a note about that. What is that, and are there examples of that in the West?
Em Campbell-Pretty:
A lot of people talk about true north.
Nick Muldoon:
[inaudible 00:28:28]. True north.
Em Campbell-Pretty:
Yeah. True north. The translation I got, which I got from Mr. [inaudible 00:28:39], who partnered with Katie Anderson for the lean study tour I did in, I don't know, '18, '17, '18, 2018, I think, so the translation he gave was direction and management sort of things. So, it's mission, right? It's strategic mission. It's that sort of thing.
Nick Muldoon:
So, just a sidebar here for anyone that hasn't seen Em's talk on this, there's a woman by the name of Katie Anderson. She runs an annual, I think, I guess not this year, but she runs an annual-
Em Campbell-Pretty:
No, not this year. She did not go this year.
Nick Muldoon:
... not this year, runs an annual lean, Kanban, kaizen study tour to Japan and visits ... Who did you visit, Em? You visited with Katie. How many were in the crew that you went over there with?
Em Campbell-Pretty:
So, I think it was a group of about 20 from memory. Katie lived in Japan for two years and then went back to the US. She lives in San Francisco, I think. While she was there, she really liked the idea of putting together these lean study tours. She was already a lean practitioner more in the healthcare side of things. So, she got the opportunity to ... We actually were on a test run tour.
Nick Muldoon:
Oh, cool.
Em Campbell-Pretty:
So, this was her experiment. She had a relationship with Ohio State University and they brought some people to the table and she brought some people to the table and they made it happen. She also had an existing relationship with Mr. [inaudible 00:30:24], who was John [inaudible 00:30:26] first manager at Toyota. So, he's a 40 year Toyota veteran.
Nick Muldoon:
Veteran.
Em Campbell-Pretty:
He came with us for the week. So, we of course went to Toyota, but we went to a bunch of Toyota suppliers as well. Isuzu, [inaudible 00:30:43]. Then we also went to Japan Post, which was fascinating. We went to a city which name escapes me right now, but they called it 5S City because all the companies in that city practice the 5S, the manufacturing 5S.
Nick Muldoon:
Tell me about it. It's not coming to mind. I don't feel comfortable or familiar.
Em Campbell-Pretty:
You don't feel good about 5S?
Nick Muldoon:
No.
Em Campbell-Pretty:
No. That's not good. So, how would I ... The 5S is five Japanese words, which I'm going to go ... Yeah. My Japanese, nothing. But it's about standardized work. So, for example, when you go into the 5S factories, you'll see the floors marked up where you need to stand to do a particular job.
Nick Muldoon:
[crosstalk 00:31:41] This is what Paul Aikas picked up for his-
Em Campbell-Pretty:
Oh, no.
Nick Muldoon:
I feel like I've seen Paul Aikas' videos of their manufacturing in the US that everything's marked up.
Em Campbell-Pretty:
Yeah.
Nick Muldoon:
Okay.
Em Campbell-Pretty:
Probably. That would be my guess. We should ask Teddy.
Nick Muldoon:
We can ask Paul, and we can ask all these people. There's time.
Em Campbell-Pretty:
Well, yeah.
Nick Muldoon:
Okay.
Em Campbell-Pretty:
Okay.
Nick Muldoon:
So, that lean tour, the Japan study tour, that was a super effective and motivating thing for you?
Em Campbell-Pretty:
Yeah. For me, it was very reinforcing. So, I had I guess my own lens on what lean leadership meant, and I found that particular tour to be very reinforcing around the value set that I believe is part of that. Katie [inaudible 00:32:43] created [inaudible 00:32:44] that is designed to show you that. So, she's often very clear that says this is not Japan, right? This is not a reorganization into Japan. This is not every leader in Japan.
Em Campbell-Pretty:
This is, I've hand picked a series of lean leaders to show you it being practiced. But it was certainly very reinforcing for me. So, very similar messages I picked up in terms of how I like to head, how I coach others to lead was built into the messages that she delivered. So, it was very cool. It was very cool. Some of those leaders, just so inspiring, particular kaizen. I think the thing that just really hits you in the face as you're talking to these folks is kaizen, this drive to get better.
Nick Muldoon:
All the time.
Em Campbell-Pretty:
All the time. Absolutely. It's these folks looking for, they're looking for the one second, right?
Nick Muldoon:
Yeah.
Em Campbell-Pretty:
The one second improvements. There's a video that floats around. Have you seen the Formula 1 video-
Nick Muldoon:
Yeah.
Em Campbell-Pretty:
... where they do, yeah, the changeover in 63 and it takes them over a minute and they do the changeover in 90-something in Melbourne and it takes them six seconds or whatever it is. It's like that, right? It's that how do I find one more second, half a second? They're just so driven. If I can remove a step that someone has to take, can I move something closer to somebody?
Nick Muldoon:
Yeah. There was some comment in the presentation that you gave. There was some comment about if I have to take another five steps, that's an extra 10 seconds. Then that's an extra 10 seconds every time I do this activity every day, and that all adds up. So, how do we shave these seconds off and be more effective and deliberate about how we do this?
Em Campbell-Pretty:
That was just huge, right? I called it kaizen crazy in the presentation. I'm just so, so driven to improve, and just tiny, small improvements every day.
Nick Muldoon:
So, one of the other practices that I didn't grok out of that talk was about the Bus Stop. What was the Bus Stop about?
Em Campbell-Pretty:
Was that in that talk? Really?
Nick Muldoon:
I'm forcing you to stretch your mind [crosstalk 00:34:57].
Em Campbell-Pretty:
You are. You are. You are. You are quite right. It really was [inaudible 00:35:01]. Okay. Oh, you're awful.
Nick Muldoon:
Yes.
Em Campbell-Pretty:
Yes. Yes, you are. Okay. So, effective leaders are human was the tagline on that one. It was really about leaders being down to Earth and being one with the teams. So, things I saw in Japan, this factory run by a woman, [inaudible 00:35:42], I think it was, so very unusual. Not a lot of women leaders in Japan. Her husband took her name because [inaudible 00:35:52]. It's a really interesting character.
Em Campbell-Pretty:
But her company has a bunch of morning rituals. You always say good morning and thank you and how they talk every day and everybody talks and everyone interacts. Then one of the other places we went to, they all had their uniforms they wore in the factory. But everybody wore the uniform, right? The CEO, the office workers, and everybody wore the uniform. Everyone was one.
Em Campbell-Pretty:
Then I was thinking about my experience leading teams, and a lifetime ago, I was working with a team that decided to enter a corporate competition. This competition was about showing your colors and showing the corporate values, which were things like better together and courage, and then [inaudible 00:36:49] a rainbow thing. So, this team decides what they're going to do, is it an address up in the rainbow colors, and they're going to be better together and show their courage and they're going to do the Macarena and they're going to video it and that's going to be how they're going to win this competition.
Em Campbell-Pretty:
I did not participate in this Macarena because someone has to take photos and stuff, right? How else are they going to enter the competition? So, had to do my bit. Anyway, we also had this ritual, which was about teams bringing challenges to leadership to resolve, and they did at the end of every spring. So, they do this Macarena and they film it and they enter the competition and at the end of the spring, they bring their challenges to leadership.
Em Campbell-Pretty:
Their challenge is Em did not do the Macarena. You are our leader, you did not do the Macarena. We are feeling very challenged by that, and we're bringing this to you to resolve. So, I went and spoke to the team that raised and said, "Look. I got to tell you. I don't know the Macarena. So, sorry." I still remember this so clearly. One of the guys said to me, "I read this blog about the importance of leaders being vulnerable." You know who wrote that blog post, don't you?
Nick Muldoon:
Oh, Em. Oh. You have it.
Em Campbell-Pretty:
So, we negotiated. I said, "Look. I think I can manage the Bus Stop." For those not from Australia, we grow up doing this in high school dances. In my part of the world, anyway. So, I grabbed my leadership team and we did do the Bus Stop and it was part of proving that we too were the same as everybody else and doing our bit and responding to the team's feedback. So, yes. That is where the Bus Stop fits in. Thanks so much for that, Nick.
Nick Muldoon:
Okay. No, I appreciate that. Now, I'm glad that I got that context. I try and do similar things. Typically, it's a karaoke or something, or that we haven't done that in a while. Yeah, okay. So, I guess the thrust of that talk was really about to leaders to serve, and it was all about being in service of. It sounds like what you took from the Japan study tour was these leaders there were very much in service of their people.
Em Campbell-Pretty:
Absolutely.
Nick Muldoon:
Do you see that as a trait that is prevalent in the best performing companies that you deal with, and how likely are they over a five, 10 year horizon, whatever that happens to be, to outperform their competitors or to be more successful in their market? Or I guess however they define success?
Em Campbell-Pretty:
I certainly see a correlation between leaders that like to serve and/or choose to serve and success with scaled agile, and business, because I guess we have seen over, it's close to 10 years, is those who practice together, your framework with discipline get results, and they get significant results. They improve their ability to deliver products and services, their cost base goes down, their quality goes up, their people are happier, their attrition goes down. We see it every single time.
Em Campbell-Pretty:
What we also see is when the leaders don't walk the talk, when the leaders are paying lip service to the transformation, it doesn't stick. They don't get the results. People don't find it a better place to work. People aren't bought into the change. So, there is definitely a correlation there. You can get pockets of wonderfulness inside an organization.
Em Campbell-Pretty:
We often observe that the organization that's transformation is as successful is the most bought in leader. Most senior bought in leader. So, if you're the leader of a train and you show the right behaviors, your train will be really great.
Nick Muldoon:
Successful.
Em Campbell-Pretty:
But that means nothing for the broader organization, solution train, the business unit, what have you. You see this thing that goes from the leader. If the leader's showing the right behaviors, you get within that space, you get the behaviors, you get the change, you get the results. But leaders who say one thing and do another, people don't buy it, right?
Nick Muldoon:
I guess this is true of any organizational change, isn't it?
Em Campbell-Pretty:
Yeah.
Nick Muldoon:
You hit the boundaries of your pocket, as you said, within the organization and then you meet the real world, the rest of the organization. People, maybe they don't have enough energy or they don't feel that they can influence and change that, and so they just live within their bubble because they don't feel that they can exert the pressure outside of that.
Em Campbell-Pretty:
Yeah. Look. I've certainly, I've seen successful bubble influence organizations. Successful bubbles can become interesting. Chip and Dan Heath's book, which one was it, Switch.
Nick Muldoon:
Oh, yeah. Switch. Yeah.
Em Campbell-Pretty:
[inaudible 00:42:02]. Shine a light on bright spot or something like that. So, bright spots inspire, and if you can create a bubble in an organization that outperforms the rest of the organization, or even if it performs better than it has previously, then everybody looks. Right? How did the organization that goes from poor delivery to great deliveries is what is going on here? That inspires others to get interested. One of the really interesting things we've seen in Australia, we can trace pretty much every SAFe implementation in Australia back to the one at Telstra.
Nick Muldoon:
Yeah, right. They all spun off from that, from the people that were part of it.
Em Campbell-Pretty:
Well, no. People who came and saw it. People who were inspired by it.
Nick Muldoon:
They're not necessarily directly involved in it.
Em Campbell-Pretty:
No. People came and got inspired by it, and then they went, did their thing, and then they inspired someone else. I haven't tried to do it recently, but there was a point in time we just could web together all of them because we could count them when we could see them. But we can web together most of them still. It says you saw someone who saw someone who saw someone who actually was someone who went to visit us at Telstra back in 2012, 2013 and got inspired.
Em Campbell-Pretty:
So, that bright spot can be really, really powerful, and that's what it takes, right? You get to add a little bit of noise, a little bit of difference, and people start to ask what's going on. I wouldn't say it's foolproof. I think it still requires, so someone's got to come, they've got to see, and then they've got to have the courage to do it for their part of the organization.
Em Campbell-Pretty:
That's the hard bit, right? I can come, I can see, I can get inspired. But am I prepared to put myself out there? There's a lot to be said for leaders who are prepared to take risks. That was one of the-
Nick Muldoon:
This was your lesson about the Bus Stop, right? You have to put yourself out there and be vulnerable.
Em Campbell-Pretty:
Yeah. Absolutely. Absolutely. This was actually, I was thinking, was the thing I was talking about at last year's SAFe Summit was be safe or be SAFe.
Nick Muldoon:
Be safe or be SAFe. Tell me about that.
Em Campbell-Pretty:
So, be safe, don't take a risk, or be SAFe, as in the scaled agile framework, and take that leap of faith. It comes back to, we started talking today about when I did this at Telstra, I didn't really understand that this wasn't a normal everyday, this is what everybody did sort of thing. It was a very new thing. So, I took a risk from a perspective that I was a business leader in a technology space and I really felt I had nothing to lose.
Em Campbell-Pretty:
So, I look back and that and go, "What on Earth possessed me?" And I go, "Well, I'm this business person leading this technology team. I wasn't supposed to succeed anyway."
Nick Muldoon:
Put it all on the line, right?
Em Campbell-Pretty:
I found out later they actually had a plan for when I did not succeed. I was supposed to fail.
Nick Muldoon:
Wait. How much waste is that? Why did they plan for something before it was ... Okay.
Em Campbell-Pretty:
Organizational policies. What can I tell you? Anyway, I did not fail. I did succeed, and because I took some crazy, calculated risks, and I've seen it time and time again, right? So many of these leaders in these companies that make this change are taking a leap of faith. I'm always saying I can't tell you exactly what's going to happen. I don't know whether you're going to get 10% cost out or 50% cost out. I don't know if your people are going to be 10% happier or 50% happier. I don't know that.
Em Campbell-Pretty:
What I do know is if you listen to what we're telling you and you follow the guidance and you behave in line with those lean and agile values, you will get results. You'll get results every single time. But you've got to be brave enough to buy in and take it on holistically and not do this thing where you manage to customize your way out of actually doing the thing-
Nick Muldoon:
Doing anything.
Em Campbell-Pretty:
... that you wanted to do.
Nick Muldoon:
Yeah. Okay. Em, this was awesome. Before we finish up, I want to take two minutes. You've mentioned books a lot today and you reminded me of this quote, Verne Harnish, "Those who read and don't are only marginally better off than those who can't." So, today so far, you've mentioned Chip and Dan Heath with Switch, you've mentioned the Leffingwell series from the late noughties. There might have been a few others. But tell me, what are you reading today? You've been in lockdown. What are the two or three top books that you've read since you've been in lockdown in Melbourne?
Em Campbell-Pretty:
Oh, my goodness. It's very awkward. Every time someone asks me, "What did you just read?" I go, "I don't know."
Nick Muldoon:
I don't think I remember.
Em Campbell-Pretty:
Can't remember. It's terrible. What am I reading? I need to open my Kindle. I don't know what I'm reading. Geoffrey Moore, Zone to Win.
Nick Muldoon:
Zone to Win.
Em Campbell-Pretty:
Zone to Win. I think that's what it's called. It's a newer book. I know this year, because obviously, I've read The Build Trap this year-
Nick Muldoon:
Yep. Melissa Perry. You mentioned that one. Yeah.
Em Campbell-Pretty:
Yep. I've read the Project to Product, Mik Kersten.
Nick Muldoon:
What was that one, Project to Product?
Em Campbell-Pretty:
Yeah. Project to Product, Mik Kersten. One of the IT Revolution press books. So, released just over a year ago. Very tied up in the SAFe 5.0 [crosstalk 00:48:21]. The other book tied up in the SAFe 5.0 release is John Kotter's Accelerate. So, I picked that back up. I read it a number of years ago when it first came out. But I like to revisit stuff when SAFe puts it front and center. Seems to make some sense to do that at that point in time.
Nick Muldoon:
Yeah, okay. It's interesting that, thinking about Verne Harnish, the scaling up framework, no relation to-
Em Campbell-Pretty:
No.
Nick Muldoon:
... scaled agile, for anyone that's not familiar. But so much of the scaling up framework about scaling businesses, they draw on so much content from existing offers, existing tomes, points of reference and experience, and it's super valuable, and I guess SAFe is no different, right? It draws on this wisdom of the collective wisdom.
Em Campbell-Pretty:
Absolutely. Absolutely. [inaudible 00:49:14] It was very fun to say in the early days, we stand on the shoulders of giants, a quote from somebody else whose name escapes me.
Nick Muldoon:
Yeah, okay. Well, Em, look. I wanted to thank you so much for your time this morning. This has been fantastic.
Em Campbell-Pretty:
No worries. It's great to catch up with you.
Nick Muldoon:
Yeah. I guess my takeaways from this, I like the be safe or be SAFe, like either be safe and don't take any risks, or be SAFe and actually put yourself out there and step into scaled agile. I definitely have to go and do a bit of research on the five S's as well and learn a bit more about that. But thank you so much for your time. I really appreciate it.
Em Campbell-Pretty:
No worries, Nick. Great to see you.
Text LinkEasy Agile Podcast Ep.27 Inclusive leadership
"It was a pleasure speaking with Ray about empowering teams and helping people reach their full potential" - Mat Lawrence
Mat Lawrence, Chief Operating Officer at Easy Agile is joined by Ray Arell. Ray currently works as the Director of Agile Transformations at Dell Technologies, is the host of the ACN Podcast, and the President Of The Board Of Directors for the nonprofit Forest Grove Foundation Inc.
Ray is passionate about collaborative and inclusive leadership, and loves to inspire and motivate others to achieve their full potential. This is exactly what Mat and Ray dive into in this episode.
Ray and Mat explore the concepts such as inclusive and situational leadership and the connection to agile ways of working, empowering the organisational brain, and fostering authenticity within teams.
This is a fantastic episode for aspiring, emerging and existing leaders! Lots of great tips and advice to share with colleagues and friends and understand the ways we can be empowering and enabling one another.
We hope you enjoy the episode!
Transcript:
Mat Lawrence:
Hi folks, it's Mat Lawrence here. I'm the COO at Easy Agile and I'm really excited today to be joined by Ray Arell. Before we jump into our podcast episode, Easy Agile would like to acknowledge the traditional custodians of the land from which we're broadcasting today, the people of the Gadigal-speaking country. We pay our respects to elders past, present, and emerging, and extend that same respect to all Aboriginal Torres Strait Islander and First Nations people joining us today. Ray, thanks for joining us today. Ray is a collaborative and inclusive leader who loves to inspire and motivate others to achieve their full potential. Ray has 30 years of experience building and leading outstanding multinational teams in Fortune 100 companies, nonprofits, and startups. Also, he's recognized as a leading expert in large-scale agile adoptions, engineering practices, lean and complex adaptive systems. So Ray, welcome, really good to have you on the podcast today.
Ray Arell:
Thank you.
Mat Lawrence:
Love to get started by understanding what you enjoy most about being an inclusive leader and working with teams.
Ray Arell:
Yeah, so I've been in leadership probably for about 15 years, leading teams at different sizes. When you have the more intimate, smaller teams of maybe five or six people, upwards of teams that are upwards of several hundred people working within an organization that I might be the leader of. And what I enjoy the most about it is just connecting with the talented people that do the work. I mean, when you go into leadership, one of the things that you kind of transition from is not being the expert person in the room that's coding or doing hardware development or something else. You have these people who are now looking for direction or vision or other things in order for them to give them purpose in order to move forward with their day.
And I enjoy coaching. I enjoy mentoring. I mean, a lot of my technical side of me is more nostalgia now more than it is relevant with the latest technologies. There's something rewarding when you see somebody who can, if you think of Daniel Pink's work of autonomy, mastery and purpose, that they suddenly find that they are engaged with the purpose that we're doing as an organization and then the autonomy for them to just do their day and be able to work and collaborate with others. And that's always been exciting to me.
Mat Lawrence:
I can relate to that. Yeah. I think in our audience today we're going to have a mixture of emerging leaders, aspiring leaders, and experienced leaders. I'd love to tap into your experience and ideally rewind a little bit to earlier in your career when you were transitioning into being a leader. And I'd love to understand around that time, what were some of the successes that you saw in the approach that you take that you've been trying to repeat over the years?
Ray Arell:
Well, I think early on, I think, especially when you grow up through the technical ranks, and suddenly at least the company that I was with at the time, very expert-based culture, if you were the smartest person in the room, those are the people that they looked at and said, "Okay, we're going to promote you to lead, or we're going to promote you to manager or promote you into the leadership ranks." I think looking back on that, I think Ray 2.0 or Ray 3.0, whatever version I was at the time, that I very much led from that expert leadership stance, which is sort of I know what is the best way to go and approach the delivery of something, and everyone should be following my technical lead for however this product comes together.
And I don't think that was really a good approach. I think that constrained people because you ended up being more or less just telling people what to go do versus allowing them to experiment and learn and grow themselves in order to become what I had become as a senior technical person. And so I think lesson learned number one was that leading a team from an expert slant I think is probably not the best approach in order if you're going... especially if you think of agile and other more inclusive teamwork type of projects, you're going to want to give people more of a catalytic or a catalyst leader type of synergistic-based leadership style so that they can self-organize and they can move forward and learn and grow as an engineer.
Mat Lawrence:
Are there any times that stand out for you where you got it horribly wrong? I know I've got a few stories which I can happily share as well.
Ray Arell:
I'd love to hear some of yours. I think horribly wrong I think is... The question is is anything ever really not fixable, not recoverable? And in most cases, most of the issues that we've dealt with were recoverable. I think that looking at, and again, kind of back into that stance of well, am I creating a team or am I creating just a group of individuals that are just taking their work from the manager and I'm passing them out like cards type of thing... I think early on, probably the big mistake was just being too controlling, and the mistake of that control meant that I couldn't have a vacation. Others were dependent versus being interdependent on one another. And I think that made the organization run slower and not as efficient as it could be.
Mat Lawrence:
I've certainly been guilty of that same approach earlier in my leadership career where I became the bottleneck, absolutely.
Ray Arell:
Yeah. Exactly.
Mat Lawrence:
And to recognize that, it can be quite hard to undo, but it's definitely worth persevering with. Something else that I was fortunate to get some training in situational leadership, oh, probably nearly 10 years ago now. And that really opened my eyes to an approach, the way I was treating different people in my team. But I was treating them the way I first judged them. So if I saw [inaudible 00:07:01] an expert and a master, I would treat them as an expert and a master in all things. And [inaudible 00:07:05] if someone was less capable at that point in their career, I'd kind of assume the same thing. And so I would apply the same level of direction or lack of direction to those people for everything. And in situational leadership, the premise for those who don't know at home, is you change the level of direction that you give depending on the task at hand. Have you used that approach or something similar to guide how you include people in different ways?
Ray Arell:
Well, in order to include people, I think part of it is you need to... As you said, you were situationally looking at each person, and you were structuring it in a way that was from a way, an approach, of very individualized with somebody. I think the philosophy that I... Not everyone is very open or can communicate very well about their skills and their strengths, or in certain cases some people, they might be good at something but they don't exercise it because they themselves feel that that's not one of their strengths, but in reality is it is. So I think that when you're saying from a situational leadership perspective, when you hear somebody place doubt that they could be the one that could do something or to take up, say, even leadership of something, I think part of that just gets into that whole coaching and mentoring and really setting it up and helping them to be successful through that.
And I think from an inclusive perspective, I think there's a set of honesty that you have to bring into your work and humility about being humble about even what you've accomplished. Because in engineering in particular, you tend to see that when you put people into a room, the people who are newer will sit back, and they will yield to who they think has the more experience. And reality is that they came from, say, let's say they just got fresh out of college. They actually might have more skills in a particular area based upon what they just went through in their curriculum that we might not have. And so the question of how do we use the whole organizational brain in order to bring all of the ideas onto the table, I think at times it requires us to be able to be effective listeners and to sometimes just pause and allow people to have the floor and pick up the pen and not hog the space, if that makes sense.
Mat Lawrence:
It really does, and I think I've seen that in every company I've worked in to some level. I'd be really interested to tap into how you go about addressing that scenario. For the people who are listening that would face that situation, it might be the first time they've been a leader and seeing that scenario and observing it. Is there any advice you would give them to help change that dynamic?
Ray Arell:
Well, one, just becoming aware of it. I frequently doodle when I'm in a group of people, and what I'll do is I'll sit there and I'll put dots on a paper of where people are at in the room, and then I start drawing lines between those individual dots if I see the communication happening between certain players. And what's interesting is if you watch that over about a 15-minute period of time, you start to see this emergent pattern that maybe someone's domineering the conversation or they're the focus point of the conversation, and it isn't going around the full room. So then that's when you get to be a gatekeeper and you invite others into the conversation. And then you politely help the ones who are being dominant in the conversation to pause, to just give space and allow those other people to talk and to get that out.
And then I think the question of whether or not what the person says may sometimes be coherent or not coherent to the conversation, or maybe they're still trying to learn about just dynamics of everything. You just have to help to get, sometimes, to get that out of people, and use open words to basically open sentence... I mean, some open questions to pull that out from them. And I think that works really well.
Mat Lawrence:I love that. I'm a doodler as well. I'm an artist originally in my early career, and I've worked my way into solving problems through tech a long time ago now, but I still can't... I need that physical drawing to help my mind think as much as anything else [inaudible 00:12:30] than just doodling on a pad.
Ray Arell:
Same here.
Mat Lawrence:
Something that you said a little earlier, we touched a little bit on inclusivity. In your LinkedIn bio you talk about being an inclusive leader who loves to inspire and motivate others to achieve their full potential. Something I'm really passionate about is that last part in particular, is helping people achieve their full potential. It's why I love being a people leader and a COO. You get to do that across a whole company. I'd love to first touch on the idea of being an inclusive leader. How do you define what it means to be one?
Ray Arell:
Well, inclusive leadership, there was an old bag that I used to have, a little coaching bag that I used to carry around with me. And at the very top of it said, "Take it to the team," was the motto that was at the top of it. And at the bottom of the bag it basically said, "Treat people like adults." Were the two kind of core things that I think part of what being inclusive is is that I have to accept the fact that, yeah, I'm a smart person, but do we get a better decision if we socialize that around the team? Do we see what other ideas or possibility thinking? Sort of in the lean sense, make the decision as late as you can.
It's more towards the Eastern culture of, well, if I keep the decision open, maybe we're going to find something that's cheaper or better or even just more exciting for our customers. And so I think part of that is knowing that you don't have to be the one that has to make the decision. You can let the team make the decision. And we all embrace because we're empowering ourselves with this was what we all thought, not just what Ray thought, which I think is cool.
Mat Lawrence:
There's a second part to that piece you talked about in your bio around helping motivate others to achieve their full potential.
Ray Arell:
Yeah, yeah.
Mat Lawrence:
Yeah. Let's talk about where that came from for you, that passion, and what are some of the ways you look to help emerging leaders reach their full potential?
Ray Arell:
Yeah, I mean, I was lucky enough when I joined Intel Corporation that Andy Grove was still running the organization at the time. As a matter of fact, he taught my Welcome to Intel class. At the time when I joined Intel, there was only about 32,000 employees. And here's the CEO, founder of the company teaching the Welcome to Intel class, which I thought was incredibly cool, a great experience to have. He oozed this leadership, whatever mojo or whatever it is he is got going out into the environment as he's talking about the company. But he was really strong on the one-on-ones, the time that you can spend with your manager or others within the organization because you can have a one-on-one with anyone within the company. And he encouraged that. And I think that helps to... When somebody is trying to figure it out, they're brand new to the company, and you get a standing invitation from the CEO that says, "You can come and have a conversation with me," I think that sets the cultural norm right up front that this is a place that's going to assist and help me along my career.
And I could tell you that there's been a number of different times that those developed into full-blown, "I'm the mentee and they're the mentors." And in those relationships over time, it's sort of like then you say, "Well, I'm going to pay that forward." Today I have at least six or seven mentees that have all sorts of questions about how do they guide through their career or if they had some specific area that they wanted to go focus on. And it's their time to pick my brain. And in certain cases, if I don't have the full answer, I can guide them to other mentors that can help them to grow.
Mat Lawrence:
I love that approach of pay it forward that you touched on there. It's definitely something that I've been trying to do in the last couple of years myself, and I wish I'd started sooner mentoring. I've had the privilege of working with some amazing leaders in my career who I've learned a lot from. And once I started mentoring, I realized how much I learned by being a mentor because you have to think. You really think about what these people are going through and not just project yourself onto them. And it validates the rationale about why you do things yourself, why you think that way. And it forces me to challenge myself.
And I think if there's anything... I talk to some of the younger people at work who are emerging leaders, and they're exceptional in their own way. They've all got very different backgrounds, but a lot of them don't feel like they're ready to be a mentor. They really are. They're amazing people. And I wonder, have you seen people earlier in their careers try and pass it forwards kind of early on or do people feel they have to wait until [inaudible 00:18:22]?
Ray Arell:
I think it depends. One, I think the education system, at least in the United States, has shifted a bit. When people go for their undergraduate degree, it used to be just they were by themselves, they did their book studies. Very little interaction or teamwork was created for this study. I mean, back when I got my electrical engineering degree, it was just me by myself. There might be occasional lab work and lab projects, but it wasn't something that was very much inclusive, nor did they have people step up into leadership roles that early. I look at now my daughter who's right now going to the university, and everything is a cohort group. There's cohorts that are getting together. The studying that they do, they each have to pick up leadership in some regards for some aspect of a project that they're working on. So I think some of the newer people coming into the workforce are sort of built in with the skills to, if they need to take up leadership with something, run a little program, run a project, they've been equipped to do it. At least that's what I've seen.
Mat Lawrence:
I love that concept. Something that I've been observing and I talk it about a lot with our leadership team and our mentor exec teams for the [inaudible 00:19:56] as well. A lot of the conversation that comes up is around team dynamics, team trust, agility within teams, and to generally try and empower teams, set them up so they can be autonomous, they are truly empowered and they're trusted to make great decisions and drive work forwards. You've got a lot of experience in agile and agile [inaudible 00:20:21] agile leader. In your experience leading agile teams, those adoptions and those transformations, I'd love to understand if you see there's a connection between being agile as a team and those traits that an inclusive leader will have. Is there a connection there in your mind between what it means to be agile and be an inclusive leader?
Ray Arell:
I think so. Because if you think of early on, they established that servant leadership was a better leadership style for agile teams. And so I think when we talk about transformation, some of the biggest failures that occur tend to be more based upon not agile, but on issues of trust and other sort of organizational impediments that had already existed there before they got started. And if they don't address those, their agile journey is painful.
I've heard people say that they've gotten Scrummed before, using it in a really kind of derogatory way of thinking that, well, instead of getting a team of empowered people to go do work within the Scrum framework, they end up being put under a micromanagement lens because the culture of the manager didn't shift, and the manager is using it as a daily way to making sure that everyone is working at 120% versus what we should be seeing in the pattern is that the team understands their flow. They're pulling work into the team. It's not being pushed. And those dynamics I think are something that if leadership doesn't shift and change the way that they work, then it just doesn't work in organizations.
Mat Lawrence:
In the many places that you've worked and coached and guided people on, you've started to come across... There's a term that we've started to use of agile natives where people who've really not known any different because so many companies in world are going through agile transformations, and that'll continue for a long time. But as some companies are born with agility at the forefront, have you experienced many people coming through into leadership roles that don't know anything but true agility and really authentic agility as you've just described?
Ray Arell:
Well, I think it's kind of interesting because as you talked about that phrase, I was thinking about it, about, well, if you knew nothing else... But I can also say that you could become native after you've been in the culture for a period of time as well. So you can eventually... That becomes your first reaction, your first habit is pulling more from the agile principles than you would be pulling from something else. Yeah, there are those people, but it's been interesting watching companies like Spotify or watching Salesforce or watching Pivotal, and I can just go down the list of companies that have started as an agile organization, they got large, and then suddenly the anti-patterns of a large company start to emerge within those companies. So even though the people within the smaller tribe are working in an agile way, the company slowly doesn't start to work in an agile way any longer. It falls underneath a larger context of what we see happening with the older companies.
And I think some of that could be the executive culture might be just coming in where they bring somebody from the outside who wasn't a native, and they have a hard time dealing with the notion that, well, we're committing to a delivery date sometime over here, and we think we're going to hit it. But no, we don't have what would be affectionately known as a 90% confident plan that says that we've cleared all risk out of the way. And yeah, it's going to absolutely happen on that day. And some of those companies get really... They feel that they have to commit everything to the street, and if they don't meet it, they've already glued those in to some executive bonus program, ends up driving bad behaviors, unfortunately,
Mat Lawrence:
Yes, I have been there. I'm assuming that in our audience, we're going to have people who are transitioning into more senior leadership roles. They're not emerging leaders, they've been doing it for a while, and they've probably run some successful agile teams at the smaller level as you've described. For those people who are moving into the more senior roles, maybe into exec positions, is there any guidance that you'd give them for navigating that change and trying to maintain, through agile principles and what it means to be agile, in those more senior roles?
Ray Arell:
Yeah, I think part of it is the work that you did as a smaller team, everything still can scale up. And I hate to use the word scale because I think scale is kind of... People kind of use it... What would be the right word? It's misused in our industry. I think values and principles are scale-free. You can still walk each day walking into your team and still embracing those 12 principles, and you're going to do good work. The question is though, is if you're doing that at the lower level, say with a Kanban board, the question is, what does it look like when you're at your executive desk? What is the method that you go pool? If you look at most of the scaled frameworks that are out today, there's very little guidance that's given to what should be in the day in the life of an agile executive. What should that look like?
And for me, if I think about the business team, the management team is working with the delivery teams daily. They should be doing that. So what are you going to put in place for that to facilitate and occur? What are you going to do about... stop doing these big annual budget processes. Embrace things like the beyond budgeting or other things where you're funding the organization strategically, and you're not trying to lock everything in on an annual cadence, but yet your organization beneath is working every two weeks. So you should be able to re-move your bets with any organization based upon the performance of each sprint. Can you do that?
The last one is probably the most important one, is impediments. And that is how fast does it take information to go from the lowest part of the organization to the highest point of the organization? And if that takes three weeks, two weeks, or even sometimes later for certain organizations, optimize that. How do you optimize an impediment that you can personally help to go remove for people so that they're not slowed down by it any longer, whatever that might be?
Mat Lawrence:
You're touching on something there, which I think is a fundamental part of being agile, which is that ability to learn and adapt, and you can only learn when you are aware of what's happening around you, you can observe [inaudible 00:28:39] to it.
Ray Arell:
Well, I said something a couple months ago, and everyone just went, "Why did you say... I can't believe you said that out loud." It's the quiet stuff out loud sometimes. [inaudible 00:28:53]. We were trying to get a meeting together to go fix one of these impediments, and all the senior leaderships was busy. They were busy. And my question was is if this isn't the most important thing right now for us, what do you do? Really, are you doing in your day if this one isn't the highest priority that you walk into? And the questioning senior leaders that maybe they're not paying attention to the right things, and sometimes speaking that truth to power is something we have to do every once in a while.
Mat Lawrence:
I agree. That level of candor is definitely required at all levels and being able to receive that feedback so you can learn and adapt as an individual, as we were talking about earlier, about being adaptive as a leader, but also as a team. There's a point that I'd like to touch on before we wrap up, which is as you climb up the career ladder and you get into a more senior position, and then you become responsible for a broader range of things, particularly as you start reaching that executive level, I've witnessed people struggle with the transition from being the person, as you talked about right at the start of this discussion, being that person who knows everything and who can direct and have all the answers into someone where I see your job changes to being the person who can identify what we know least about, what we as an exec team know least, where we're... have the least confidence, where we see the impediments and we don't know what to do with them.
How do you go about guiding people to embrace that? Because I think what I see is the fear that comes with that, almost a fear of exposure of, "Oh, I'm admitting to people I don't know what I'm doing." And I've been rewarded through my entire career by becoming more of an expert, and suddenly my job is to be the person who's confident enough to call out, this is what we don't understand yet. Let's get together and try and resolve it. When the risk is greater, the impact is greater, and you're responsible for more things, how do you help people transition into that higher-level role?
Ray Arell:
Well, I think part of it is can they let go of that technical side, having to have their hands dirty all the time? And I've seen certain leaders that, really, somebody needs to go back and say, "Are you really sure that this is the career that you're wanting to go to? You seem to be more into wanting to be into the nuts and bolts of things, and maybe that's the best place for you because you feel more comfortable in that space." The other aspect though, as they transition, I think is again, trust becomes critical. Trust the people that are working for you, that they're not coming in and being lazy and you have to go look over their shoulders all the time because you feel that they might not be being productive or other things. You have to have the ability to say that, look, that the people that you hired are talented, and they are moving us towards our goals.
I think what becomes more critical for the health of the organization is that you have to do a much better job at actually saying, "Okay, well, here is our vision," whether it be a product vision, whether it be the company's vision, whatever that might be, helping people to understand what that North Star is, and then reinforcing that not from a perspective of yourself, but a perspective from the customer. And I think this is where a lot of companies start to drift because they start to optimize some internal metric that, yeah, that'll build efficiency within your organization. But what does the customer think? And constantly being able to represent as, if you think of from an agile perspective, the chief product owner of the organization, to be able to represent this is what the customers need and want and to be able to voice that in the vision and the ambitious missions that are set up for the organization. Make it real for people.
And then the last part of that is not everything is going to happen and come true. If you read most executives' bios, there's lots and lots and lots and lots of mistakes. And I remember this of one leader, he was retiring. And I thought this wasn't most awkward time that he actually did this. He actually went up on the stage and he talked about his biggest failure. Now, throughout my career working with this person, I always wondered whether or not they were human. And then on the day of this person's exit, they finally decided to give you a few stories about mistakes that they made. And I think that he really needed to share those stories much, much earlier because I think people would've probably found... They would've been a little stressed working around him. And it would also show some vulnerability for you as a leader to say that you don't have everything figured out, and sometimes it's just a guess. We think that this is where the product needs to go.
And then as soon as you put it in front of the customers, they're going to tell you whether or not... If you take the Cano model and suddenly you're going to hit this is the most exciting thing since sliced bread, are they going to love it or are they going to go, [inaudible 00:35:12]. I'll take it if it's free. You get into this situation where it's like, well, we can't charge as much. But I think those stories become important and anchor organizations. One other aspect of this is I think that by having somebody who's approachable and can relay those stories effectively into the organization and talk about these things, I think then that opens the door for everyone else to do it as well. Because like it or not, humans are hierarchical in the way that we think about things. A lot of people manage up, so they mimic leaders. So be that leader that somebody would want to mimic.
Mat Lawrence:
I think that's great advice, Ray. The connection for me that's run through this whole conversation is around engaging with your work authentically, whether it's the team that you're trying to lead, whether it's the agile practices at whatever scale and level that you're operating at. And to build that trust to enable that to work requires that level of authenticity.
Ray Arell:
Yeah, exactly.
Mat Lawrence:
I would love, as we wrap up, for you to leave any final tips or advice for both current and emerging leaders on that topic. If there's a way beyond just sharing your own personal stories, how would you advise people? What would you leave them with to build some trust in their teams?
Ray Arell:
Well, a couple of things. Number one, you have to be mindful about who you are as a person. Again, like I was saying, that people manage up. And if you send out an email at three o'clock in the morning, and five minutes later your people were responding to you, then you're not being a really good role model of a good work-life balance. So a lot of your tendencies will bleed off into the organization. So regardless how you assess yourself, do an assessment of your leadership, where you think it is. Harvard Business Review, a long time ago, put off the levels of what they saw as leadership models. And the lowest level is the expert and the achiever-based leaders. And if you're one of those, those are not very conducive to a good agile or collaborative culture. So if you're currently setting in that slant, then you should look ways of being able to move yourself more to a catalytic or a synergistic-based leader.
And that journey's not an easy one because I went through that myself. It took years in order to pull away from some of those tendencies that you had as an expert leader. And as an example, an expert-based leader tends to only talk to other experts. If they perceive somebody not to be an expert of something, they tend to discount those individuals and not engage with them. And so again, the full organizational brain is what's going to solve the problem. So how do you engage the entire organization and pull those ideas together?
The other one is that as you go into, from an emergent leader perspective, I think you said it yourself earlier, and that's not just the bias of you're not an expert, I'm not going to talk to you, but any bias that you might have can affect the way that you lead and judge an individual, and really could limit or grow their career based upon maybe a snap judgment that you might have had. So I think you have to be mindful of your decisions that you're taking within the organization and especially the ones you're making of people. And so you got to be careful of those.
The last one is probably just... And this gets into the complex adaptive systems space. Not everything is cut and dry, black and white, or mechanistic, meaning that we can take the same product, redo it again and again and again, and we're going to get different answers. We're going to get different requirements. We're going to get different things. It's okay for that stuff to be there. And it's okay for the stuff that's coming out of our products to be different every once in a while, and specifically because everything, it's a very complex environment. Cause and effect relationships and complexity is, customer can change their mind, and we have to be comfortable with a customer changing their mind. Our customer might have new needs that come up.
And likewise, our employees, they sometimes will have change of thought or change of what they are excited about. How do you encourage that? How do you grow those individuals to retain them in the company, not to use them for the skill they have right now, but how do you play the long game there? And I know I'm getting a little long-winded here, but the thing that I see most, even with all the layoff notices that are going on right now, is that that company's not playing the long game. I think that's a bad move because all you're doing by letting an employee go is enabling your competitor with a whole bunch of knowledge that you should be retaining. So anyway, I'll cut it short there.
Mat Lawrence:
Right. Thank you for sharing your wisdom with us today. It's been an absolute pleasure. I've really enjoyed the chat. So yes, thank you for joining me on the Easy Agile Podcast.
Ray Arell:
Awesome. Thank you for having me.
Text LinkEasy Agile Podcast Ep.26 Challenging the status quo: Women in engineering
"It was great to be able to have this conversation with Maysa and have her share her story. So many great takeaways." - Nick Muldoon
Join Nick Muldoon, Co-founder and Co-CEO of Easy Agile as he chats with Maysa Safadi, Engineering Manager at Easy Agile.
As a woman, growing up in the middle east and being passionate about pursuing a career in the world of tech, don’t exactly go hand in hand. Navigating her way through a very patriarchal society, Maysa talks about her career journey and how she got to where she is today.
Having the odds stacked against her, Maysa talks about challenging the status quo, the constant pressure to prove herself in a male-dominated industry, the importance of charting your own course and her hopes for the future of women in tech.
This is such an inspiring episode, we hope you enjoy it as much as we did.
Transcript
Nick Muldoon:
Hi, team. Nick Muldoon, co-founder co-CEO at Easy Agile, and I'm joined today by Maysa Safadi, who's an engineering manager here at Easy Agile. We'll get into Maysa's story and journey in just a little bit, but before we do, I just wanted to say a quick acknowledgement to the traditional custodians of the land from which we are recording and indeed broadcasting today, and they are the people of the Dharawal speaking country just south of Sydney and Australia. We pay our respects to elders past, present, and emerging, and extend that same respect to all Aboriginal Torres Strait Islander and First Nations people that are joining us and listening in today. Maysa, welcome. Thanks for joining us.
Maysa Safadi:
Thank you, Nick. Thank you for inviting me.
Nick Muldoon:
So, Maysa's on today. We're going to explore Maysa's journey on her career to this point, and I think one of the things that interests me in Maysa's journey is she's come from a fairly patriarchal society in the Middle East, and has overcome a lot of odds that some of her peers didn't overcome, and she's managed to come to Australia, start a family in Australia, has three beautiful children and is an engineering manager after spending so many years as a software engineer. So, Maysa, I'd love to learn a little bit about the early stages of your life and how you got into university.
Maysa Safadi:
I was born and raised in United Arab Emirates. I am one of nine. I have three brothers and five sisters. I'm the middle child actually. Dad and mom, they were very focused on really raising good healthy kids and more important is to educate all of their kids regardless if they are boys or girls. Started my education at schools there. When I graduated from high school, I end up getting enrolled in a college like what you call it here in Australia, TAFE.
Education in United Arab Emirates, it's not free. Being one of nine and having that aim and goal for my father to educate all of us. When it comes to education, it was two factors that play big part of it. Can dad afford sending me to that college or university? and then after I finish, will I be able to find a job in that field? One of my dream jobs, I remember growing up I wanted to be a civil engineer, and I remember my older brother, he's the second, was telling me it's good that you want to study civil engineering. Remember, you will not be able to find a job.
Nick Muldoon:
Tell me why.
Maysa Safadi:
United Arab Emirates, it's male dominated country. Civil engineering is a male dominated industry. If you are going to look for a job after a graduation, it is pretty much given to males and Emirati males first. So, kind of it needs to go very down in the queue before it gets to me, and to be realistic, sometimes you give up your dreams because you know that you are not going to have a chance later in life.
Nick Muldoon:
Oh, my gosh, this is demoralizing.
Maysa Safadi:
Unfortunately.
Nick Muldoon:
Okay,
Maysa Safadi:
So, the decision for me to get to engineering, it was, again, I couldn't really go to university because it was too expensive. My older sister had a friend who told her about this institute that they are teaching computers. When it came to mom and dad, they really told us, "Do whatever you want, study whatever you want, it is you who is going to basically study that field and you need to like it and you need to make sure that you can make the most of it." So, with that institute, it was reasonably okay for my dad to pay for my fees and they were teaching computers. I thought, "Yeah, all right, computers, it is in science field, right? I can't maybe study civil engineering, but I'm really very interested to know more about computers."
Nick Muldoon:
Similar, close enough.
Maysa Safadi:
Close enough. I end up getting enrolled and I remember the very first subject was fundamentals of computers or computer fundamentals, something like this, and I thought, "Yeah, all right, that is interesting," and I did really finish my education from there. After two years I ended up getting a diploma in computer science.
Nick Muldoon:
So, was this a unique situation for you or were most of your girlfriends from high school also going on to college?
Maysa Safadi:
It's unique actually, unique to my family. I'm not saying it's rare, you will find other families doing it, but it's not common. It is unique because, yes, most of the girls, if not all they go to school, it's compulsory in United Arab Emirate, but very small number of them pursue higher education. Pretty much girls, they end up finishing school and the very first chance to get married, they end up getting married and starting their own family. I remember-
Nick Muldoon:
And you've chosen a different path because-
Maysa Safadi:
Oh, yeah.
Nick Muldoon:
... yes, you have a family today obviously, but you established your career, you didn't finish school and get married.
Maysa Safadi:
I think I really give so much credit to mom and dad in that sense. They told us education is more important than starting a family or getting married. They said, "Finish your degree, finish your education, then get married." The other thing they said, "Do not even get married while you are studying because for sure you won't be able to finish it. Maybe because your husband wouldn't want you to finish it. Maybe you will become so busy with the kids and you will put it back." I remember actually so many times with my older sisters when someone, it's traditional marriage there, when some people come and propose to marry or to propose for their hands, my dad always used to say, "No, finish your education first."
Nick Muldoon:
So, this is interesting because I think your eldest was born when you went and actually continued education and got your master's, is that correct?
Maysa Safadi:
Yes. I got diploma in computer science. However, I always wanted a bachelor degree. I knew that there is more to it. I fell in love with computing but I wanted more, and always I had that perception in mind, "If I'm going to get a better opportunity, then I have to have a better certificate or education." So, I thought getting a bachelor degree is going to give me better chances. I was working in United Arab Emirates and saving money, and Wollongong University had a branch there in Dubai. So, I had my eyes on finishing my degree there. Eventually I end up enrolling at Wollongong University, Dubai campus, to get my bachelor degree in computer science.
Nick Muldoon:
So, just for folks that are listening along, Wollongong is the regional area of Australia where Maysa and I and many of our team live. So, University of Wollongong is the local Wollongong University that has a branch in Dubai.
Nick Muldoon:
So you were with University of Wollongong doing this bachelor degree, and how did you make the transition and move to Australia?
Maysa Safadi:
When I was studying at Wollongong University, Dubai campus, and was working at the same time to be able to pay the fees, I met my husband at work, and happened that he has a skilled migrant visa to come to Australia, coincident. So, I was thinking, "All right, he is going to go to Australia, he is a person that I do really see spending the rest of my life with. So, how about if I transfer my papers to Wollongong University here in Australia, finish my degree from here, while he gets the chance to live in the country, and then we can make our minds. 'Is it a place for us to continue our life here?' If not, it was a good experience. If good, that is another new experience and journey that we are going to take." So, we end up coming to Australia. I finished my degree from here.
Nick Muldoon:
What did you find when you arrived at Australia? How was it different from United Arab Emirates? How was it different for women? How was it different for women in engineering given what your brother had said about civil engineering in Dubai?
Maysa Safadi:
I had a culture shock when I came to Australia. Yes, I was in a country that.... male-dominated country, third world country, no opportunities for females, to a country where everything is so different. The way of living, the communication, the culture, everything was so different. When it comes to engineering, because I didn't really finish my degree in United Arab Emirate, so I didn't even get the chance to work in engineering though. However, knowing about the country and knowing about the way they take talents in, I knew I had slim chances. Now, coming to Australia and to finish my degree at the university, it was challenging. Someone from the Middle East, english is second language, being in computer degree where looking around me, "My god, where are the girls? I don't really see many of them around." And then, yeah, getting into that stereotype of industry or of a field where it is just only for males.
Nick Muldoon:
Yeah, so a bit of a culture shock coming across. I guess fast forward, you've spent a decade in software engineering and then progressing into engineering leadership. What was the change and how did you perceive the change going from a team member to a people leader?
Maysa Safadi:
I graduated from Wollongong University and I end up getting a job at Motorola as a graduate software engineer. In the whole team there was three females.
Nick Muldoon:
How big was the team?
Maysa Safadi:
How big was the team? It was around 20.
Nick Muldoon:
Okay.
Maysa Safadi:
Yep. There was the network team which had, I can't remember how many, but it was a different team. The team I was in, it is development team, and there was three girls in there, one of them another graduate that end up coming to the program and one that started a year before. Interesting, these two females, they are not in IT anymore. I really loved the problem solving, I really loved seeing the outcome of my work in people's hands because I was developing features for mobile phones. So, all was in mind then as an IC, how to become better at my work, how to learn more, how to prove myself to everyone that I'm capable as much as any other male in the team.
Nick Muldoon:
Do you think, Maysa, that that's something that you've had to do throughout your career to prove yourself?
Maysa Safadi:
Yes, yes. It's a tough industry. Really not seeing so many females it makes it hard because you look for role models that makes you think, "Oh, she made it. I can make it. If she's still in there, then I can learn from her." I missed all of that. I never had another mentor in my career or having even a female manager in all of the jobs I had before. So, always I was dealing with males, always I was trying to navigate my way to show them the different perspective I can bring. Even the subtle interactions I used to have with them giving me that, "You are not capable enough. You are not there yet. This is our territory. Why are you here?" All of these things, it does really, without you think about it, it does really sink your self-esteem and the self-worth when you are in industries like this. Yeah.
Nick Muldoon:
So, I'm conscious, you know are in this position now, you've kind of talked about you can't be what you can't see. If you can't see a woman that's a people leader and you're not reporting to one, then it's hard to see how you can become that. But, here you are, you have become that, and for our team here, you are one of the women leaders in the company, which is fantastic. So, I guess, what are the sorts of activities that you are undertaking to try and be present and be visible that you can be a woman people leader in the engineering field. I think it was earlier last month perhaps that you were at WomenHack in Sydney.
Maysa Safadi:
Yes, I've been-
Nick Muldoon:
What's WomenHack?
Maysa Safadi:
Okay. WomenHack, it is organization to bring diverse talented women intake together, to support them, to educate them, and not just only that, to try to connect them with other companies that they appreciate diversity and inclusion, and basically try to recruit... Pretty much, it is finding opportunities for women in tech, in companies that they do value the diversity.
Nick Muldoon:
Okay. So, I think it's interesting, I see these parallels here between your mom and dad that kind of went out on a limb and extended themselves financially to get six girls through a college and university education in the Middle East, and they were doing something that was perhaps fairly progressive at the time. You said it wasn't common. It sounds like WomenHack is bringing together more progressive companies these days, that are creating opportunities for women to get into leadership or even to accelerate their careers.
Maysa Safadi:
Yes, it is so pleasing to see the change that has happened over the years. When I reflect back in 2000, when I graduated and end up working in IT, and all of the behaviors, there was no knowledge or there was no awareness how much diversity is important, and they were not even aware that really females are really quitting the field or not that many females enrolls in the first place in degrees like computing or engineering. Even education through the school, no awareness was there. Then you see now the progress that is happening, more awareness is during school. Universities, they are trying to make the degrees or the fields more inviting for females and diversity. They are trying to bridge the gaps. So, many companies that are taking action to make it easier for females to be in the field and to progress in the field.
So, WomenHack, there are so many other groups like Women in Tech, there are so many companies that are allies to females in tech as well, where they are trying to really support and make their voice heard by other companies. Is as well all of the research and the science, are really proving that having diversity in teams, it is going to be more beneficial for the companies, for the teams, to have more engaging teams having these differences. So, yeah, there is a lot of awareness happening at the moment, and so many companies are trying to do something about it. I wish if that was early on.
Nick Muldoon:
Earlier in your career.
Maysa Safadi:
Earlier in my career, yes. So, many times I felt so isolated. So many times I was sitting back and saying, "Is it worth the fight?" Why do I have to work always twice as hard, to just only prove that I'm capable? Why does it have to be this way? Why I'm not equal?" That what actually made me change my career from IC to people leader. I didn't want to put other females... Being people leader wasn't just only for females, it was for me to voice, to be able to help pretty much. People leader to be able to help anyone in the field regardless if they are males or females. Moreso is to lead by example, is to be a role model for others, is to show others that if I can make it, then definitely you can as well, is to provide the support, it's to build that trust.
Nick Muldoon:
So, how can we, as an industry, I guess, how do we change... I'm reflecting on Iran at the moment, and the activities that have taken place over the last 60 days in particular, but really just more media coverage for hundreds of years of oppression of women. What do you hope, you being a people leader, a woman that's come from the Middle East, what do you hope for these young women and girls in our Iran over their trajectory? If we're still making a journey here in Australia, in a male dominated industry, what sort of hope do you have over the 20 years from here to 2040, for these women that are in the Middle East today and still haven't found a progressive society?
Maysa Safadi:
Politics. It's the game of power. Really hoping is the awareness to get there for these females in locked countries to know that there are better opportunities for them. They need to be stronger, they need to support each other, they need to empower each other. As much as it is easy said, it's not that easy done. However, all of that frustration that is built in them, it is surfacing from time to time. I'm really hoping for Iranian women, not just only Iranians, I'm really hoping for every woman in the world, regardless if it is a third world country or even if it is advanced country like Australia, is to always feel that they are worthy, is always to feel that they can have a voice, they can be part of life, and they are doing meaningful things.
Now, if they are raised in a way that always being told you are second, always being told you role only to get married and raise family, they will believe it themselves. So, it needs to come from women like us, leading by example, being role models, sending the awareness. Really media, we need to use the media very well so we can get to these people who are really locked in their countries now thinking that this is normal. It a lot of work needs to happen.
Nick Muldoon:
Well, that's an interesting observation. It is normalized for them, isn't it? So, look, reflecting on my own upbringing, I remember that my parents would always say you can achieve anything you put your mind to, but I could open up the newspaper, I could look on TV and I could see a host of people that were people that look like me, that is white males that were Australian, that were successful in business, and so I believed that I could do and be whatever I wanted to do and be. So, I guess, how do we get this message out? How do we tell your story more broadly to get this message out? That you can do whatever you put your mind to, you can achieve whatever you hope to achieve. There's something interesting for me to reflect on about the media piece that you're talking about.
Maysa Safadi:
Yeah, and I think the countries that they are advanced, the countries that they are really recognizing women more and more, they are more responsible in sending that awareness. They have to do more. It is basically, yeah, media, it is such an important thing. This is what people read everyday or watch everyday.
Nick Muldoon:
I guess, I'm conscious, like we're talking about half a world away in the Middle East, but you're actually involved in a community group here at home. What's that group that you're involved in and how's that helping women?
Maysa Safadi:
Yeah, I'm a board member for organization called Women Illawarra. It is run by women, for women. Basically this organization is to help women in domestic violence, it's basically to set them in the right path. It gives them services and it does educate them and even help them with the counseling, with legal support so they can get out of these situations. Make them believe that they can be part of this society, that they are important voice in the society, in the community, and they can really contribute and make an impact. So, by providing this education and this support, it is empowering these women to take matters their hand, and again, to really set the path for their own life and their own success. They need to take control back again, and yeah, even help their kids see their moms that they are really doing the right thing.
Nick Muldoon:
It's this interesting thread that comes through in your entire life story and your journey, that mom and dad wanted you to have an education so that you were empowered to chart your own course in life-
Maysa Safadi:
Yes.
Nick Muldoon:
... and here you are today, giving back to other women, trying to help them get an education and feel empowered so that they can chart their own course in life. I think that's fantastic. Thank you, Maysa.
Maysa Safadi:
Thank you.
Nick Muldoon:
What is your hope for women over the next 10 years? Because it sounds like we're on a trajectory, we're making progress in some countries, we're not making as much progress in other countries. What's your hope for 2030? What does it look like?
Maysa Safadi:
My hope for 2030, or my hope for... I really hope it is even five years, less than 10 years. My hope for 10 years is not to have conversations about how to reduce the gap between males and females, because by the 10 years time, that should be the way everyone operates. My hope in 10 years time is to have equal opportunities for anyone regardless what's their gender, background, language they speak, physical abilities, it needs to be equal, it needs to.... Equity, it is such an important thing. Giving exposure to the same opportunity, it is so important regardless what's your abilities. Stereotyping, I need that to get totally erased from the world.
We are all a human, we did not really choose where we born, who our parents are, what our upbringing, what our financial situation, it wasn't our choice, why do we have to get penalized for it? We have responsibility toward the world to help everyone. We are social people, we really thrive when we have good connections and good bonds, we really need to tap into the things that makes us better. So, we have so many talents that we can use it to the benefits of the world. I know countries always going to have fights and politics, that everyone is looking for the power, that's not going to disappear. But us, as people part of this world, we really need to try to uplift and upskill everyone around us. I really hope for the females in all of the other countries to know that they are worth it, to know that they are as good as anyone else. They have the power, they don't realize how much strength and power they have. So, it comes from self-belief. Believe in yourself, and you will be surprised how much you will be able to achieve.
Nick Muldoon:
There you go. Believe in yourself and you'll be surprised with how much you are able to achieve. Maysa Safadi thank you so much for your time. Really appreciate it.
Maysa Safadi:
Thank you so much Nick. Thank you everyone.