Connecting permaculture and documentation with Liz Argall

Kate 0:04
Welcome to The Not-Boring Tech Writer, a podcast sponsored by KnowledgeOwl. Together, we explore topics and hear from other writers to help inspire us, deepen our skills, and foster our distinctly not-boring tech writing community. Hello, my lovely, not-boring tech writers. This month, we kind of have a little change up. Normally, this would be a solo episode, but in a nod to Write the Docs as well as some personal stuff I have going on, we decided we'd do a bonus interview episode instead of a solo episode, and maybe I'll be really productive before the next solo episode, so you won't know how unproductive I've been in the last month. So with that in mind, welcome to another interview episode. This month's guest is definitely a Write the Docs special. I had never met her before Write the Docs. And lo and behold, we ended up giving a lightning talk in the same lightning talk session, and that led to us kind of connecting socially during the event, which is a very Write the Docs thing, and as a result, she's here on the pod, because I think she's an amazing human being, and she's had a really interesting array of work experience, and we have a shared love for spreadsheets and matrices. So without further ado, I would like to welcome you to the pod, Liz Argall. Liz, welcome to the show.

Liz 1:22
Thank you so much for having me. And I should say, as we discussed before, I'm a big permaculture fan as well. And you know, you gotta follow the seasons, and having a little bit of fallow resting the soil is not unproductive. It's listening to your body and building capacity for other kinds of productivity.

Kate 1:40
So Liz, can you tell me a bit about your tech writer villain origin story? How did you end up getting into this field in the first place?

Liz 1:50
When I was seven years old, there were some contractors working on our house, an extension on our house, and I was fascinated with them. And my dad noticed that I was fascinated, and he said, “You should go interview them and write about it,” because that's the sort of dad I had. In my little notebook I interviewed them about, you know, putting in flooring and stuff like that, and what it was like. And I wrote it down. And because I went and wrote it down, you know, then suddenly we had more of a relationship. I got an expert showing me how to hold the hammer properly and how to use it, and the perfect way to hammer in a nail, and the deeply satisfying thing of getting it in in a certain amount of strikes, and then striking and getting it all the way down, and how he could hit it in such a way that it even went down below the wood. So I wrote my little article about what they were doing and how they were doing it. And, you know, how to strike a nail.

Kate 2:58
It's funny how, when you show an interest in somebody's area of expertise, and the thing that they spend all their time on, they will open up layers and layers to it that you never knew existed. And then the beauty of being a technical writer is that you get to translate that and try to carry some of that out into language that non experts will understand to deepen their knowledge, right? That's such a beautiful way to describe what we do.

Liz 3:24
And they can open up and make their implicit understandings explicit. Like, sometimes they might not even know how much they know, or just by being asked questions, they're like, ‘oh yeah’. Then they might even get deeper into their practice as they have someone to just talk through things with.

Kate 3:46
It's almost like you facilitate the shift from being what I've heard called being unconsciously competent to being consciously competent, where you have that heightened level of awareness of just how much you actually do know, and the level of competence or expertise you have, and sometimes you don't realize that until you're talking to someone else and explaining something, they ask a question that you've never explicitly asked, you just implicitly understood, and to be able to explicitly explain and then recognize that as explicit knowledge that you have gained, is super validating. That's fantastic.

Liz 4:21
It says something about my family that when I was pre teen, I was somewhere between 10 and 12, I wrote a short story that I showed to my dad, and he said, you put an agenda committee meeting in a story with an agenda and minutes. And I went, what's an agenda in minutes? And he said, ‘this bit’. I thought, that's what families do.

