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
- Podcast
Easy Agile Podcast Ep.13 Rethinking Agile ways of working with Diversity, Equity and Inclusion at the core

"The episode highlights that Interaction, collaboration, and helping every team member reach their potential is what makes agile work" - Terlya Hunt
In this episode join Terlya Hunt - Head of People & Culture at Easy Agile and Caitlin Mackie - Marketing Coordinator at Easy Agile, as they chat with Jazmin Chamizo and Rakesh Singh.
Jazmin and Rakesh are principal contributors of the recently published report "Reimagining Agility with Diversity, Equity and Inclusion".
The report explores the intersection between agile, business agility, and diversity, equity, and inclusion (DE&I), as well as the state of inclusivity and equity inside agile organizations.
“People are the beating heart of agile. If people are not empowered by inclusive and equitable environments, agile doesn't work. If agile doesn't work, agile organisations can't work."
📌 What led to writing the report
📌 Where the misalignments lie
📌 What we can be doing differently as individuals and business leadersBe sure to subscribe, enjoy the episode 🎧
Transcript
Terlya Hunt:
Hi, everyone. Thanks for joining us for another episode of the Easy Agile podcast. I'm Terlya, People & Culture business partner in Easy Agile.
Caitlin Mackie:
And I'm Caitlin, marketing coordinator at Easy Agile. And we'll be your hosts for this episode.
Terlya Hunt:
Before we begin, Easy Agile would like to acknowledge the traditional custodians of the land from which we broadcast today, the Wodiwodi people of the Dharawal nation, and pay our respects to the elders past, present and emerging, and extend the same respect to any Aboriginal people listening with us today.
Caitlin Mackie:
Today, we'll be joined by Jazmin Chamizo and Rakesh Singh. Both Jazmin and Rakesh are principal contributors and researchers of Reimagining Agile for Diversity, Equity and Inclusion, a report that explores the intersection between Agile business agility and diversity equity and inclusion published in May, 2021.
Terlya Hunt:
We're really excited to have Jazmin and Rakesh join us today. So let's jump in.
Caitlin Mackie:
So Jazmin and Rakesh, thank you so much for joining us today. We're so excited to be here with you both today, having the conversation. So I suppose today we'll be unpacking and asking you questions in relation to the report, which you were both principal contributors of, Reimagining Agility with Diversity, Equity and Inclusion. So for our audience tuning in today who may be unfamiliar the report, Jazmin, could you please give us a summary of what it's all about?
Jazmin Chamizo:
Absolutely. And first of all, thank you so much for having us here today and for your interest in our report. Just to give you a little bit of background of our research and how everything started out, the founder and the owner of the Business Agility Institute, Evan Leybourn, he actually attended a talk given by Mark Green. And Mark who used to be, I mean, an Agile coach, he was referring to his not very positive experience with Agile. So this actually grabbed the attention of Evan, who was a big advocate of agility, as all of us are. And they decided to embark upon this adventure and do some research trying to probe on and investigate the potential relationship between diversity, equity and inclusion and Agile.
So we had, I mean, a couple of hypothesis at the beginning of the research. And the first of hypothesis was that despite the positive intent of agility and despite the positive mindset and the values of Agile, which we all share, Agile organizations may be at the risk of further excluding marginalized staff and customers. And the second hypothesis that we had was that organizations who actually embed diversity, equity and inclusion directly into their Agile transformation and then strategy may outperform those organizations who don't. So we actually spent more than a year interviewing different participants from many different countries. And we actually ended up seeing that those hypothesis are true. And today, we would like to share with you, I mean, part of this research and also need to encourage you to read the whole report and also contribute to this discussion.
Terlya Hunt:
Amazing. And Jazmin, you touched on this a little bit in your answer just then, but I guess, Rakesh, could you tell us a bit more about what was the inspiration and catalyst for writing this report?
Rakesh Singh:
Yeah. So thanks for inviting once again. And it's a great [inaudible 00:03:51] talk about this beautiful project. The BAI was actually into this activity for a long time, and I happened to hear one of the presentation from Evan and this presentation actually got me interested into business agility and associated with DEI. So that was one thing. And second thing when Evan talked about this particular project, invited all of us, I had been with transformation in my job with Siemens for about three decades for a very long time. And we found that there were always some people, whenever you do transformation, they were not interested or they were skeptical. "We are wasting our time." And okay, that was to be expected, but what was surprising that even though Agile came up in a big way and people thought, "Okay. This is a solution to all our miseries," even though there was a focus on culture, culture was still our biggest issue. So it appeared to me that we are not really addressing the problem.
And as Jazmin talk about our goal and our hypothesis, and that was attractive to me that maybe this project will help me to understand why some [inaudible 00:05:12] to get the people on board in some of the Agile transformation.
Terlya Hunt:
Thank you. That was awesome. I think it definitely comes through in the report that this is a topic that's near and dear to all of you. And in the report you mentioned, there's a lack of consensus and some misalignment in defining some of these key terms. So thought to frame the conversation today, Jazmin, could you walk us through some of these key definitions, agility, diversity, equity, and inclusion.
Jazmin Chamizo:
That's a great question now, because over the last year, there's been a big boom on different topics related to diversity, equity and inclusion, I mean, especially with the Black Lives Matter movement and many different events that have affected our society in general. And with the rise of social movements, I mean, there's been a lot of talk in the area of diverse, equity and inclusion. And when we talk about agility, equality, equity and inclusion and diversity, I mean, it's very important to have a very clear understanding of what we mean with this terms. Agility is the mindset. I mean, it's really about having the customer, people, at the very center of the organization. So we're talking about agile ways of working. We're talking about more collaborative ways of working. So we can bring the best out of people and then innovate and put products into the market as fast as possible.
Now, when we were thinking about agility and this whole idea of putting people at the very core and customer at the very core of organization so we can respond in a very agile and nimble way to the challenges that our society presents at the moment, we found a lot of commonalities and a lot of similarities with diversity, equity and inclusion. However, when we talk about diversity, equity and inclusion, there's some nuances in the concepts that we need to understand. Diversity really refers to the mix. It refers to numbers, to statistics, all the differences that we have. There's a very long list of types of diversity. Diversity of gender, sexual orientation, ways of our thinking, our socioeconomic status, education and you name it, several types of diversity.
Now, when we talk about equality, I mean, we're talking about applying the same resources and support structures, I mean, for all. However, equality does not actually imply the element of equity, which is so important when we talk about now creating inclusive environments. With equity, we're talking about the element of fair treatment, we're talking about social justice, we're talking about giving equal access to opportunities for all. So it's pretty much about leveling the filed, so all those voices can be part of the conversation and everybody can contribute to the decision making in organizations and in society. So it's that element of fair treatment, it's that element of social justice that the element of equity has to contribute and that we really need to pay attention to.
And inclusion is really about that act of welcoming people in the organization. It's about creating all the conditions so people, everybody, can thrive and everybody can succeed in an organization. So I think it's very important, I mean, to have those definitions very clear to get a better understanding of how they overlap and how there's actually, I mean, a symbiotic relationship between these concepts.
Caitlin Mackie:
Yeah. Great. And I think just building on that, interaction, collaboration and helping every team member reach their potential is what makes Agile work. So your report discusses that there are lots of overlaps in those values with diversity, equity and inclusion. So I think, Rakesh, what are those key overlaps? It seems those qualities and traits go hand in hand. So how do we embrace them?
Rakesh Singh:
So if you see most of the organization which are big organization and being for about two decades or so, and you compare them with the startup organization, so in the traditional setup, normally people are working in their functional silos, so to say. And so the Agile transformation is taken care by one business function. It could be a quality team. It could be a transmission team. And DEI normally is a domain of an HR or people who enter the organization. And the issue is that sometime these initiatives, they are handled separately and the amount of collaboration that's required does not happen, whereas in a startup company, they don't have these kind of divisions.
So looking that as a basis, what we need to look at is that the organization should be sensitize that they work together on some of these projects and look at the underlying what is the commonality, and we can possibly either help each other or complement each other, because one example is, if I can give, it's very easy to justify an Agile transformation relating to a business outcome, okay, but any people related change is a very long-term change. So you cannot relate that to a business outcome in a shorter timeframe. So I call Agile and DEI as symbiotic. An Agile can be helped by a DEI process and DEI itself can be justified by having an Agile project. So they are symbiotic.
Now, what is the common thing between the two? So there are four items. I mean, there are many things which are common, but four things which I find are most important. Yeah? The first thing is respect for people, like Jazmin talked about being inclusive. So respect for people, both Agile and DEI, that's a basis for that. And make people feel welcomed. So no matter what diversity they come from, what background they come from, they're feeling welcome. Yeah? The second part is the work environment. So it's a big challenge to create some kind of a psychological safety. And I think people are now organizing, the management is now understanding that they think that they have provided a safe place, but people are still not feeling safe for whatever reason there. That's one thing.
The other thing is that whatever policies you write, documentation, policies or announcement, the basic things that people see, is it fair and is it transparent? Yeah? So I used to always see that if there are two people given bonus, if one person get 5% more, no matter how big is the amount, there's always felt that, "I have not got my due." Yeah? So be fair and be transparent. And the last one is that you have to invest in people. The organization need to invest in people. The organization need to invest in enabling them with opportunity to make use of new opportunity, and also grow and through learning. So these are four things that I can see, which actually can help both being an agile, and also having inclusive environment in the company.
Caitlin Mackie:
The report mentions that some of those opportunities to combine agile and diversity equity inclusion are being overlooked. Why do you think this is?
Rakesh Singh:
So I think that the reason why they're being overlooked is that, it's basically, educating the leaders. So it's just, if I'm in the agile world, I do not really realize that there are certain people related aspect. I think, if I just make an announcement, people will participate. Okay? So that's the understanding. On the other side, we got an input from quite a few responders saying that some of the DEI projects are basically words, are not really sincere about it. It's a waste of time. "I'm being forced to do certain training. I'm forced." So the sincerity part, sometime there's a lacking, so people have to be educated more at a leadership level and on at a employee level.
Caitlin Mackie:
I think a really interesting call out in your research is that many agile processes and rituals are built to suit the majority, which excludes team members with diverse attributes. Jazmin, what are some of those rituals?
Jazmin Chamizo:
Yeah, that's a great question. Now, if you think about agile and agile rituals and for example, I mean, daily standups, a lot of those rituals have not actually thought about diversity, or the design for diversity and inclusion. I mean, agile is a very on the spot and is a very, who can talk, type of rituals. But there's a lot of people, I mean, who might need more time to process information before they can provide inputs, so fast. So that requirement of processing information or giving input in a very fast manner, in daily standups, that might be overlooking the fact that a lot of people, with a different type of thought processing styles or preferences may need more time to carry out those processes.
So that would be, I mean, number one; the fact that it's very on the spot and sometimes only the loud voices can be heard. So we might be losing a lot of opportunities, trying to get feedback and input from people with different thinking styles.Now, also, if you think about organizations in different countries, where English is not the native language of a lot of people, they may also feel a lot of disadvantage. This happens a lot in multinational organizations, where people whose, you know, first language is English, they feel more confident and they're the ones who practically may monopolize now the conversations. So, for people who's first language is not English, I mean, they might feel at a disadvantage.
If you think about older employees who sometimes may not be part of an agile transformation, they might also feel that are not being part of the team and they may not have the sense of belonging, which is so important in an agile transformation and for any organization. Another example, I mean, would be people, who because of their religious belief, I mean, they need maybe to pray five times in a day, and I mean maybe a morning stand up might mean very difficult to adapt to, or even people with disabilities or language differences, they feel a little intimidated by agile. So there's a lot of different examples. And Doug report actually collects several lived experiences, by the respondents that we interview that illustrate how agile has been designed for the majority and for a more dominant type of culture and that highlights the need to redesign many of these rituals and many of these practices.
Caitlin Mackie:
Yeah, I think just building on that in your recommendations, you mentioned consciously recreating and redesigning these agile ways of working. What are some of the ways we can rethink and consciously create these?
Jazmin Chamizo:
Mm-hmm (affirmative). Well, the good news is that, during our research, and during our field work and the conversations that we had with some organizations mean there's a lot of companies and organizations that have actively implementing them different types of practices, starting from the way they're managing their meetings, their rituals, their stand ups, giving people an opportunity to communicate in different ways. Maybe giving some room for silence, so people can process their information or providing alternative channels for people to communicate and comment either in writing or maybe the next day. So it doesn't have to be right there on the spot., and they don't feel under that type of pressure.
Now, another example would be allowing people, I mean, to also communicate in their native language. I mean, not necessarily using English, I mean, all the time as, I mean, the main language. I think it's also important for people to feel that it can contribute with their own language, and also starting to analyze, I mean, the employee experience. We're talking about maybe using non-binary options in recruitment processes or in payroll. So, I mean, starting to be more inclusive in the different practices and analyzing, I mean, the whole employee journey. I mean, those are some examples that we can start implementing to creating a more inclusive environments. And the one that is the most important for me is encouraging leadership to intentionally design inclusive work environments through the use of, like creating environments that are really where people feel safe, where they have this. Psychologically safe.
Terlya Hunt:The whole section on exploring and challenging existing beliefs is so interesting. And I would definitely encourage everyone listening to go and read it. I could ask you so many questions on this section alone, because I think it was full of gold, and honestly, my copy is highlighted and scribbled and I read it and reread it, there was so much to absorb. The first thing that really stood out to me as a HR practitioner in an agile organization was this belief that focusing on one or two areas of diversity first is a good start. And from your research, what you actually found was that survey respondents found this method ineffective and actually harmful for DEI. And in your research, you also reference how important it is to be intentional and deliberate. So I guess, how do we balance this need for focus and creating change with these findings that being too narrow in our focus can actually be harmful? Might throw this one to you, Rakesh.
Rakesh Singh:
So actually, thanks to the reform data report, very interesting, in fact, we presented to quite a few groups. And one of the thing that I observed when we are talking about some of the beliefs and challenges, there were immediate to response say, "Hey, we do experience in our area." So, what we realized is that this whole aspect, as Jazmin talked about, many dimensions. So if you look at inclusiveness, and diversity and equity across organization, there are many streams, and many triggers. As diversity, we understand, okay, in very limited way, it may be gender, or it may be religion or country, but actually, it's much more in a working environment, there are many dynamics which are [inaudible 00:22:15]. So the challenges, what we saw was that if you pick up a project in a very sincere way and say, "I'll solve one problem, okay?" Let me say I solve problem of a region or language, yeah? Now the issue is that most of the time, we look at the most dominant and identify that problem.
So what happens is that you actually create an inequity right there, because there are other people they are suffering. They are, I won't say, "Suffering," but they're influenced by other factors of diversity and they felt, "Okay, nobody's really caring for me." Yeah? So you have to look at in a very holistic picture, and you have to look at in a way that everybody is on board, yeah? So you may not be able to find solution to every specific problem, but getting everybody on board, and let people work in some of the environment or either psychological safety or the policy level, so create an environment where everybody can participate, and issues can be different so they can bring up their own issues, and make sure they feel that they they're cared for. And that's what we actually observed.
Terlya Hunt:
And the second belief I thought was really interesting to call out was that this belief that we will adapt to somebody's beliefs if they ask. And your research found that not everyone is able to disclose their needs, no matter how safe the working environment, so that by relying on disclosure is the first step in the process,. Organizations will always be a step behind and, and also place the burden of change on marginalized groups. What are some things we can do, Rakesh, to remove this pressure and to be more proactive?
Rakesh Singh:
So there are a couple of things that we need to look at when we talk to people, actually, they discussed about the problem, and they also recommended what could be right, we are doing it. And we also discussed among ourselves. So one thing which was very clear that there was a little doubt about the sincerity of leadership. And so, we felt that any organization where leader was very proactive, like, for example, what is the basic reason, if I have a problem, if I talk about it, I am always worried what will happen when I disclose it? And is it the right issue to talk about it? So, these are the questions would inhibit a lot of people not to talk about it at all. So, that's where the proactive leadership can help people to overcome their inhibition and talk about it, and unless they discuss about it, you'll never know if there's a problem. So, that's the one thing. So, that's the approach.So there are a couple things that we could also recommend, is proactive leadership to start with, and something which can be done is there are a lot of tools available for the managers, yeah? People leaders, I would call it. Things like coaching, so you have a grow model where you can coach an individual person, even as a manager or as an independent coach, then having a facilitation techniques. When I started my career, they were not a training on facilitation, just going to the room and conduct the meeting. But they're very nice tools, facilitation techniques, which can be brought out to get people to participate, and so things like that can be very useful for being proactive and drawing people out of their inhibition. That definitely is with the leader. That's why we call it servant leadership. It is their job to initiate and take the lead, and get people out of their shell.
Terlya Hunt:
It ties quite nicely into the next question I had in mind. You both actually today have mentioned a lot of challenging beliefs, and calling things out. We need to build this awareness, and create safe spaces, and create psychological safety in our teams. What are some examples of how we can create safe spaces for these conversations?
Rakesh Singh:
The examples of someone creating safe places is ... I would say that educating people and the leaders. What I have seen is that if the leadership team recognizes that and educates the managers and other people ... You need to actually train people at different level, and create an environment that everybody's participating in the decision making, and they're free to make choices within, of course, the constraint of the business.
The focus, where I would put it, is that there are many educational programs and people would like to educated, because I normally felt that I was never trained for being a good leader. There was never training available. But these days we find that a lot of educational programs highlighting a various issue, like microaggression, unconscious bias, psychological safety. People should understand it. Things like being empathetic. These terminologies are there, but I find that people don't really appreciate it and understand it to the extent that they need to do, even though they are in a leadership position.
Caitlin Mackie:Thanks for sharing, Rakesh. I really love what you mentioned around proactive leadership, there. Your research found that 47% of respondents believed organizations who achieved this unity of Agile, and diversity, and equity, and inclusion will reap the benefits and exceed competitors. Jazmin, what did these organizations do differently?
Jazmin Chamizo:
Yes. That's a great question. Actually this ties very nicely with idea of servant leadership, inclusive leadership, and how leaders have this incredible challenge of creating workspaces that are psychologically safe, as Rakesh just mentioned. This is really everybody's responsibility, but it has a lot to do with a very strong leadership.
We found that several other organizations that we interviewed, they had a very strong leadership team, that they were really committed with diversity, equity, and inclusion in their agile transformation, and they were able to put DEI at the very core of the organization. That's number one, having a very strong leadership team that's actually committed to diversity, equity, and inclusion, and that does not perceive DEI efforts as isolated actions or initiatives.
This is something that we're seeing a lot nowadays. As a DEI coach and consultant, sometimes you see, unfortunately, several organizations that only try very isolated and very ... They don't have long-term strategy. What we have seen that actually works is having this committed leadership team that has been able to put DEI at the very core of their strategy.
Also a team that has been able to serve as an advocate in diversity, equity, and inclusion, and agility, and they're able to have advocates throughout the organization. It's not just one person's job. This calls for the effort of the whole organization and individuals to commit to DEI and be actively part of the agile transformation.
Also, I would say, leaders that embrace mistakes and embrace errors throughout the process. This is something that came up a lot during our conversations with people in different organizations, that in many cultures and in many organizations, mistakes are punished. They're not perceived as a source of opportunity.
One of the tips or best practices would be having leaders who are able to show the rest of their organization that mistakes are actually learning opportunities, that you can try things out of the box, and you can be more innovative. That even if you fail, you're not going to be punished, or there won't be any consequences because of that, and, quite on the country, that this is actually a learning opportunity that we can all thrive on.
Caitlin Mackie:
Yeah. I completely agree. What benefits did they see?
Jazmin Chamizo:
They definitely saw a greater working environment. This is something that was quoted a lot during our interviews with respondents, that individuals saw that they had the chance to try new and innovative ideas. Definitely greater innovation, more creativity. Business morale actually ultimately went up, because they saw that the organization was actually embracing different perspectives, even if they fail. This definitely called for greater innovation.
I would say innovation, more creativity, and a better working environment. Absolutely new products, new ideas. That if you think about the current circumstances with COVID, this is what organizations have to aim at. New products, more innovation to face all the challenges that we have nowadays.
Terlya Hunt:
Powerful things for the listeners to think about. Here at Easy Agile, our mission is to help teams be agile. Because we believe for too long the focus has been on doing, when the reality is that Agile is a constant journey of becoming.
There's a specific part in the report that really stood out to me that I'd like to read. "Agility is a journey with no fixed endpoint. The road towards creating diverse, equitable, and inclusive environments is the same. Agility and DEI can be pursued, but never fully achieved. They are a process of ongoing learning, reflection, and improvement. A team cannot enter the process of improving business agility or DEI with a mindset towards completion, and any model that unites Agile and DEI will ultimately be ineffective if those taking part are not ready to embark on an ongoing quest for self improvement."
I absolutely love this quote. Rakesh, let's explore this a little bit further. What more can you tell me about this?
Rakesh Singh:
Actually there's an interesting thing that I would like to share to start with. We wanted to look for a organization who would help us interview their people and talk to their people. The way organizations responded ... Some responded, "Shall I allow my people to talk to somebody? It could be a problem." But then we got other organizations, they were actually chasing us. "We would like to be part of this, and we would like to get our people interviewed." They were very positive about the whole thing.
I happened to talk to the DEI corporate manager, a lady, and the way she was talking was ... She was so much, I would say, passionate about the whole thing, even though at least I felt that they were very high level of awareness of DEI. But the quest for learning and finding out what they could do better was quite astonishing and quite positive.
That's where my answer is, is that ... If you look at the current pandemic, and people realized that, "Okay. We have to work from home," initially some people found it great. It's a great thing. Work-life balance. "I can attend my home." But after some time they found it's a problem. There's other problem.
The point is that, in any organization, where it's a business or a social life, or people, it just keeps changing. There's no method or policy which is going to be forever valid. There's a continuous learning process that we have to get in.
What we need to do is focus on our goal that we want to achieve. Depending on the environment, that's what we call business agility. Now bring it to people as well, because it is a people ... We talk about customer centricity, and all that. But finding it's the people who are going to deliver whatever organization want to. You have to see how their lives are getting impacted.
We are discussing about getting people back to office. The problem is that, a city like Bangalore, it's a very costly city and very clouded city. People have gone to their hometown and they can work from there. Now, to bring them back, you have to approve them back again. To cut short the explanation, our life is changing, constantly changing, and technology and everything is putting ... People have to look at methods and approach of how they can be adapting themself on a continuous basis.Learning is a continuous process. In fact, when I got into Agile and people ask me, "How many years of experience you have?" I generally say five years, because anything that I did before five years is actually the wrong practice. You have to be continuously learning, and DEI and Agile is no stranger to this situation.
Caitlin Mackie:
I love that. I think fostering that continuous learning environment is really key. I suppose, on that, a few of the recommendations from the report are centered around getting deeper training and intentional expertise. Jazmin, what further recommendations, or courses, or practitioners are there that people can engage with after this episode?
Jazmin Chamizo:
Sure. An important part of our report was a series of recommendations to the entire agile community, and practitioners, to organizations, and agile coaches. You can see that. You could get more specific information in our reports. I would like to encourage all of you to read. Definitely when it comes to agile coaches and consultants, we're encouraging people to learn more about diversity, equity, and inclusion because one of the insights and the learnings we drew from this research is that diversity, equity, and inclusion is not specifically included in the agile world.
When we talked to the respondents in many different countries, they did not spontaneously made the connection between agility, Agile, and diversity, equity, and inclusion. But the more we talk about it, they discovered that, indeed, they were very closely overlapped. There was a symbiotic relationship between them, because you're putting the person and everything that relates to that individual on the very core of the organization, on the transformation.
Definitely we do encourage ... Leaders and agile coaches need to start learning more about our DEI, building that proficiency, learning more about unconscious bias and the impact of unconscious bias, and discrimination, and racism that we'll continue to see in organizations. They're more mindful of those voices that are not being heard at the moment in the present conversations. They can learn different techniques or different methods to be more engaging and more inclusive.
When it comes to the agile community in general and influencers, it is important to mention that Evan Leybourn, the founder of the Agility Institute, is having at the moment some conversations with important institutions in the agile community, such as the Agile Alliance, because we are looking for ... That's what Gen Z-ers are looking for. There's a big call out there for organizations to embrace this type of transformation, but putting DEI at the very core of the organization. That's what I would like to say.
Contribute to the discussion. This is a pilot project. That we are hoping to conduct more research on other DEI areas related to agility. We would like listeners to be part of the conversation, and to contribute with their experience, to improve the state of agility in the current moment.
Caitlin Mackie:
Thank you both so much for joining us today. Thoroughly enjoyed our conversation. I can't wait to see how Agile and diversity, and equity, and inclusion evolves in the future. Thank you.
Jazmin Chamizo:
Thank you so much for having us. It's been a pleasure.
Rakesh Singh:
Thanks a lot to both of you. It was nice to share our experience. Thank you very much.
- Podcast
Easy Agile Podcast Ep.18 Top qualities of an agile leader and team
"It was great to chat with Alana and learn from her experience" - Sean Blake
In this episode, I was joined by Alana Mai Mitchell. Alana is a results coach, author, podcast host, and Senior Product Development Manager at one of Australia's largest banks where she works with Agile teams every day.
She has over 13 years experience in digital financial services and coaching. She's spoken live on Channel 10 here in the Australian media and has had her mental health story featured in publications, like The Daily Mail and Mamma Mia. She's the author of a book, Being Brave, and she's the host of the Eastern Influenced Corporate Leader Podcast.
We covered a lot of ground in today's episode. We talked about:- The importance of putting your hand up and telling your manager when you want to be challenged more and to be exposed to new opportunities.
- Building trust with your team and disclosing some vulnerabilities about yourself.
- Alana's mental health journey over the course of six years, and that journey continues today. What she's learned and what we can learn from her experience to better look after our teams and people in our community.
- Servant leadership and being a generous leader.
- The importance of authenticity and direct communication.
I hope you enjoyed today's episode as much as I did.
Transcript
Sean Blake:
Hello, welcome to the Easy Agile Podcast. My name's Sean Blake and I'll be your host today. Today, we have a really interesting guest and a fantastic episode ahead for you. Our guest today is Alana Mai Mitchell. Alana is a results coach, author, podcast host, and Senior Product Development Manager at one of Australia's largest banks where she works with Agile teams every day. She has over 13 years experience in digital financial services and coaching. She's spoken live on Channel 10 here in the Australian media and has had her mental health story featured in publications, like The Daily Mail and Mamma Mia. She's the author of a book, Being Brave, and she's the host of the Eastern Influenced Corporate Leader Podcast.
Sean Blake:
We covered a lot of ground in today's episode. We talked about communication styles. We talked about the importance of putting your hand up and telling your manager when you want to be challenged more and to be exposed to new opportunities. We talked about the importance of building trust with your team and disclosing some vulnerabilities about yourself. We covered Alana's mental health journey over the course of six years, and that journey continues today. What she's learned and what we can learn from her experience to better look after our teams and people in our community. We talked about going first in servant leadership and being a generous leader. The importance of authenticity and direct communication. I hope you enjoyed today's episode as much as I did. Let's get started. Alana, thanks so much for joining us on the Easy Agile Podcast today. It's great to have you here.
Alana Mai Mitchell:
Thanks so much, Sean.
Sean Blake:
Before we jump into our conversation, Alana, I'm just going to do an acknowledgement to country. We'd like to acknowledge the traditional custodians of the land from which we're recording today, the Watiwati people of the Tharawal speaking nation, and pay our respects to elders past, present and emerging. We extend that same respect to all Aboriginal and Torres Strait Island peoples who are tuning in today.
Sean Blake:
Well, Alana, there's so much to talk about today. The background is, we used to be colleagues in the financial services industry. We bumped into each other again out of the blue at Agile Australia '21 Conference, just at the end of last year, which was a great conference. We thought we'd have you on the podcast because you've got so many different stories to tell, but I thought maybe we could start this episode by talking about your career journey and how working with Agile Teams has weaved into your career trajectory.
Alana Mai Mitchell:
Yeah, sure. Agile really came into the forefront right back in 2013. I always remember my first Agile training. We had a team day, where I was working at the time. We had an external facilitator come in because the Agile framework was something totally new to financial services at that time. We played Lego. We had each of our wider team was divided into smaller teams, like scrum teams, all this new terminology. Then we were building island and we had an island each and the product owner was feeding user stories in from the customer. Partway through we were building, I think, a rocket launcher and then no, we didn't want to rocket launcher anymore.
Alana Mai Mitchell:
We wanted to tweak it. We had to adapt to things on the fly. I always remember that experience because it was so transformative, just having such a direct and collaborative way of working with people on a project. To this day, of all the Agile trainings and experiences that I've gone through, it's always the ones that are really interactive that I've remembered the most and gained the most and taught them, like learnt them myself as a participant and then taught them to other people as well.
Sean Blake:
Along the way, do you think, you've been through all these training sessions and you've been working with teams on the ground. What have you found from Agile, which is a big topic, but what have you found to be the most transformative and the most helpful from the way that these teams used to do things to the way that they do them now?
Alana Mai Mitchell:
I would say communication. What I found was, because I had the contrast with both, I've worked in Water Force style projects and Agile projects as well. I think the biggest part is the amount of effort and rigor that we would go through reviewing requirements and have those be delivered into technology. Then it go quiet and you not hear from technology until they come back with something and they're like, "I've got a baby." You're like, "What kind?" The difference with Agile is that you are able to co-create them.
Alana Mai Mitchell:
You're creating with your customer or your end user, if you're working with an internal user, and then you are also working with technology and finding out what kind of constraints technology has or what kind of ideas they have as well. You have that ability to communicate with the dev. Sometimes your devs are on-shore, often cases they're offshore. We're all remote now, so it doesn't make as much difference as it did when we were in the office. You can really just pull away a lot of the process that gets in between people and have conversations. That's what I really think is the most transformative part.
Sean Blake:
Great. Yeah, so that communication. Do you feel like the communication throughout COVID and working remotely has been more challenging? Are you one of those people that find those face-to-face communication skills, you really prefer the face-to-face or has remote been okay for you? Because I know some people have struggled. Some people have found it easier to be on Zoom all the time.
Alana Mai Mitchell:
Well, I mean, when I go in the office and we have that brief time where we were back in the office, I had a smile on my face the whole time. Because I just love seeing people and I'd go around and walk over to my team and say, "Hey, how are you going?" Just catch up with them. I think the one piece that's missing for me in the remote working whilst there's greater flexibility, you can do multiple things at the same time. You focus a lot of your work. You can get a lot more done quicker. I do find that informal relationship building, you need to actually schedule in time or pick up the phone out of the blue and connect with someone.
Alana Mai Mitchell:
Whereas in the office, I would just find that because people were there and I don't know, you might be having lunch at the same time or going downstairs for something at the same time or even the corridor conversations that happen after the meeting where you can just chase someone or ask someone a question or they chase you and you just get things done. It's just different. I'd say it's more, the catch ups are more scheduled and formal, I find in a remote work setting.
Sean Blake:
I feel the same way. I feel the small talk and the talk about the weekend on Zoom is much harder for me and much more tiring to try and sustain that than in person. It becomes more naturally. I really have to make a big effort, especially on one-to-ones with people in the team when I'm trying to check in on their health and wellbeing and how they're going at work. I just find that much more exhausting than what I do in person. I think it's just those nonverbal communication skills and you can see people's body language easier when you're in the office.
Sean Blake:
Someone's slumped at their chair for six hours out of a seven-hour work day. Then you're like, "Oh, something's wrong." If you know that you've got to get on Zoom and try and pretend to be happy and that everything's okay, then you can fake it a little bit easier. Of course, there's loads of benefits to remote work, as you say. That human element personally, I find it's much more challenging to replicate using digital tools. Maybe there'll be more innovation that comes, but the time will tell on that.
Alana Mai Mitchell:
Yeah. On that, I wanted to add some of my friends in the technology space. Talking about the metaverse and how at the moment you and I are having this conversation through screens. I'm in my space, in my house, and you can see my painting in the background and I can see that you've got a podcast set up. One of my friends was talking about how, he's an architect, and so he was thinking about how we create digital spaces. When we meet digitally, if we were meeting as our avatar, what kind of space would facilitate better conversation? That blew my mind when he was talking about that. I was like, "Oh, I hadn't even thought of that." Absolutely, you could meet in a virtual space because we're doing what we've got with the tools that we have today, but the tools can change.
Sean Blake:
I guess it's almost certain they will change. I can't see that Zoom will be the market leader forever. I'm sure there'll be things that come along very soon that will try and replicate some of those physical experiences that we miss so much of being in the office and having those social experiences together. Alana, I'm wondering about the teams that you work with now or in the past, those Agile teams, do you have any tips for people who are new to Agile teams or maybe they're coming in?
Sean Blake:
They want to improve their communication, whether they're remote or in office, and improve their organization's Agile maturity, but they're just finding it a bit of a struggle. Do you have any tips for people who are just, they're butting their heads up against the wall and they can't seem to make progress with some of those patterns and habits that you talked about, like taking requirements away and not knowing what's happening for so many months or years before you hear something back from technology? How do you actually start to influence that culture and behavior, if you're new to Agile?
Alana Mai Mitchell:
I'm going to take a slightly different approach on that to answer your question. Because the thing that came to mind for me was when I in Outward Bound, which is a remote wilderness organization in 2012 in the US. I was instructing there. One of the frameworks that they use is William Glass' Choice Theory. Choice Theory talks about that we have five needs, and I'll put myself on the spot. Well, I'll mention some of them, because I can't remember all of them. There's like need for fun. Some people have a high fun need. Then there's like need for power, like feeling powerful. There's like, love and belonging, is another important need. There's two others, which I can't recall right now. I think when you are coming out of a situation, from a perspective, you've tried a couple of times when you're approaching it, and not getting anywhere, I would have a look at what needs am I, myself looking to get met out of this communication.
Alana Mai Mitchell:
Then on the flip-side, what needs is my communication partner or the team that I'm working with? What is the most important need for them? As we were talking about remote working, like the fun need. People love to have fun and you can actually have fun at work. It doesn't need to be separate. Thinking about like, if you have a high fun need, and you also notice your team has that as well. How can you address that in your communication style or bring out some kind of activities that can bring that to life? I would always go back to what are my needs and what are the needs of other people that I'm working with? Because when you're working with different teams, they have different agendas, they have different goals. If you can figure out what you have in common, it's a lot easier to bring another team or people in those team on the journey, once you figured out what the common ground is.
Sean Blake:
That's great advice. Think about it from their point of view, rather than just what you need and your own agenda and try and adapt to your approach to them. That's really good. I saw this quote recently, Alana, which reminded me a little bit about your mental health journey, which we'll talk about more in a moment. The quote was about, when you're looking for a new role or a new job, you shouldn't just look for a great company to work for. You should look for a great manager to work for, because the influence and your experience as an employee, working for a manager, is often so much more important than and influential than just picking a great or a well-known company to work for. Have you found that to be true in your own career?
Alana Mai Mitchell:
Oh, yeah. I have found that some really phenomenal leaders. In a previous organization that I was working in, I like to keep learning and growing all the time. In previous roles, sometimes I get bored. It happens. That's really valuable to organizations because I'm constantly looking at where to improve things. I had a time where my manager was focused on other things and learning and development wasn't as important. Then I had a lady named Christina come in and Christina was like fire. She was just, "This is what we got to do." Open to change, really clear communicator, she's from the US. She's really direct in a compassionate way and she's really progressive as well. I found because of her influence in the organization.
Alana Mai Mitchell:
Also, through my willingness to put my hand up and say, "I'm willing to participate." Which is, for the people who are tuning in, it's not just about the leader creating the opportunities for you and saying, "Hey, present to this general manager forum or executive general manager forum." Or whatever it is. It's also about you saying, "Hey, I'm willing and I'd love to." And communicating what you are after. We met on that path and I had some of the most, stronger success working with Christina. I was fortunate at that the culture was also really great. The immediate team culture needed to shift as well, which is part of why Christina came on board, and the company culture is really good.
Alana Mai Mitchell:
I would say on the point on like manager over culture is that when you are someone who is progressive and you're wanting to shape the culture for the better, you're going to find cultures that need a little attention or need a little work or things that aren't quite as performing as well as they are. With the sales perspective, opportunity plus. If you go to a culture and everything's amazing, you're sure you can make it a little bit more amazing. Really, when you have the support of your manager, who's, you see these initiatives and they're going to say, "Okay, go for it. I've got this GM forum coming up that you can present at, or let's find your sponsor. Let's find your mentor." That the two of you working as a team can be at the forefront of the new culture, which impacts the rest of the culture.
Sean Blake:
Interesting. I don't know if I've ever been in a culture that's perfect and overachieving and too good, but absolutely you can get too comfortable and complacent in roles and you can almost just be a little bit shy from putting your hand up for those opportunities. Do you think there's many cultures out there that are too good? How do you assess the quality of a culture before you accept the role and start working in that team?
Alana Mai Mitchell:
Oh, good question. I always asked, what's the vision and how does it relate to this role? I want to hear it from the hiring manager before I join a company. What I'm looking for is I'm asking that question to multiple people. I'm looking for a congruence, about the hiring manager sees a similar story as to what their peer, who's maybe interviewing in the second interview or their leader in the third interview. I'm looking for those things to match up, because that's telling me there's consistency. It's just, I'm getting the same story. That they're also communicating well. That would be a sign to me. Yeah, that's about what I do.
Sean Blake:
That's good. Good tip. Alana, you have a quote on your website, which talks about your mental health journey. It says, "I have totally recovered from five mental health breakdowns across six years, where doctors once talk would me, I would be homeless." That sounds like a lot of hardship and a lot of sweat and tears and pain over many years. Do you want to walk us through a little bit of that journey and what you've learned about yourself through those experiences?
Alana Mai Mitchell:
Oh, yeah. Thanks for pulling that out from the site, Sean. In 2013, I started to notice that things weren't right. I wasn't feeling myself. I sought help from a counselor, career counselor. Because I thought, "Is it my career?" I said, "Am I not in the right job?" I spoke to a psychiatrist and a psychologist and they did a little bit of an investigation, but no one really got to what was going on. Then I made some quick decisions in my career, which I look back on and I think, "Wow, I really was in the throes of it and not thinking clearly at all when I made those choices." I found myself, about November 2014, in between roles. As someone who was previously really ambitious, like high-achiever, chronic high-achiever without having a role and a career prospect at the moment back then was a big deal.
Alana Mai Mitchell:
I had what was called a psychotic episode. Essentially, that was like me, believing deluded thoughts and not having a really strong grip on reality, having some story going on in my head that wasn't true at all. It ended up because I was taken by ambulance to hospital. Then still at that point, people didn't really know what was going on. I was a in mental health ward and came out from that, started on medication, which improved things. I thought, and this is part of why I had the multiple psychotic episodes, is that I thought that the stress of being in between jobs or stressful situations at work, I thought they were the triggers for the psychotic episodes.
Alana Mai Mitchell:
I would take the medication for a while, get better temporarily, think everything was normal, stop the medication. Then six months later I would have another breakdown. Then that happened over six years and I realized towards the fifth and final, so that was when I was running a coaching business that had a few clients at the start and then we didn't have any clients at all. I essentially ran out of money and got into debt. Then when the doctor learned about my financial situation, he said, "You're going to be homeless." I was so offended. I was like, "How dare you." I was like, "No, I will not. I will not." I look back now and I'm so thankful for him sharing that with me, because he provided me with a choice. Something to push against and choose another way. He activated my will, from me going from being offended to being thankful, where I'm at today.
Alana Mai Mitchell:
I charted my way out of that. Now, I have well-managed schizophrenia and I take medication. I'll be taking medication for the rest of my life. It's part of who I am. I don't experience like, some people have a lot of appreciation for, because I know that they're in their mental health journey. It's not all smooth sailing, even after they have an answer of a diagnosis. It still can be challenging in there's up days and down days. For me, I'm consistent. It's been now coming up to four years since the doctor and I had that conversation in the hospital. Life is just incredible since then.
Sean Blake:
That's great. I'm so happy to hear that. Thank you for sharing your story with our audience. I think it's really important, isn't it? To be vulnerable and to share the truth about things that have happened in the past. Do you think that there's something that we can learn? With the people that you work with now, do you have a clearer understanding or are you looking for signs of people in your life who might be struggling with some of the similar issues and what can we do as people in our own communities and working with teams to look out for each other and to better support each other with some of these mental health issues front of mind so that we can be more supportive?
Alana Mai Mitchell:
I always listen for and check in with how the team is doing and it's not just, you ask how are you, and you're listening for more than what they say. If they say they're good, how are they saying it? We had that conversation before about the remote working and it's different. To come to the, are you okay, and we have the, are you okay days. Someone asked me in the office where we were actually working together. They're like, "Are you okay, Alana?" I couldn't answer her. It's not always as simple as getting a no, sometimes it's, you don't get a response. Then the alarm does go off. I really think taking in all the points of interaction that you have with someone and aligning to, is that consistent with how do they were, is there something different, check in with them, how is it going? If you're having a conversation, great. If they're sharing with you, even better.
Alana Mai Mitchell:
If they're not, you can always just check in with yourself and being like, "Is it something you need?" As to, why are they not sharing or is that something that's going on with them as well? The other piece I wanted to tie it, bring it back to the Agile leadership piece and from the conference that Agile Australia that we were at. I really see that building trust with teams is so key. We're in this remote working environment or hybrid working environment, depending on what office you're in. It really is important to build trust with your team. One of the quickest ways you can do that is by sharing vulnerably with what you have to share. I don't mean going for exposure and putting yourself in vulnerable situations where you are uncomfortable with what you share.
Alana Mai Mitchell:
It's disclosure, so it's something that you're 100% comfortable within yourself, and you've accepted it within yourself and you share that with your team in openness. When you do that, you see that your team also, they hear it and they mirror it as well. You go first and they share. The mental health example, I shared that on LinkedIn. I've shared it in situations with my team. Then I've been invited to talks and I've had people approach me. It really builds without having to go through a lot of, I ask this thing of this person, do they deliver it above and beyond expectations when I ask for it? How many times do you need to go through that process before you trust someone versus you, coming out and creating an environment of trust through of vulnerability? I do caveat that it's like not oversharing, it's sharing what you're comfortable with at that point in time, and that might change as you go on.
Sean Blake:
Interesting. Does this apply to leaders as well? I know that you've spoken about being a generous leader in the past, and that reminds me of servant leadership, which is another kind of Agile phrase that you hear come up quite a lot. This idea of going first, disclosing what you're comfortable with to your team, even as a leader, showing vulnerability is really important. I know in my experience, if you can share some of the honest and harsh realities of what it's like to be in your position, then your team are more empathetic with the challenges that you have.
Sean Blake:Because a lot of people assume that when you are in a position of leadership and responsibility, then things are easier because you can just delegate or you've got budget to solve some of these problems, but it's not actually the reality of it. The reality of it is you struggle with things just like anyone else. By sharing and disclosing things with people at all levels of the organization, then that helps to build empathy and a bit more care and support no matter what level you're at. Are there other things or habits or qualities of a generous leader or a servant leader that you've seen or that you try and model or encourage?
Alana Mai Mitchell:
The big one that stands out for me is authenticity. Really knowing yourself, knowing what your leadership style is, knowing what your challenges are, what your strengths are, what you're working on and being authentic about that. When you feel something, sharing what you feel, not having to feel like you need to say it a different way or sugarcoat it, being able to speak your mind in a way that's direct and compassionate. We're not going for like arrogance, and we're not going for wishy washy. We're going for direct and compassionate, then share what's in your heart, so authenticity. Those are the leaders that you, I'm so glad you brought up empathy because when you're vulnerable, empathetic, and authentic, those are the leaders that really stand out for you and me.
Sean Blake:
That's great advice. Authenticity, direct communication, build empathy. All right, thanks for sharing that.
Alana Mai Mitchell:
You're welcome.
Sean Blake:
Alana, how did you decide that you wanted to write a book about some of your experiences and can you tell us about how your book, Being Brave, has changed your life and how you think about sharing your story?
Alana Mai Mitchell:
I naturally have a lot of things going on. I love projects. I love it, that's why I'm in projects. Because I love setting a goal and reaching it. The company I was working at had done a number of workshops and I got to a point where I didn't have as many activities going on. I was like, "Oh, that's really interesting. I don't have as much stuff going on." This was just at the start of the pandemic in 2020. A friend, a really dear friend of mine said, "Try meditation. Try meditation daily." I meditated each day and I had been surrounded, my network is very much of a coaching network. I know a lot of coaches and they had written their own books as well. I was on the radar and I was meditating and I got the idea to write a personal memoir about my story.
Alana Mai Mitchell:
It's really interesting that even in through that process of doing a lot of personal development work and going through the process of writing the story, there were still some things in that, that I wasn't quite comfortable owning yet. It's been, since I wrote the book that I've accepted that. In a book, if people read it, I talk about psychotic episodes. I don't talk about schizophrenia because it was all later when I was asked to do a media thing about schizophrenia, that I was like, "Okay, yep. Time to own that." I feel like the book at a point in time had me accept all that had happened with unconditional love and then to still, modeling that piece of going for disclosure and not exposure. Still, I had my fragility on what I wasn't ready to disclose yet. Since then, that had progressed further.
Sean Blake:
That's awesome. That therapy you're sitting down to write the story actually helped flesh out the story itself and you came to terms with some of those things that happened. What has been the reception to the book?
Alana Mai Mitchell:
Most people, when they pick up the book, it's a short book, so some people even call it a booklet, because it's 11,000 words. It's short. They say, "Wow, I read that in an hour and a half, in one sitting. I couldn't put it down." someone had said, "It's the story of the famous rising from the ashes." They can take a lot of inspiration from it. The point of the book and a lot of what we're talking about vulnerability is going first as the leader. You set an example that others can follow in, so that will flow into their lives as well. The book is set out with a story and a few questions at the end that people can go through for their own insight.
Sean Blake:
Great, awesome. Alana, is there anything else you'd like to share with our audience before we start wrapping up the episode today?
Alana Mai Mitchell:
I did, because I know this is about Agile more so, and that's a really important topic to your audience. I did write and have a think about after that conference we went to, Agile Australia, about what is beyond the Spotify model? Because the Spotify model is very, word is spoken about it at the moment with the crews and the tribes and squads of course, and the chapter lead models and all that they have, which I'm sure everyone tuned in would be really familiar with. I started to think about, what are the things that are relevant beyond the Spotify model? What's next? If your organization is at a point where you've already at your job at some of that, and you're looking for what's next. I did write an article about that. It's on LinkedIn, and I'll give it to you. If you want to, you can put it in the show notes.
Sean Blake:
That's awesome. We will definitely do that. Where can people go to find out more about you? Where can they buy your book or visit your website?
Alana Mai Mitchell:
My site is www.alanamaimitchell.com. On there is more about my story. There's a few things about coaching, which may be relevant. I'm not coaching at the moment, I'm more focused on my career in financial services. Then the book is on Amazon and it's in English and also in Spanish. There's the audio book and also the print book and the eBook.
Sean Blake:Awesome. Well, Alana, thanks for disclosing what you've disclosed today and sharing your story with us. I've learned a lot about your experiences, and I've got a lot to think about, to reflect on, how to be a more generous leader. Thanks for spending time with us and being part of the Easy Agile Podcast.
Alana Mai Mitchell:
You're so welcome. Thanks for having me on the show, Sean.
Sean Blake:
Thanks, Alana.
- Podcast
Easy 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.



