Luke Pivac, Author of An Agile Playbook for Technical Communicators

The transcript below is unedited output from OpenAI Whisper.

====

Hi, I’m Len Epp from Leanpub. And in this episode of the Front Matter podcast, I’ll be interviewing Luke Pivak. Based in Auckland, Luke is a writer and professional agile project manager and scrum master with experience in both startup and big enterprise environments who is currently working in the banking industry. You can follow him on Twitter at Luke Pivak that’s PIVAC and check out his writing on Medium at both luke pivak.medium.com and on his agile adapt blog at medium.com slash agile dash adapt. Luke is the author of the Leanpub book and agile playbook for technical communicators, a guide for technical communicators working with agile teams. In the book, Luke helps technical communicators learn what agile development is, and what its benefits are for team collaboration. In this interview, we’re going to talk about Luke’s backward and career, professional interests, his book, and at the end, we’ll talk a little bit about his experience as a self published author. So thank you very much, Luke, for being on the Leanpub Front Matter podcast. Hi Len, thanks for having me. I always like to start these interviews by these interviews by asking people for their origin story. I’m always wondering if you could talk a little bit about where you grew up and your career path. Yeah, sure. As you can tell by my accent, I’m from Auckland, New Zealand, born and bred in Auckland. I went to the main public schools here. And my writing, interest in writing started as a young at a young age, I was always interested in like acting movies, you know, books, TV shows, things like that. I’ve been a child of the 80s grew up with Knight Rider, MacGyver, Transformers, playing with those GI Joes and things like that. When I went to university, I studied film television production. But, you know, throughout throughout those formative years, my interest in writing grew and grew. And it wasn’t until in my 30s, I got into IT, especially writing for technology, because I thought, you know, a way of expressing yourself and actually having interest in helping users use stuff was really appealing to me. So I decided to do some study in technical communication. I got my first job working for an international company called Navico, who do marine electronics, so like some rad, echo sounders, things like that. And I met a wonderful lady named Aude Ellie, she was Norwegian. And through the powers of working remotely, being in Auckland, she was obviously in Oslo, I learned, you know, to, you know, those factors of working with documentation, using Adobe to share, you know, latest markups of information. But what was more important was being a mentor, or a mentor working with her learning how to convey information clearly for users, she could speak two or three languages and write just as well in them. And I learned a great deal from her. It took a couple of years there. And then I worked for a startup company called Unleashed Software. During that time, I was a technical communicator with, you know, some developers who were, you know, about 13 or 14 of them, and then three or four testers, which, you know, test the work that they’re doing. And there was a bit of a bit of a conflict there with personality. So they said, well, you’re the technical communicator, you can, you can run this impartially. Do you mind giving it a go? And I said, Okay, what’s this about? And I sooner than later, I realized that it’s more than role calling and asking people how they felt, were using the scrum framework. And what was interesting was, it kind of gel to me like a, like a, you know, hand, you know, like a glove hand fitting into a perfectly fit glove. So I wanted to know more about it. I did a course and agility ended up becoming my new passion and career. During that time, I learned how to balance end user documentation and running like scrum teams. And from there, my passion for agility came through. And these days, I’m more of the senior agile leader, but my core skills of writing are still there. So what I really love doing is fusing my writing nonfiction writing with my passion. And I use the plan do check X cycle of I learn, I plan it, and I do it, I do learn some things from work, do some reading, and then I reflect on it. And then I write it. And if people are interested, then it’s a win win for all of us. But that cycle is quite a theme in my working career the past 15 years. Thanks very much for sharing that story. That’s interesting. plan do check act. Is that the deming method? Is that am I getting this? Okay, okay. So it’s it’s really interesting. The reason I bring that up is because it’s a technical term that I can link to and so people can learn more, of course, from your book and your blog and stuff like that. But preparing for this interview, I found a video on YouTube that I think you published years ago, where you actually talk about the history of technical writing. And so it’s interesting that you bring up these sort of challenges that like, you know, like, it might sound like a kind of straightforward and kind of dry thing. But there’s actually a lot of interesting challenges in it. And technical writing kind of exists for very important reasons and has its history in naval shipbuilding, and the military, which is super interesting. So if you if you can recall any of the any of those factoids, if you could, if you could talk a little bit about that, that history of technical writing and where it comes from? Yeah, no, absolutely. That rings a bell because I remember doing that video many years ago now. Um, so yeah, with with that, with that course, and with the history of technical communication, there is a difference because people think of documentations documentation, like, you know, the stakeholders and you know, what we need to do, but it’s more than that. It’s, it’s the art of writing in plain language. And it’s the art of, you know, showing people how to convey information in a simple and digestive way. And days of now we’re talking on this podcast, right? And you could use this as some kind of, you know, knowledge base that people can learn from, and many other, you know, Josh Rogan, is it? You know, he has a lot of information, whether it’s relevant or not. This is infotainment, but, you know, that there’s a long history of, you know, knowledge sharing, and a way of doing that back in the day, and that’s fishing with boat builders and makers, even when the famous Greek philosophers were around, you know, with Aristotle and Plato, they would do a lot of right hand and a lot of those what we’d call cliches or sayings were actually coming from, you know, knowledge based information. So there’s a big history of that. I think with technical communication, that was, it’s there to be direct, make it understandable for anyone to follow. And there’s a big challenge in that. And some people, and even I had this misnomer that it’s, it’s isolated, you’re, you know, it’s, you know, geeky thing you do, and only, you know, really interested people read it. But it’s actually, it’s from packets or of an ingredients and something you buy from the supermarket. It’s the messages that you get from, you know, some public service, email or notification. It’s even on the radio, there’s still people that need to do writing, whether it’s an script format for entertainment purposes, or even for information purposes. So I think it’s a really, really interesting profession to get into. The thing with technical communication is not necessarily the art or the craft of writing that information. It’s actually the challenges gathering that information, and getting it from the right subject source and getting it validated. That’s a process that you need to go through. And there’s many people and there’s many distracted people that you might be working with, that don’t have time for it. And I think with the art and challenge of being a technical writer or a technical communicator is actually having that ability to influence and engage to get your subject matters on your side and maintain that relationship. And once you get that, that information that you can get will become more fluid, more open and more accessible. So a lot of it’s got to do with relationship building. This is what led to me writing this book. It’s the challenges of, you know, overcoming, you know, some of the reluctance that developers or testers might have, or that people simply don’t have time. But the great thing about agility is that, you know, it breaks work down in small incremental chunks, so that you and, you know, stakeholders and the development team need to be in play and in sync. So it’s a great opportunity for people like technical writers to leverage that opportunity and engage with those people they need the information from. Yeah, thanks very much for that, and in particular for bringing up philosophers. For my sins, I wrote a doctorate years ago in English literature, and it was largely on the subject of clarity and obscurity in language. And so I could talk about that as probably almost as long as you could. But it is very interesting, because the need for clarity and the need for clarity to sort of be for things to be clearly explained to new people or people who are new to it. I don’t think it’s an accident that the history of it comes from the military, because the guy who knows how to work the cannon might not be there five minutes from now if you’re in a battle and or he might not be there for the next one, maybe be maybe not because he gruesomely died in battle, but because he’s, you know, off, you know, doing something different now, his tour is up or what have you. And so actually the sort of like imperative to have clear language and conventions for expressing things that can, you know, be where those conventions can actually be transmitted across teams or people and over time in particular is so incredibly important, where it gets really where it gets super interesting philosophically is that I think, you know, a philosopher of language that I once took a class with talk about how like the, you know, the best proof that language works is skyscrapers. One could say the same thing about getting like a satellite to hit an asteroid millions of miles away from the earth or something like that. But what what happens though, is that often, in my view, we do this natural thing where like, there’s this, this, this, this, these classes of things that you can speak about very clearly, like, but do these steps in this order? And then there’s like, how should I vote? You know, those are, you know, you can’t, it’s sort of what we want this kind of clarity that exists in with some classes of problems to exist with other classes of problems. And so often people kind of think that if something isn’t being communicated to them, clearly, there’s a problem with the communicator, not that there might be something inherent to the subject. And I don’t know how deep we want to go into that kind of thing. But it’s interesting that software development, people often want the kind of clarity that can come from these kind of, as it were kind of straightforwardly physical process descriptions, lay these bricks out in this pattern or something like that. They desperately want that same kind of thing to exist with software, but it can’t in some ways or for lots of things, because software is like writing software is a generative thing. It’s a creative act that’s new with every line of code that someone writes, or at least is is for now when when the AI is writing it, maybe that’ll be different. But But in any case, I wanted to ask you a little bit just this has come up on the podcast before I’m sure most people know, but can you talk a little bit about what agile software development is, and how it differs from sort of the conventional in the past kind of waterfall software development method, just so people understand what the kinds of things we’re talking about communicating and documenting here, of course, waterfalls is your typical project management conventions. So when you’re planning your building, and then you’re testing and then you release it. So it’s a cascade of waterfall. But the problem is, with waterfall and software development is that, you know, you might do a chunk of work up front, get all the documentation, you know, the contract, some stuff like that, how are we going to engage who we’re going to employ, and what we’re going to build. And then you get into the build phase. And each part of this is educated. The problem, especially digital 2.0, so to speak, is that your competition, and there’s thousands of competitors in the market, so to speak. And it’s really hard to be competitive when you’re still planning a project that you’re going to do in two years time, and your competitor might have something out in the market within three or four months. So the great thing about agility, which was created in 2000, 1991, with a group of software engineers who decided to meet and find a better way of building software than just using your traditional waterfalls methodology. And they came up with the Agile framework. Look at listeners if you want, with the Agile manifesto. So there’s four values, and there’s 12 principles. But basically, it’s the principle is, if you can work together in a room, in a whiteboard, to plan something out, and then you can start building it by working together with a bunch of cross functional teams with all the different disciplines, from developers, to testers, to BAs, to UX designers, you know, the whole gambit, as well as a leader, which would be a scrum master, for example, who helps educate the team and coach the team on the different scrum events that are available and focus on the team health. And then you’ve got a product owner who focuses on the return of investment and as the customers puts a customer lens on the work, so prioritizes the backlog of items that they need to do. The developers, as in that cross functional team, meet together, look at the backlog and agree to, you know, grab a small chunk of that backlog and prioritize it and work on it for a small iteration, typically two to four weeks long. The great thing about that framework is that they, the principle of scrum with, or Agile, is that you have to deliver a working piece of software, something, you know, small incremental, you know, bit of value to the business at the end of it. So you’re slowly but surely releasing things as you go. Just as a segue, that’s the great thing about Lean Pub, you can publish something as soon as you feel like it’s good to go and you can build your audience and grow on it. It’s the same principle. Using just in time planning and agreeing with the business and the team on what the priority of work is, it gives you time to pivot, as in adapting the change of the stakeholders who check at the end of the time, like what they see, or they want more of it or less of it. So it provides more dynamic flexibility in that. I think the cat’s out of the bag with, does it work in software and digital? Yes, it does. There’s 30 years plus of, you know, evidence to show that that’s actually the case, especially in a highly competitive market. But you still have traditional projects like boat building, possibly NASA, you know, Space Aeronautics, they use a lot of agility, but a lot of, they use waterfalls a lot too. Same with, you know, construction and things like that. So there is a place for traditional project management, as well as agility. But agility, even if you don’t embrace the agility framework, things like stand ups, meeting with your team every day, that’s a good thing. Reviewing with your customer at every opportunity when it’s possible, it could be a stage gate. That’s a given. That makes sense. So even if you’re not adopting a whole agile approach, these techniques and agility that people use every day, because it makes sense. So whether it’s in one form or the other, it’s here for the long haul. Speaking of stand ups, so we’re talking about a certain sort of type of meeting where people use the word stand up to sort of sometimes literally mean like stand up, right? So you don’t sit down and it’s like, we’re here for a reason, you know, and actually makes a big difference to meet people standing up rather than sitting down. But that gives me the opportunity to talk about something you write about in your in your bio, which is that around the beginning of the first COVID lockdown, you helped Scrum Master, a team that I imagine sort of went remote at that time. And so I was wondering if you could talk a little bit about that project and in that context, explain what Scrum is. Yeah, of course. Scrum is an iterative framework that sits under the agile umbrella. So agility or the agile framework, so to speak, is not necessarily a mapped out process. It’s a high level framework, but it adopts certain techniques. Scrum is one of them. For Scrum is, like I was explaining earlier, is basically, it’s an iterative approach, where you’ve got two to four weeks, you meet with your Scrum team, and you meet with your Scrum team, you’ve got your plan or your backlog of prioritised items, the product owner is responsible for prioritising those. And then the development team can work with the product owner and the Scrum Master to take a piece of that work with what’s agreed on, and then they commit to it over a period of time during that sprint or iteration. It’s two weeks long, and they work every day on it by building and developing and they meet at the daily stand up to answer what they’re on track or not. Are they meeting the sprint goal? And if they’ve got any blockers, can anyone in the team help? So this helps with co-location environments, and I’ll get to COVID in a minute. But that term, osmotic communication, it’s about, you know, hearing that information in the background, someone’s talking, and you might, you know, like osmosis, you hear something in the background and go, oh, yeah, by the way, you know, encourages that kind of collaborative environment. Working remotely, that can be really challenging. However, it’s not impossible. This is why working in that location and COVID came, working with your team in a co-located area all together in an open plan environment, working remotely, that’s all disappears. So when COVID came along, I was working with a New Zealand government agency called Health Alliance. So we basically do all the software with the hospitals, hook up vendor services with the hospital internal platforms. And I was working with DevOps team and all of us and you know, with working on health, there’s a lot of people’s like private medical information. And also, you know, some of these cases is some extremely sick people. So it was really important that we got this right. And I was fortunate enough to have a really mature, well-developed team and I got that respect. I spent several months working with them on enhancing our agility practices. So when we couldn’t go into the office anymore, we had to do it remotely. I had to work with senior leaders on what that looks like for us. And it’s about the rhythm of the meetings. And even though we can’t meet in person, what can we do online and how can we run it? So that was a really intense learning process. But we consolidated and brainstormed and came up with a framework that would work for us. And I was pleased to know that the work was really challenging and hard, but it was rewarding. And we got through that. And I learned a great deal from that experience. And it sort of led me to write about it a bit further down the line. Having an experience like that, especially in such an intense regulatory environment was a real eye-opener, but it was a real educational piece for me. And I learned a lot from it. And with that, it kind of cemented more of my understanding of agility than ever before, because of the opportunity and the unique experience I had. So I started writing a lot about it. And now it’s kind of been taken, now that we all do it more regularly, I think it’s become more of a norm now. And going back to the way we did is kind of a forced evolution of, you know, I’ve had to relook at the way we do agile practices, or the way we work together as a culture throughout the world. Yeah, it’s really interesting. A friend of mine who’s a surgeon told me that at the beginning of speaking of healthcare and things like that, that at the beginning of COVID, he had to rethink how he did things, meeting with patients and things like that, right? So they started doing a lot more things over video and stuff like that. But you immediately start, of course, you really start realizing what you’re kind of missing, when you can’t, when you can’t be physically together. And sort of a lot of the things you might not have thought about that you sort of relied on, or that were productive, like overhearing something or being able to dive into jump into a conversation that you see happening or something like that. And then finding ways to kind of recreate that virtually and stuff can be really, really rewarding on its own. And so in addition to working in the sort of healthcare, where there’s all sorts of private important data, the next question I wanted to ask you was about something you mentioned that we talked about a little bit before we started recording, which was that around the age of 40, you were you were diagnosed with ADHD. And you talk about this quite quite movingly about how you know, you can, one can turn that into an opportunity for for improvement and sort of, you know, put it to work for one’s benefit and the benefit of those around you. And so I was wondering if you could talk a little bit about that experience, what it was like sort of being 40 years into your life and learning something so important about yourself and how it how it affected your daily life and your working life as well. Yeah, of course. Thank you for the question. I, my children are both on the spectrum, they kind of, they’ve been diagnosed with ADHD, but they’re very talented children, highly intelligent, and, you know, going through that experience, I realized how much insight and gifts to the world that they have with, you know, being on the spectrum. It kind of led to me going to my doctor and questioning some of, you know, the habits that I noticed through my children, you know, that things weren’t quite right. For example, you know, I was, I learned a lot as a technical communicator, but, you know, having ADHD was very challenging, getting all the information, understanding at first, and breaking it down simply. And then I went to my doctor and I did some tests and he did say I did have a, I was a high functioning ADHD candidate. And that was really interesting because from my experience, that would explain a lot, always did well in IQ tests and emotional EQ tests, but I couldn’t sit down in an exam in high school for two hours. I would either choke and fold like a pack of cards, or I just couldn’t sit there and stare at a piece of paper with text on it, trying to conceptualize something in my mind for that long. And having that diagnosis at age of 40, I’m 45 now, was a real life changing event for me, not for the bad, not for the worst, but for the better. I could put a label on this thing about why is my brain always sometimes getting a little bit cloudy? Why can’t I see the wood for the trees all the time? And having that diagnosis and, you know, getting it treated, it took the edge off and enabled me to see things a bit more, less myopic than before. You know, I can, I’m really better. My gift to the world is connecting the dots in projects and, you know, pulling up for next actions and seeing, you know, what possible problems might happen. Having that opened up my mind to see that a lot more with greater scale, greater depth and greater detail has been really eye opening for me. You know, for anyone, you’re never too late. And I’ve got friends the same way. And I think it is quite rewarding, the fact that, you know, you can actually understand how your brain works, and what you need it to do. And what it’s enabled me to do is move on from that and concentrate on my strengths and my gifts to the world, so to speak. And I believe I’ve become better for it. Yeah, thanks very much for sharing that story and sort of how you came through sort of your experience of watching your children and then sort of learning something about yourself as well is very fascinating. It’s education is a sort of whole, a whole nother kind of subject that we could talk about for a long time, like, like clear language and stuff like that. But you know, the idea of particularly kind of young people being asked to kind of sit in desks in rows and sort of do hour or two hour long exams is not, it’s not necessarily wrong, but it’s not natural either, right? It’s a we contrived that convention. And I think I think it’s I’ve talked about it on the podcast before with somebody where like, you know, particularly in the origins of the American idea of school, and the way we think of it now with the rows and desks and sort of bells going off and rigid demarcations of time throughout the day actually came from the Prussian military, which is super interesting. But but in any case, yeah, no, it’s not for everyone all the time. You know, it’s not for anyone all the time to be doing that. And it is a model that I think we all need to kind of be don’t necessarily need to challenge every moment of every day. But we do need to be aware that like, this is something we made up and something that we can change. So you’ve got a blog, Agile Adapt, and I was wondering if you could talk a little bit about when you got into blogging and what you write about there. Yeah, so basically, I’ve been blogging, kind of when I started moving around to technical writing, because, you know, writing is part of my DNA. And I was moving, I was transitioning when I was at Unleashed Software out of technical writing into more agility. So as part of me trying to understand my new career, and seeing what I learned at a startup and running scrum teams, but then moving into more of the agility focus is that if I’m the one doing this is surely there’s other people and they want to know about this. And, you know, I’ve got this gift of writing quite well, and thought I’d give it a go. And over time, I’ve built a loyal audience and I’ve enjoyed it. And it’s actually like I was saying earlier, the plan, do check act cycle, you know, it’s part of my process on how my brain works, you know, learning something, writing it down, shaping it, and applying it to work and then reflecting and then writing about it and sharing it on my blog is actually my cathartic. It’s cathartic, it’s part of my process, but it’s part of, you know, how I reach out to the world. So that’s been really, really enjoyable. Agile Adapt is basically my thoughts on the agile and adaptive management techniques, using iteration, iterative approaches to manage things. And that could be with software documentation, it could be from master running a team, it could be someone struggling with high performance teams, or someone who’s been bullied, and you know, a development team by a senior developer, because a lot of, you know, engineering environments is very hierarchical. And even though we tried to avoid that, naturally, that’s been embedded in generations of engineering, something that sometimes some people default to. So I think what I find awesome is a mindset, an agile approach or an agile mindset is a growth mindset. So we’re trying to bring people together, work collaboratively, and, you know, get the best work out of people and feed them, close those feedback loops, you kind of got to work with people together, because at the end of the day, it doesn’t matter how many documents you sign or how many agreements you’ve got in the bag, some people have got to do the work together. And to do that, you kind of got to be conciliatory, collegial, and, you know, get on with people, and basically not be a dickhead. Yeah, you’ve got a relatively recent post that I read about psychological safety, and how important that is, and that they’re actually kind of, and you set out, it’s not, it’s not just kind of, there’s a system that you can have in place for checking things like, you know, is this a psychologically safe environment and sort of being, you know, the fact that like, that’s, that’s not a soft thing. That’s a hard ass thing to make sure that you’ve got a psychologically safe environment, because if you really want to get projects done well, you need to have that as part of your, not just have the psychological safety, but having reviewing it and being self aware about it, being explicit about having that environment and why it’s actually really important, which is great. And of course, I’ll link to that link to that in the transcription. Just moving on to the next part of the interview where we talk about your book. So you’ve got this book out, an agile playbook for technical communicators. And I was just asking, I just wanted to ask a little bit about what’s the origin story of that book and just talk a little bit about what you have to say in it. So of course, thank you. I wanted to write about challenges of communicators working agile teams for quite some time. Going back, I experienced a lot of that over the years, but you know, when I went to Unleashed Software, being a tech writer, and then basically being forced to, well forced, but a happy accident of running the scrum teams. It gave me some really interesting insights into a lot of technical writers either on their own, or they might be with working with other technical writers, but in different teams and not really connected. Because at the end of the day, technical writers are providing a service for a specific product. They’ve got to concentrate on that. It’s very rare you get a group of technical writers together working collectively, but it does happen. So this book, I felt I spent most of my time, especially as a technical writer on my own. And you know, I had to fight to get the attention of developers to be their subject matter experts to get that information through there. And you have to build relationships and battle through things. Additionally to a lot of discussions on forums that have come across with technical communicators is this agile thing that can be challenging. And sometimes it can be, it doesn’t consider technical writers and the workflow processes. And I wanted to challenge that idea because it actually does. But I realized that there’d be a lot of technical communicators out there that wouldn’t be open to getting that training, not open to it, but accessibility wouldn’t be there. And sometimes they might just be thrown in the deep end and go, just do it. So I felt quite strongly that there is actually a way, there is a place for technical communicators and other more siloed professions like BAs or even UX designers. There’s only one of you and a team of civil developers or quality engineers. Where do I fit in this place? And I felt like I, based on my experience and insights, had something to share on that. And I also wanted to educate for those interested, what is agile? What are the good things about it? What are the bad things? Some of the misnomers? And I talk about that in the book. Yeah, I know it’s really good, actually. I mean, there’s one sort of interesting detail I wanted to dive in on there, which is the difference between product documentation and user documentation. And I was wondering if you could just talk a little bit about that important distinction. That’s a really good question. With product documentation in the book, you know, I refer to it as things that are internal documents that need to get the work done. So it might not necessarily include a technical communicator, but the technical communicator would use that information for the user documentation. So that could include contracts, it could include scrum artifacts, like a definition of done. So, you know, when we finished this user story or this task that we need to do on the board, what does success look like? Definition of ready, how do we get that ticket from planning to get it started to build, for example. So that’s what I mean by product or project information. It could be other things like as built documents, QA testing documents, internal documents to the organization that they can use or produce to get things done. End user documentation could be help files. This is something that the technical communicator really focuses on. So it would be help files, FAQ files. It could even be a wiki blog for certain users that they need to address. But it’s basically what the user needs to get something done or the assistance that they need to do if it’s really complex software. Yeah, it’s really interesting you mentioned there, you know, defining done, defining ready, defining these terms and having to redefine them in each new context is just so interesting. I mean, you know, if anyone who’s ever been in a debate club is, you know, first rule is define your terms, you know, the same thing is true if you’re writing an essay in philosophy class. But if you’re going to work with other people, one thing, and this again, goes back to sort of those deep issues about clear language and stuff like that. A lot of people think that the sort of they associate clarity with being quick and just diving in because you’re adding complexity, which we don’t normally, we think is normally like kind of complexity and clarity kind of bash up against each other. But if you don’t add a little bit of work at the beginning of a collaborative process with other people to do something, it seems boring, and it might seem pedantic, but you need to define your terms. And in particular, if you’re trying to produce something, step by step, defining what’s ready, like is that defined piece of work ready to go, we need to know what that means. You need to when work is done, you need to know what that means. And that’s also in order to provide the psychological safety, right? Where it’s like, why did you mark that done? It’s not done. And you go, well, it’s done according to the definition might be like the kind of boring answer. But like, you know, that’s why I did it. Maybe we need to revisit and like, you know, we need to sort of our definition and you’ll actually change those definitions over time. And so like tack tackling those kinds of things head on. But in particular, as I think you mentioned a couple times, the challenge of convincing people that this is something that you need to do when they all just want to be banging away at that creating code or doing whatever else it is that they want to do getting people to take time away to sort of read through a document understand have a come to a shared understanding of things can be a challenge all on its own. And so anyway, I recommend anyone who’s faced this challenge or who might face this challenge, please, please buy the book. It’s really good at explaining these kinds of things very well. In the last part of the interview, we talked a little bit about your experience writing and publishing and being a content creator. And believe it or not, there are actually people who skip to the end just to hear the sort of bits of wisdom and stuff like that. But I was wondering, with respect to your blog, do you have a schedule, for example, do you get up at 6am and write 1000 words every day? Or do you do it when inspiration strikes you? That’s a really good question. I think it depends on what I’m feeling like at the time. So what the one thing I do myself to is writing is that for I’ve got to do at least one blog a month. And what that one blog will be is, you know, it’ll give me some time to stew over ideas. And then I’ll make some notes, and it will evolve over time with those notes. And then I kind of shape it. And then I look, you know, I’ll sit away from it for a couple of days, and then I’ll look back at it again. And I go, does this make sense? Is this the intent of what I’m trying to do? So it is a process. To be honest with you, though, writing an agile playbook for technical communicators, and I’ve just released a new one. It’s called Leading from afar, digital remote working. And writing chapters gives me ideas. I end up blogging a lot more regularly because my brain is stirring about the work and structure that it’s got in the book that I might have tips and tricks that I could borrow that are not necessarily in the book, or I could talk about it in a general term in the blog. But they’ve kind of got to coexist together and elaborate. So whatever I’m writing about it at the current time is probably quite similar to the book that I’m working on as well. But I think for me, a benchmark is monthly a good quality blog that you know, I’ll spend a few weeks shaping on. And if anything else comes from that, I might split it into two. So it could be two or three blogs in a month, come from one, one, one, but at least one a month is my main thing. When I’m writing a book, I tend to have more because I just my brain is kind of all the electrodes are connecting up together. And, you know, swung me around. So I have a lot more insight and enthusiasm to just get it out to the world. For some reason, that reminded me of something you said reminded me of something you mentioned in an email when we were talking before the podcast about you’re going to be hosting a webinar. I’m just I’m just reading from my notes here about tech, technical communication. And you’re actually going to use the Q&A from that webinar to update a chapter of your book with some new content. I don’t think I’ve heard that one before. That’s a really good idea. Yeah, I think. Yeah, I’m just trying. It’s relevant. So I’ve actually, this is a technique I picked up from a while ago, I interviewed in my blog, I’ve interviewed agile leaders like Joanna Rothman, Kelly O’Connell from LinkedIn, there’s a lot of agile talks, and also Ryan Ripley, who’s written a book just recently called Drixing or Scrum. And I sort of did a video call like this and interviewed them, but I didn’t use the video call, I just sort of did a transcript of the Q&A, and I cut it up and put it into the blog. But they got the idea with the technical writing book, I actually ran a Q&A before I wrote the book. And there were some really good questions in there. And I said, well, why don’t I just use that and annotate some of it and include it in the book? Because these are actually general questions that most people would have challenges with. And I thought that went down really well. I worked with my editor, Steve, he used to be my mentor as a technical writer, he thought it looked really good. So I’ve got a new webinar coming out. And it’s actually based on a chapter of my book. It’s basically working relationships. So you know, how do technical communicators work with a product owner? How do they work with a scrum master? How do they work with a development team? And this is from the same organization that I had the previous webinar with. So I thought it might be a good opportunity to use that recording, just obviously, and with privacy respected, use some of the general questions and shape it to update the new version of my book in Lempub. Yeah, it’s a real, I think that that’s just a really interesting idea of like, you know, sort of writing something, publishing it, having a webinar on it, and then getting feedback from people and then updating, updating the chapter that generated the webinar in the first place is just is just a really interesting Yeah, I think that’s kind of my plan to check. Yeah, yeah, no, exactly. Exactly. So it’s really, really good idea because we we do at the end of the podcast, I’m sort of happy to go into the weeds. One thing I wanted to bring up is you have a very good cover for your book. Anyone listening who’s who’s thinking about self publishing, I think a good if you can at all get one producing a really great cover is makes a big difference usually. And so I was wondering if you could talk a little bit about how you got your cover. Yes, of course. When I was working at Navico, I mentioned that earlier, I became very good friends with a art director at Navico named Michael Moore, no relation to Mike Moore from going on 911. But he just same namesake. He was a very talented is a very talented graphic designer. And I was very fortunate enough to come good friends with him. And he’s been a good mate over the years. He now runs an agency. And for I don’t know if you, your listeners are yourself are familiar with the term, but in New Zealand mates rates. So a few bottles of wine and maybe maybe a good, you know, recommendation. He’s helped me with that. So I was very fortunate enough to do that. So I guess my point is, if you know any good graphic designers, or anyone that’s good with illustrations, leverage that. And I know in lean pub that that you yourself you recommend that and I wholeheartedly agree there is it is worthwhile. Additionally, that’s not possible. I think leveraging a free app or online service on Google to help craft it but spending time and graphics is actually just as important as the words because that old expression that you’re paying 1000 words, it kind of does in some ways. So I actually think even if it’s not your talent, because I can’t draw to save my life, but I’ve got friends who can if that’s not an option, just try and scrounge get what you can from it. Because spending time on a good illustration does does have its rewards. Yeah, definitely. And I guess the one thing I would add to that is don’t don’t let it hold you back, right? Like, yeah, if you don’t have a great cover yet, don’t let it hold you back. But but it is again, taking an iterative approach to these kinds of things is really important. And there’s there’s always room for improvement. And and ideally, in the end, you’ll have like great illustrations and great covers and stuff like that. But while you’re working, you know, good enough is good enough is good enough. Absolutely. Can I just add to that? The cover just sort of reminded me the story of the cover was that Mike was asking what kind of cover would be some concept, but weren’t really jelling. So I just maybe it’s the way my brain works. But I just sort of said, Well, my favorite color at the time was I like British racing green. And I really like the new web web or blog that is coming out at the moment. It’s kind of like I’ve got a Beatles yellow submarine feel to it with this, you know, kind of big bloggy people with big, big legs and really nice dynamic, colorful visuals. And I see something like that. And I was very fortunate to have a graphic designer who kind of modeled that and shaped it into into what it was. But I did want to make sure that it was collaborative and had that remote working feel to it. And that was kind of my remit, my brief to him. And he came up with some really good imagery. Yeah, it’s fantastic. The last question I always ask on the podcast, if the guest is a lean pub author themselves is if there was one magical feature we could build for you, or if there was one thing that had you sort of shouting at the screen and shaking your fist at lean pub every time you were using it. Is there anything you can ask us that you would want us to fix? I think it’s really great dynamic field, I think the forum and more of community based stuff, my forum didn’t work. I realized that it was, it’s been underutilized, but hopefully after this and with the webinar, that will get get into practice a bit more other than that, I believe that what you guys do is really great. And I think the, the profits share and, and some of the cost model that you have is really forward thinking and really well structured. And I’m really looking forward to being part of that. The other thing, you know, I’d love to see some marketing partners come into into into the, you know, promotion is should be on the writers as well. So it’s been really good because I’ve had to humbly socialize some of the stuff and it’s been really quite good engaging with the readers. So that’s been quite exciting. I really enjoy the platform. I think it’s, it says what it says on the tin. It’s lean pub and you know, you can get something out soon and, you know, cater with your audience a lot more. And what I really like about it too, is that is you an opportunity to engage, not just with, you know, the lean pub services, but you know, the community inside lean pub and as well as, you know, on social media. Yeah. Thanks very much for sharing all of that. It’s interesting. Yeah. With respect to a forum. So for anyone listening, who’s not familiar with it, if you, if you create a link, if you publish a book on lean pub you can actually click a button to create a forum. This runs off a service called, called discourse. And while we had it, while we had it, we’ve had it for quite some time, we hadn’t given it a lot of love basically. And sort of things just started to come apart and just wasn’t functioning properly when people were creating new books and stuff like that. So we actually put a lot of effort into it and made some big changes, but like the forums are quite robust. Now they’re as robust as you’ll see if you, discourse is a very popular thing. I think masterclass might use it or used to, but either very robust forums and they can be really good places for community and they are relatively underused. Oh, and if you’re a lean pub author listening, join the lean pub authors forum, talk there more. But when it comes to marketing, we sort of realized a few months ago that we needed to do a lot more work helping authors market their books. You know, we’ve, we’ve always sort of been sort of nerds about the sort of publishing kind of like the book side of thing, right. And we need, we realized we need to do a lot more. And part of the reason is that like, you know, self-promotion is really important. If you’re self publishing, you’re already self-promoting to some extent, but one of the roles that like, we’re not a publisher, we’re a self publishing platform, but you know, one of the roles that we can play is doing things like this podcast, giving people an opportunity to have us put them out there. There’s just a little bit of a different dynamic between that and just, just sort of straightforwardly putting yourself out there. And so we’re going to actually be doing a lot more things like one thing we’re going to be doing. And for example, if you’re, if you’re, if you’ve made it this far, please subscribe on our YouTube channel, because we’re going to be using that as the main venue for all kinds of video stuff. So we’re going to have a series called Lean Pub Launch, which is going to be inviting authors and giving them a form that they can fill out to apply to do launch videos. So if you’ve just launched a book, let’s record a launch video with you. And that could be where we don’t know how it’s going to work out, but we’re going to like, it could be Twitch or Instagram live streams. It could be just submit a video to us if you talking and we’ll publish it on our YouTube channel, you know, after, after reviewing it and things like that, but it also, we’re not going to use it just for new book launches. It’ll be like a new chapter, you know, because that’s part of Lean Pub is I’ve launched it. You don’t, you’re not necessarily launching a new book, but you might be launching five new chapters or something like that. And that’s definitely worth a video. And we’re going to be doing other things as well. So, you know, kind of watch this space, but definitely I, we, we at Lean Pub completely agree with you about having more marketing done and stuff like that to help authors get out there in different ways to get out there and hopefully fun ways to get things out there, because when things are fun, you do them more and you do them more often. And so that’s something we’re going to strive for. But, but anyway, Luke, thank you very much for taking the time out of, out of your day to be on the podcast. And thank you very much for being a Lean Pub author. Thank you for having me. It’s been a real honor and I’ve enjoyed it. Thanks. Thanks. And as always, thanks to all of you for listening to this episode of the Front Matter podcast. If you like what you heard, please rate and review it wherever you found it. And if you’d like to be a Lean Pub author, please check out our website at leanpub.com. Thanks.