You were circling back to what you said earlier. I think one of the other things is that sometimes subject matter experts will have secret shames, especially like programmers, they'll be like, this bit of code is not so good, or this bit of that. I had a very recent experience where I found out that the reason why they were reluctant to document was because there were some bits of it that weren't so mature and it wasn't up to their standard. And being able to take them through the process of putting it in a framework, we understand this is a prototype, it's okay that it's a prototype, and, it's useful to make explicit; that it has this dependency on this weird thing that's over here, and blah, blah, blah. If we just make that explicit, people can understand that. People might be like, Okay, well, how can we support you to make this better? Or, okay, let's not change this random file. It has this dependency. And just like seeing the weight come off people from. oh, I can't document because it will expose my secret shame, to, oh, well, I can be like, this is what I'm doing, this is what I've been able to achieve in the time that's given. These are the strengths. These are the dependencies, you know, and being able, it's not a secret shame. It's a dependency. It's a work in progress. It's making explicit what we have now, and then they can hold their heads up with pride and maybe get more support, or have other people be like, You know what? That's good enough, get the job done. That's one of the beautiful things about having good frameworks and supportive structures, to help us see each other more clearly.

Kate 5:54
Also just a concept that translates well under the writing side of it as well. A number of times, when I've talked to somebody about their documentation, and the first place they go is telling me everything that's wrong with it. Or, that ‘I haven't updated that in forever’. My solo episodes are a tour de force in this, right y'all? But there is this sense of, oh, I can't present that to the world because it's not perfect. And normalizing that as not being a thing you have to be ashamed of. But this is part of the process we all go through. If you just kind of own it and recognize that and are above board on it, people can appreciate all the wonderful things. And maybe the thing that you think you should be ashamed of here secretly is not actually a thing worthy of shame. It's just: this is what happened in version 1.0, and that's what it is. And you know? By the time you get to 2.0, it'll be way different. And then you will have a different secret shame, and it will just evolve over time as your work evolves over time. It's part of the human condition, right?

Kate 6:46
Yeah. And it could be that some of your secret shames are actually showing great versatility and strength. You’re like, Oh, I couldn't get it to work. So I had to borrow from this library and this and I had to cobalt together all these things. And to you, it's a shame, and then someone else looks at it and they're like, ‘Wow. That's amazing’. You had to do all of these arcane things to get this dashboard. No wonder. We're giving you a hard time because it's like a dashboard. Why don't you just update the dashboard, and then you know what's where because there are these things that aren't in place. So I had to do all of this arcane stuff-

Kate 8:35
And a bunch of things, to get the end product that you see. Am I happy with it? No, but it's much better than not having anything at all. And sometimes you undersell your own ability to hack those various things to get the thing that you want right? I love this as a concept.

So Liz, I'm using the word tech writer. It is in our podcast title, obviously. Is that the label that you most like? Or do you prefer something maybe more esoteric or more general?

Liz 9:05
So technical writer is a term, as you can hear. I've been into the concept of documentation for a long time, and the empowering nature of documentation. I get confused when they say, how many years of technical writing have you done? And I have to think, where do I draw the line? Where do I count my writing as technical enough; when I was writing SOPs for my first jobs and all these sorts of things. I've had these challenges in some jobs in the last decade where I've been doing work, and people have been like, oh, well, that's not a technical writer thing. And so I realized that part of it is this internalized oppression. To a degree, I am passionate about creating spaces where people, if there is ever the label ‘technical therapist’, I'm really trying to sink into. Yes, I am a technical writer, but your understanding of what a technical writer is is limited. Let's expand our understanding of what a technical writer is. One of the amazing things that happened to me the end of last year and this year is I went through a whole bunch of interviews processes with canonical and I didn't get the job, but it was this alchemical healing process to be seen in that way, to go through a process where I got to say, This is my story to be heard, and that a person like me could be heard, that a person like me could have a chance at a job like canonical. When I don't have an IT degree, I haven't gone through the standard pathways. So people have said, Oh, you're not a technical writer. They said, “you're not a technical writer, you're a program manager, you're an operations manager”. I went immediately from that experience to Write the Docs. I got to be surrounded by wonderful documentarians. And I was like, what we do is beautiful. Our curiosity is beautiful.

Kate 11:03
The problem is that there's a problem with the definition of what a technical writer is. You can be a technical writer even if your job role and or description doesn't mention technical writing. A lot of support agents are technical writers. A lot of product managers are technical writers. There's a bunch of devs who do technical writing as they're documenting the stuff they're working on. Arguably, people who write cookbooks or instructions on things are all technical writers. So like for me, I had to get to the place of redefining what I thought the label meant, so that it was much more of a spectrum, and recognizing that I fit somewhere on that spectrum, and that a lot of my work experience fits somewhere on that spectrum, but it wasn't always in the exact same place. I think we're aligned in that feeling of, Yes, I'm happy to identify as a technical writer. But my definition of what a technical writer is might include a whole lot of operations or process development that maybe to someone else falls outside the bounds of what a technical writer is. And we can both exist and call ourselves technical writers, and that's fine, and should, frankly. People should embrace the idea that technical writers do more than just write documentation on a thing.

Liz 12:30
Yeah, and especially when we are so intimately involved with (writing) as a technical writer, we are well opinionated about how awesome technical writers should be. We go through that user experience that we're listening intensely to them, and then we listen to the developer of the subject matter expert experience, and we can have those moments of having them open like a flower.

Kate 12:58
So we've touched on this a little bit, Liz, but can you tell me about your experience in the field overall and kind of what you're working on right now?

Liz 13:07
So, yeah, my experience in the field overall, I think in terms of really being able to formalize a bunch of my technical writing, I was working in for on mass entertainment, working on massive multiplayer online games with like terrors, over 10 years history, and it's interesting, they're dealing with 10 years of legacy content and working with people through that, and dealing with sometimes quite arcane rules of weapons leveling up and all that sort of stuff and crafting and transformations and stuff like that. That was actually a few years after that, I ended up working in computer perception, machine perception, augmented reality research project Aria. And it was interesting to see just how much you know in both your understanding of what the physics of this situation is, helping to make really complex things explicit. So it's been really interesting. I mentioned Project Aria. I really treasure that experience, because I got to come in just before we did our first ever open source release, and through to open source is the inevitable way to open sourcing some stuff that used to be behind a password, and really helping us scale our program, from a couple of university partnerships that were all very manually onboarded to creating documentation that really allowed us to expand our program, part of Project Aria, which I realize I've just been saying it as a word. So Project ARIA was a really wonderful alchemical process for me. Project Aria, it started as a physical device, but also as a whole program of activities around the ARIA device. The Aria device is a multi modal data capture device in glasses form factor, designed to accelerate augmented reality and machine perception research and AI research. So these glasses, they look like a normal pair of glasses, but extra heavy, and they have seven spatial microphones, an RGB fisheye lens camera. There are different shutters and types of things like how you capture visual images can have an impact on what you can do with it. So we have some cameras that are specialized for doing slam for slam calculations. So that's space localization and mapping, which is like when a robot is going through a space, it needs to understand where it is in space, and also have a map of its broader space, which will be important for augmented reality research. Now I'm possibly getting into the weeds. It's got slam cameras that are also used for hand tracking now, and accelerometers, Imus, all that sort of stuff. And this is a huge amount of data that it captures, and then you can upload it. It then allows people to look at this enormous amount of data and be like, how do we make sense of it? This is the sort of actual- we don't live in an Instagram world, like this is what cameras would actually be picking up. How can we manage the pure volume of the data? How can we streamline that data? How can we anonymize this data? Like putting people's faces and number plates and personal information is a liability that nobody wants. Well, not nobody wants, but you know that if you're going to make it a popular thing, one of the open source releases that Aria has done is for blurring faces and number plates, because especially with different kinds of cameras, the ability to blur varies when you consider if we've trained all our data on Instagram images, it knows how to blur Instagram images. It was this huge data collection activity, and, well, enabled a huge range of data collection activities, collecting data in the right way with the right consents in place, and then providing both the data sets to the academic community or open source community, as well as physical devices for universities and research partners to do their own research with. So we had a lot of different audience types, from from data collector users who might be like in their own home, just like doing recordings of themselves, washing the dishes or something like that, who might not even have access to a computer, to internal developers, tiny team trying to do a lot to our academic research partners, which I like to think of as sleep deprived PhD students who've suddenly been thrown sideways into a project, to when people say oh, they'll just figure it out. Very smart people can be very, very tired, can be under a lot of stress, can just only be able to handle what's right in front of them, and then write content that also works for regulators and things like that. We have research partners around the world. So the regulators in the EU are going to be happy with how this is being done. I got to have an incredible end to end experience with it. UI strings, it was training, it was providing updates to the facts to help make sure that we looked good to regulators. And, because I was touching all of these things, I could be like, Okay, well, this bit has changed, so we need to update this bit over here to writing talking points for people going to workshops and instructions for how to do things at booths.

Liz 14:06
So a really wide range of sort of content types, as well as a broad range of audience type to put the overlay Venn Diagram of eight different audiences, plus a bunch of different content types and contexts in which that information would be shared. It sounds challenging, but really interesting.

Liz 19:14
Oh, it was amazing. I got to learn how to build static websites with docusaurus on the fly. And get to know Python a little bit better. And from general user documentation to in the code, DOCSIS code going, Okay, well, this read, you know, even this read me, that's by a different team, but it's within our one ecosystem. Saying, here are ways that we can align these instructions to the other instructions, so that we have a shared vocabulary. And technical writers love untangling knotted bits of string.

Kate 19:58
Knotted bits of string content? Yes. We do!

Liz 20:00
I got to cultivate content champions, which is my favorite thing. That's what I think of all those people who care about content I'd be like, I got to take care of my content champions, and I got to take other people along there- they're engaging with documentation, activism pathways. Documentation is scary too, not so scary too. Actually, this is kind of interesting. I could be involved. There's people taking people on that pathway and also taking care of the people who've been these lone people that are like, I care about documenting those loan programmers that really care, but often get quite isolated, so building a community and a support and an acknowledgement of them, give them data around how they have made an impact, so that in their reporting they can say, Okay, I achieved these things and that effort can be counted. I treasure moments when I've had engineers say to me, ‘I don't know about this documentation, it seems like a big waste of time’. And then going through this process with them and being like, oh, this has saved me so much time, actually, you know, when people ask me questions about this new stuff, I just send them a link to the documentation, whereas historically, I would have had to, like, dig through code and this and that and the other and even if it's still them being the pathway to the content; Because often that's what people want to do. They want to ask the subject matter experts. They don't want to search for it. But if that subject matter expert can be like "and here's something I've prepared earlier".

Kate 21:47
Yes, I've distilled my expertise into this series of documents which you can explore at your leisure when needed, and it is not dependent on my availability. Often you do kind of encourage people to access that information and to internalize it in ways that if they just ask you every single time, they never get there themselves, because they don't have the full spectrum of your knowledge. They just have the piece that they thought to ask about at that time, and they can't follow the different pathways out of it to find other things that they might also have ancillary questions around, right?

Liz 22:28
And I think that is one of the real struggles of how we need to continue to find ways to tell the story of documentation and technical writing. Sometimes we get caught in other people's metrics and the things that are easy to measure, and so they'll be like, how good is this documentation? If it's only getting 20 clicks a month, or maybe less, or whatever. But if one of those clicks saves one process and if each of those clicks saves my engineer half an hour, that's huge, especially if they have to answer a five minute question, then it takes them 30 minutes to get back into their work. Or it takes them on a journey, and it wastes so much more of our time.

Kate 23:14
What were some of the metrics that you ended up coming to that you really liked in the end?

Liz 23:21
One I think, is just sowing metrics of the value that we do. One is just capturing the qualitative and, on my blog, I've got a thing about search term analysis, and I think just making it visible that when people search for this keyword, they get what they need, or they don't get what they need. So one of the metrics is actually just impact, and it can be especially, like hand, if it ties to a story. One of the things that gave me big fuel was a very senior person being like, I searched for ARIA calibration, and I couldn't find, you know, and I couldn't find what I wanted, like that, that use case there. You can hang out a lot of things off that. And so that is a single point of impact. And then you can tell the story of, okay, when we go to these things? And so you can have your own sort of, I guess, I'm not sure if user stories, but you can have different scenarios. For example, imagine a journalist is going through this. Imagine a regulator is going through this. So that's one thing that I think qualitative has value. But qualitative doesn't just mean feelings. You can be, you can like, be quite a spreadsheet with your qualitative analysis. And I think it's very important to connect to the larger mission and vision of your organization, if you're like, 'These are the things that we measure ourselves against as an organization. This is how it achieves these goals. This is how it improves.' You know, you can tie it back to very specific things.

Kate 25:00
This is a great note for us to pause and take a break on so we will take a break, and we will be back shortly.

Kate 25:07
This episode is sponsored by KnowledgeOwl, your team's next knowledge base solution. You don't have to be a technical wizard to use KnowledgeOwl. Our intuitive, robust features empower teammates of all feathers to spend more time on content and less time on administration. Learn more and sign up for a free 30-day trial at knowledgeowl.com.

Kate 25:31
And we are back from the break. So Liz, thank you for all of the conversation around Project Aria. I loved that. One of the other things that came up when we were doing some of our pre interview conversation was that you're currently working with a group that's involved with permaculture in Uganda, right? I'd love to hear a little bit more about this as well.

Liz 25:54
Since January, I've been working with an old friend of my dad's in Uganda to co-found Ngombor Community Development Alliance. It's in the West Nile part of Uganda, near the Congo border, and it's just been incredible. One of the things that appeals to me as a technical writer is how we can use words to create space and create more opportunities to turn up. I don't know if this is too much sucking up to the canonical interview process. I feel like it's possibly, like, a little bit embarrassing, how much I got out of that experience-

Kate 26:31
Or self knowledge, like there are some interview processes where you realize, Wow, this is really not the kind of organization, or not the kind of role that I want to be involved in, or there were pieces of this that I really was attracted to, and pieces that I wasn't. What does that tell me about the next role that I should apply for, or whatever that might be?

Liz 26:54
Absolutely. So, yeah, I was so excited that I even had a chance at a job at Canonical. I'd just come off an open source project, a big open source project, Project Aria, but I still had a lot of imposter syndrome, a lot stuff. I had inherited some baggage. I had inherited some early gatekeeping experiences of the open source world. So to have such a welcoming environment, because I knew from my own experiences of Project ARIA there is incredibly wonderful, warm, very excited to support people participating. So I threw myself in really hard, and they made it easy. They made it easy to participate and get passionate about it, Danielle. They were like, here's some stuff from Danielle, right? Read all of this stuff. And from there, I got into the diataxis framework, and was really excited about how the diataxis framework is similar to permaculture in some ways, like people get caught up on the surface of it. But if you look at it like the methodology, this is not a structure, this is a process and a way of thinking about things. This is a way of doing little things. This isn't a top down approach. This is a grassroots 'How can you inform it? How can you do little things? How can you be messy with things?' Which very much aligns with permacultural agricultural principles of not depending on a big hierarchy, optimize the yield. What can you do now? What are the little things that you can do? And so it was a lovely methodology to spend time with and then through there, in part because it was such a drawn out process. I started researching Ubuntu more, and canonical more, and I watched the Ubuntu Summit. And at the Ubuntu Summit, there was Ngazetungue Muheue talking about how people should turn up for partnering with Uganda, or, not Uganda. How about how people should turn up, about partnering with folks in Africa, and especially people in rural and remote Africa, and saying, We don't need chunks of cash, we don't just need random slugs of cash thrown around. What we need is friendship. What we need is partnership. What we need is an engaged sponsorship, rather than this scramble for various stuff, which really resonated with me and resonated with my background in the nonprofit world, about the difference between the performance of scrambling for ad hoc grants and just how much empowerment can come from sustained farming. So this is how much can come from sustained sponsorship and partnership and support, and how that just respects people's dignity and empowerment on a whole different level. So I saw this thing, and I was really excited and empowered by it, and I thought, well, this is a reason to reach out to a friend of my dad. My dad died a few years ago. I haven't been in touch with Vincent Olago for a long time. I'll reach out and just be like, is there anything you can do as a technical writer in the open source world? Is there any way I can help you? I was really inspired by this YouTube video, and he replied with, Oh, that's really cool. Great to you. I have 60 or 70 acres of land, and I want to found a permaculture model farm. And I said, Okay, well, let's see. Well, let's see what we can do, and we'll see how my writing skills and your your dream, and he's done a lot of community capacity building over the time he helped- he became friends with my dad almost 20 years ago when my dad supported him to found a trade school in Congo. My dad paid for the sewing machines that helped give sewing skills to women who are escaping difficult circumstances. And that's how their friendship began. So anyway, Vince sent me this proposal that was, like, wildly ambitious and like, shooting for the moon. And at the right the docs conference, there was that whole thing of, when people give you a crazy idea, don't just shut them down. Explore the concept with them and see what can become of it. And that's a principle I live by as well. And so I said, okay, what can we do here? What are the little pieces? What are the components? What can I do? We sort of built from there. I was like, Well, okay, for if we're going to do that, we need to have a website. I don't want to have the colonial thing of like, I could bang together a website super fast. I want to support people to have the website, you know, in Nebbi. I want to support people locally to do that. So I actually reached out to the, Write the Docs Slack, and I was like, I'm trying to think of how to teach how to build websites. What do you guys think? I was thinking about static website generators and stuff, and it was a good exchange in the write the doc slack. I was like, okay, Yeah, let's just go to HTML and CSS, and we'll go from there. And so I started to try to teach Vince HTML remotely. We're in completely different time zones. He has a laptop, but it's not capable of video conferencing, so any phone calls have to be with a data plan on a mobile phone, and because the hardware stack doesn't support video chat. I was like, oh, to do that, and just basic HTML. If we could cut, start collaborating on Git, that would help. We've got this big plan for all this stuff, but we will just focus on local empowerment. Can we support people to build a website? Like, that's a very small little thing. And so I said, Okay, well, PyCon Uganda is hosted by this physical location. Vince goes to Kampala every couple of months. So I reached out to the organizers of PyCon Uganda, and asked, Is there somebody that could teach Vince, like Vince could come by and they could teach him GitHub, because there's no way I can do that remotely and just give him a little lesson. And I got a message back, going, Okay, well, that physical location doesn't do that, it was just they were the host, but PyLadies Kampala, they're the ones that do this. And so I was like, Can we do some GitHub stuff. And PyLadies was like, ‘Hello, we are PyLadies, and we do these things, and we have these meetups, and this year, it's data science’ and blah blah, and we have a meetup, and they just like, came with this whole package of how they would like to help. So to get from Nebbi to Kampala, it's like a full day's travel through some incredible national parks and stuff like that, but they're really remote, so it was not a simple just go to a meet up, and we have gender equality baked into everything that we do. So I provided a little bit of money for two men and two women to go to the PyLadies meetup, and I supported for the female representation to include, they were a bit nervous about including some people that might not speak English and stuff like that. And I was like, Well, no, like, you have a lot of wisdom about incredible community leaders who have incredible wisdom and connection with you to speak to the challenges. You might not know a lot about it, but you know a lot about the community, and they'll be useful to bring to PyLadies. So they went to the PyLadies like they fed them lunch. They took them on a tour of the city and as well as attended this Introduction to Data Science meetup, and it was incredible to have a woman who had never touched a computer before in her life to go to the meetup, to learn about data science, to see how diet of science was relevant for agriculture, for sustainable- you know, she is a subsistence farmer. Agriculture is essential to her livelihood. Climate change is changing her livelihood. And for her to see the value in data science, that she would start recording data and details manually, and that she would support other people to learn IT and to learn computers and stuff like that. So I love that like that incredible chain, you never know when you throw yourself passionately into something what's going to happen, but you optimize the chance of an amazing result, if you just give it your full attention and potential- Because of applying for a job, I paid attention, which leads to this thing. We're now an officially registered organization. We've broken- people have gone to permaculture training, and permaculture is very grassroots. What can you do right now? You don't need to wait for a big authority. You don't need to wait for anything big and fancy. And it's okay to start small and messy. It is good. It's generative, having all of these different edges and stuff. And it's just been incredible to me, being able to build a bridge, to use words to create connections, to send emails to various people, and using my Western white colonial power, to help incredible people be valued and seen as being like you. You don't speak English, but I see your value. It's very humbling.

Kate 36:58
Yes, exactly. So it becomes almost this snowball effect, because I helped you with this little piece, you can now go out and do so much more impactful, important work among your community or your family or your peers, or whatever that looks like.

Liz 37:13
And it has been wonderful just seeing, and I'm sort of scrappily looking for volunteers and how people can help and stuff like that. Our first ever supporter was someone in the Write the Docs Slack, who I was in this someone was talking about, and I just, like, I just, I've been trying to figure out how to send money to, like, sending money to Uganda. And because I wasn't a citizen at the time, and America's in a very interesting place, you know, a lot, and I just want to send like, 20 bucks to Vince to do this thing. It's not a lot of money, but it would be really impactful. And it was someone in the write the docs community that was like, I can send 20 bucks. But some random stranger we never met said, I can send 20 bucks, and he was our first supporter. And there have been lots of, Can we do this? Can we do whatever? But just like that, that little bit of support. And then I was chatting to somebody through the Write the Docs community, and through my own job search, actually, I got an introduction to Lucy Mitchell, who's this wonderful technical writer based in the UK, and she's a phenomenal force of nature who can do so much, and then, like many technical writers, you just see what needs to be done next. And so just being able to talk with her, and she was like, Oh, well, let's improve the onboarding experience. And just like all the questions that she asked, I haven't answered half of her questions, but she's asked these questions, and so that helps us think through and mature our approach, so that we can bring on the next volunteer in a better way. We have a wonderful former colleague of mine who he's helping with the just a little bit of he's going to edit some video for us, and, you know, and he just asked me a few questions for how to put, and suggestions for how to put together the visual story that would help him do the video editing, and that actually, was so useful and helpful for how to tell our story. And just getting these little snippets of expertise and support has been so- It's just like, Oh, if you can just give me the structure. And I was like, Wow, thank you for that art direction. He didn't even think of it as art direction because it's just in his DNA, but it was so useful. Every time someone says, Who is the audience for this? Who are all those questions for and stuff like that, all these different people bringing their expertise has been amazing.

Kate 38:46
So that brings us full circle back to your seven year old self, interviewing the workers who are laying new floors and who showed you the best way to hammer a hammer. Sometimes you don't recognize how much knowledge you have or where you yourself need to ask questions until you have a good technical writer ask you, or it’s nice to have somebody who's an expert in crafting content in some way ask you very pointed questions about the content that you want created. It is a very nice distilling process, right? And into the nice without even meaning that was phenomenal, easy over here. Is there anything that you want to specifically call out here?

Liz 41:06
I came across a wonderful piece of permaculture advice that I'm going to carry through to a lot of things. Which is: the best fertilizer is the gardener's shadow.

Kate 41:18
Oh, wow.

Liz 41:20
Just turn up. You know, it loops back to that, the diataxis framework of, it's a process to pay attention to your docs. Just turn up. Number Community Development Alliance, it was like my commitment was ‘I'm just gonna turn up for 10 minutes’. I promise that I will spend 10 minutes communicating with Vince or working on stuff for Vince every week. I'll just turn up.

Kate 41:49
And it removes some of the pressure of feeling like you're not doing enough, or you're somehow not technical enough, or not expert enough, or whatever the not enough story that you're telling yourself is. Often just showing up and doing something in your docs, like you leave at the end of however much that time is with better docs, like this is one of the things in the solo episodes reporting out my progress on it. I often feel when I get into the recording like, Ooh, I got sidetracked by this thing, and then in the effort of trying to articulate what I did, I'm like, No, actually, this is a thing that I have really wanted to do for a long time, and I finally made the time to do it. And yes, it's only like 70% done, but boy, that 70% is such an improvement for what I had before.

Liz 42:40
Here's a sneaky Google findability trick as well. Content, freshness is an important metric. So if you have docs that you really want to surface to the top, it is better to regularly maintain it than do a big surge of energy and then ignore them for a long time.

Kate 43:00
There we go. We get two pieces of advice for the price of one, right here, folks, you're better to make those small iterative improvements, which is also an element of permaculture, isn't it? You want to make little changes with what you can. Do what you can, when you can.

Liz 43:17
That's right.

Kate 43:18
That's beautiful. And then the last question for you. Liz, if people wanted to follow up with you to kind of check out some of the work you're doing or get in touch. What are the best ways for them to do that?

Liz 43:31
If you'd like to stay in touch, if you go to lizargall.github.io, that's my portfolio website, and you can subscribe to the newsletter. Check out the blog if you look for Liz Argall. I'm pretty much the only Liz Argall on the internet. My creative career and my other community advocacy career is there as well, and I am an open book. If anything resonates with you. If you're curious about anything, you're welcome to email and talk to me and stuff like that.

Kate 44:02
I can attest to this. Liz is not shy. She loves connections, so you are welcome to reach out to her, and we will do links to all of the sites she's mentioned in the show notes. So you're welcome to connect with her that way. And you're also in Write The Docs Slack clearly, because you're talking about it, and I know you have a LinkedIn presence as well, because that's how I have stayed up to date on some of what's been going on with you.

Liz 44:26
So that's true, that's true. You can connect with me on LinkedIn and the Write the Docs Slack is a lovely, lovely space for any documentarian or proto content champion.

Kate 44:39
I love it. Thank you so much. Liz, I am so happy that we got to have this chat. Thank you for being so generous with your time and your knowledge. This has been fantastic.

Liz 44:49
Pleasure.

Kate 44:55
The Not-Boring Tech Writer is co-produced by Chad Timblin, our podcast head of operations, and me. Post production is handled by the lovely humans at Astronomic Audio, with editing by Dylan, transcription by Madi and general post production support by Been and Alex. Our theme song is by Bright Side Studio. Our artwork is by Bill Netherlands. You can check out KnowledgeOwl’s products at knowledgeowl.com and if you want to work with me on Docs, knowledge management coaching, or revamping an existing knowledge base, go to knowledgewithsass.com that's knowledge with sass.com. Until next time, I'm Kate Mueller and you are The Not-Boring Tech Writer.

Creators and Guests

Kate Mueller
Host
Kate Mueller
Kate is a documentarian and knowledge base coach based in Midcoast Maine. When she's not writing software documentation or advising on knowledge management best practices, she's out hiking and foraging with her dog. Connect with her on LinkedIn, Bluesky, or Write the Docs Slack.
Chad Timblin
Producer
Chad Timblin
Chad is the Head of Operations for The Not-Boring Tech Writer. He’s also the Executive Assistant to the CEO & Friend of Felines at KnowledgeOwl, the knowledge base software company that sponsors The Not-Boring Tech Writer. Some things that bring him joy are 😼 cats, 🎶 music, 🍄 Nintendo, 📺 Hayao Miyazaki’s films, 🍃 Walt Whitman’s poetry, 🌊 Big Sur, and ☕️ coffee. Connect with him on LinkedIn or Bluesky.
Liz Argall
Guest
Liz Argall
Liz Argall creates empowering documentation and processes; where you need it, when you need it. She’s a technical writer, program manager, author, and trainer who delivers humanizing, data informed, accessible, and technically complex projects for a range of organizations, from Fortune 500 companies to a community development organization in Uganda. In a past life, she was a professional artist talent scout and she’s still a professional member of SFWA (now called the Science Fiction and Fantasy Writers Association). She’s a graduate of Clarion Writers Workshop, has been critiqued by multiple New York Times best selling authors, and has critiqued the stories of multiple award winning authors, which is a long way of saying that she likes to give a good portfolio critique!
Connecting permaculture and documentation with Liz Argall
Broadcast by