S5E4 Mastering Project Management as Content Creators with Kieran Morgan

Zohra Mutabanna: 0:04

Hello folks, welcome to season five of Inside Techcom with Zohra Mutabana. This season we are focusing on tools, tips and strategies to elevate your craft. Let's dive right in. Hello folks, welcome to another episode of Inside Techcom with Zohra Mutabanna. Today I have Kieran Morgan. He is an author and an entrepreneur. He's also the founder of Boffin Education. He's passionate about applying his diverse skill set in leadership, operations and documentation to challenge the building of knowledge business. Documentation to challenge the building of knowledge business. He has published Technical Writing Process and the second edition was released recently and we will touch upon that as well. With that, kiran, welcome to my show.

Kieran Morgan: 0:54

Thanks, Zohra, great to be in your show.

Zohra Mutabanna: 0:57

Thank you. How are you doing?

Kieran Morgan: 0:58

I'm a little sleepy at the moment. I have a newborn baby who's a week old now, and my one and a half year old is just in a bit of an adjustment phase. So yeah, you mentioned before, you can see the dark circles and 100%.

Zohra Mutabanna: 1:14

I appreciate you taking the time out to spend with me, away from your newborn. I would not have agreed to it, but thank you so much for giving us the time. So, kieran, tell us a little about yourself.

Kieran Morgan: 1:27

In terms of my background and journey. Well, right now I manage an education and publishing company called Boffin Education and we're a little different to, I guess, existing education companies that just do training and existing publishing companies that just publish books. We're trying to bring those worlds together and publish books and do courses. So that's where I am right now. Of course, we love evidence-based education. We're really passionate about that. So we're all about using principles that are kind of grounded in cognitive psychology. So that's where I'm at right now and you're one of my authors, Zohra, so working on technical documentation management book. So that's fantastic.

Kieran Morgan: 2:11

We love to do things in teams. Look in terms of where I was before, yeah, I've had a lot of roles and really diverse roles, and my last gig was I was doing program management for my state education department here in Australia, which is a really interesting experience for a couple of years helping them transform their business model, their operating model. Before that, I was a senior manager in operations and governance at Telco and then, before that, for about 10 years, I was doing contracting and all sorts of things. So documentation, tech writing, process analysis and project management as well, and also tech docs, project management.

Zohra Mutabanna: 2:48

That is a very diverse background, but first I want to acknowledge that, yes, we are on the team of authors working on our next book. Thanks to Felicia a shout out to her that she got me introduced to you. Without her, I wouldn't have known you. I'm so grateful for that introduction and I'm here today working with you and I'm really looking forward to our journey and also acknowledging the amount of information and knowledge that I have gained just working with some of the spectacular team that I'm on. So thank you for that opportunity. Kiran, you shared your background with us. You talked about program management, doing contracting, your background with us. You talked about program management, doing contracting. All of that For the benefit of my listeners, I want to dive a little bit into what does program management mean, Because I honestly get confused when I hear program management, project management, product management and since you've dabbled in all of these three, it would be great for us to just tease those apart for our benefit.

Kieran Morgan: 3:46

Yeah, sure, I mean like I guess it depends who you talk to. It means different, Of course, Of course. So you know, program management to some people and the Project Management Institute is someone who manages multiple projects, so who has project managers reporting to them. But in some other fields, you know, a program is a project, right, it's just any kind of endeavor. And obviously product management we're all familiar with because lots of tech writers write product documentation. So hopefully your audience is familiar with what product managers do. They make a lot of work for tech writers and project managers.

Zohra Mutabanna: 4:21

Yes, actually, they are our bread and butter. They are our job security, so we ensure that product managers have work for us.

Kieran Morgan: 4:29

Absolutely. I'd like to stand over your shoulder and watch whilst you're literally writing documentation in some cases.

Zohra Mutabanna: 4:35

Yeah, I've been fortunate. They worked with me. Fortunately nobody's looking over my shoulder making sure I'm writing. It's been a very collaborative effort with my product managers. Making sure I'm writing it's been a very collaborative effort with my product managers, so I guess I'm lucky with that. So program management you said it's similar to project management. It's really managing projects, but different industries may refer to it differently. Did I get that right?

Kieran Morgan: 4:58

Yeah, yeah, yep.

Zohra Mutabanna: 5:00

As technical writers, although we are on, I will say, majority companies today are following some flavor of agile software development cycle and with that, you have product managers that you work with, you may have project managers that you work with and you get to work in blocks, in iterative blocks, blocks. However, in those sprint blocks, the project managers are managing projects for development, not for technical writers per se, because we being shared resources, we are on multiple product teams, multiple scrum teams, and I think that is it's great, but also it's a disadvantage, because now it's up to technical writers to manage their own projects and, with you having this experience in project management, I wanted you to share, were you in such role, and if you can share any tips, any strategies that technical writers can take away, because that's something that I always struggle with. If you have any tool strategies, I would love to hear about that.

Kieran Morgan: 6:06

Yeah, sure. So look, I guess for most project managers you know documentation it's just a line item in your schedule. You know user guide finalized and approved at X date, right, which you know. If you're a tech writer, you know actually there's so much that goes into that, you know, so it really doesn't do it justice. And there's so much more that goes into documentation and planning and a documentation project and people don't really pay this justice, even though all of us, you know, even if we're not tech writers, we do documentation projects all the time.

Kieran Morgan: 6:37

You know, if you're working in any sort of modern business or government department, you know you're probably, probably you're doing project plans or briefing notes or or some sort of document and they have to go through layers of review. You know, and that could be a really complex process and particularly for tech writing, when you have to make sure that your documentation is really accurate, the process leading up to that line item user guide approved it's a long process and there's a lot of steps along the way. So one thing I've always been really interested in as well what does the project management of technical documentation look like? That's something I've been doing for a long time over my different roles, particularly my tech writing roles, obviously, and when I was project manager for tech docs at a place called Cochlear as well. So really kind of grappling with that on a kind of global scale with a big global company that does translation as well. Does that answer your question?

Zohra Mutabanna: 7:29

It does. I think I want to go into how does a technical writer, who may be a lone writer or, let's say, on a team, but still managing their individual projects, if you had any suggestions on how they could address, because one of the things that I struggle with is with being on multiple projects. How do I track what those projects are? So if you have any tips to inform how I can do better project management, yeah, sure.

Kieran Morgan: 7:59

So I think the first thing is to kind of recognize that good project management requires a bit of time just in doing that project management aspect. You know, and as tech writers we tend to want to jump into the work feet first and people think project management, they think schedules and Gantt charts, but there's a lot more to it than that, right, and there's really, I guess you know, two main. To me anyway, there's two main sides of project management. And one is the planning. Well, technically, before you start, or you might actually practice to it when you started, that's all the thinking that you need upfront to plan out your project and get it right. And then there's the tracking, which you mentioned, and that's the ongoing phase. So that's the management over the life of the project.

Kieran Morgan: 8:42

And I think you know when it before I did, you know, before I started doing my master's in project management, before I, you know, got more experience in project management like many people, I kind of just lumped them all together. This is project management and it's kind of a lot to chew on, you know it's it's a lot to digest. So I think the first step is understand that. You know it's kind of a two-step process. First you do your planning and that feeds into your ongoing management and you know, starting in that way helps kind of reduce the chaos a little bit. And then, of course, you know planning is a process as well, which I'm happy to talk about.

Zohra Mutabanna: 9:19

Absolutely. I think that would be great and I like how you have split that project management, the function, into separate roles, because, yeah, when I think about project management, I'm thinking I'm lumping it all together. Who uses OneNote and she has a planner that she's created for each team that she's on and she has all the high level projects that she's working on for a sprint or for a program increment because we use safe, and then she has it's a chart, it's a simple chart and then as she goes through it, as it moves through the sprint until time to release or go to market, she's tracking it. So it's a very simple way of approaching it and I started copying her approach to project management. As technical writers, we don't have any specific tools to manage. In your opinion, is that a good way, or is there a better way that we could approach this using simple tools that we have for access?

Kieran Morgan: 10:29

Yeah, that's a really good way. Simple tools are the best and I love just a simple Excel spreadsheet for tracking a project. It's really hard to go past it. It's just so easy to use. There's minimal overhead. Yeah, absolutely, I'd recommend that for the tracking.

Zohra Mutabanna: 10:47

That's awesome. Now you said you could share more about the planning phase. Let's talk about it.

Kieran Morgan: 10:53

Planning is. I mean, that's what feeds into your tracking phase, right. So you know people sort of expect, if they don't have, if they've just sort of dipped their feet into the water of project management, that you know, somehow the tracker is, you know, magically, appears, all you know, nicely formed, or there's the schedule, right and there it is. But there's a lot of work that goes into, you know, producing that, to getting to that point. And if you just kind of jump straight into the tracking stage, you kind of miss this really big, important thinking aspect of project management where you do the hard work that gets you to that point to having a tracker that looks really simple, having a Gantt chart, and basically what that all starts off with is scope definition, right, yeah, which is figuring out well, what have I got to do, what are my deliverables and what are my topics?

Kieran Morgan: 11:40

In our book Technical Writing Process we talk through a really simple kind of scope definition exercise, which is you put together a documentation plan, right, and that talks about your purpose, your audience, your deliverables and who your review team is.

Kieran Morgan: 11:54

That's kind of your fundamentals and in your deliverables, depending on how complex they are, you might have a list of topics, if it's a user guide or something like that, or maybe it's a quick reference guide and it doesn't have a list of topics. You know, if it's a user guide or something like that, or, you know, maybe it's a quick reference guide and it doesn't have a list of topics, it's just an individual document, and that's a great start to planning For many or most technical writing projects. You know, that's kind of what you need to get off the ground and to then put that into your tracker. You know, and that lets you, you can share that with your manager, you can share that with your stakeholders and you can establish, you know, a really good common understanding of you know, this is what I'm meant to produce and these are the dates. And hey, here, all that, here are the people who need to sign off on them, and, oh gosh, it's a lot more people than we expected.

Zohra Mutabanna: 12:34

And yeah, yeah, yeah, that's true. That's true. It's a skill and I think as you grow in your career it's something that you cultivate, or that's what I have experienced, so I can speak for myself. Project management I haven't done any formal education in it, but as you were sharing about how we start thinking about planning the first thing, we we as technical writers who are in agile we start okay, what are the high priority features being developed for a particular sprint? So you're kind of aligning your deliverable and your ask and scope with your product backlog in an agile environment. Would that be right?

Kieran Morgan: 13:18

Oh, yeah, absolutely yeah, yeah, totally. In a natural environment. Even before you align it, the first thing is well, what am I signing up to produce? What is my scope Right? How many deliverables are there? And there's a whole bunch of studies in project management that say that, or they conclude that defining your scope is one of the biggest success factors in projects. Yeah, so I think, even before you align your deliverables with your sprints, you have to, you know, figure out what that list of deliverables is in the first place, and in project management, that's called you know, scope or a work breakdown structure.

Kieran Morgan: 13:52

And the work breakdown structure is something I really love. It's like the greatest tool ever and not many people know about it actually, which is weird, because it's the simplest thing. There are ways to help you figure out visually what do I have to deliver? And basically it's like a tree structure, right? So tech writers should love them, because we all do tree structures and taxonomies all the time. Yeah, it's a table of contents, and that's what a word breakdown structure is. It says look, what do I have to deliver?

Kieran Morgan: 14:19

In descending levels of granularity where I can relate each sub-deliverable backup to the parent. So for tech docs it might look like hey, new product launch. That's my parent at the top of the tree. My next level down is I need a quick reference guide and I need a user guide. Okay, that's my level two and my level three. Well, there won't be anything on. The quick reference guide is what it is, but under my user guide, you know, hey, I might have 20 topics under there. So that's what a work breakdown structure is and that's where I always start and it's just building a really visual picture of what I have to do, what's the scope of my work and then the process that you follow to execute. That. That's kind of like an overlay on top and that's what your status columns are in your status tracker.

Zohra Mutabanna: 15:08

Got it. Now how does that? I guess what I'm taking away from this conversation is also kind of aligning with your content strategy. So that planning phase is also helping you take a step back from just scheduling and thinking about if this is, let's say, a new team that's been put together or a solo technical writer who's got a team that he's on, he or she's on and thinking about okay, what am I going to deliver? As you said, you start thinking about the scope, most importantly, what are the deliverables going to be, and then how am I going to release those? So that ties into the product roadmap and also you're kind of starting to build a content strategy. Am I far-fetched in saying that, or am I on the right track here?

Kieran Morgan: 15:52

I mean, look, ideally you'd have your content strategy before you have your work breakdown structure. But I mean your content strategy might have a list of a whole bunch of deliverables. So I guess you know it's a useful tool that you could use anywhere. Depends how granular you want to go to in your content strategy.

Zohra Mutabanna: 16:09

Awesome, we were going to touch upon Woffin Education. You did mention a little bit about what we are doing. Share with us about your first book, and then we'll talk about the next book as well.

Kieran Morgan: 16:20

Yeah, okay. So the tech writing process yeah, I published that back in 2015. I was the solo writer on that, so I probably spent I don't know maybe two years writing it. I can't remember that. It was a while ago. It wasn't even meant to be a book.

Kieran Morgan: 16:34

So it was kind of like this accidental thing dogs at this biomedical company called Cochlear who make hearing implants for deaf people. It was a really fascinating job but a huge challenge for me because I'd never been in an environment before where I was documenting manufactured products. So that was a whole new world for me. They did translation into 42 languages across the world. They had software products, which was cool as well, but all these hardware products. So when I came in, they'd sort of been through this U-tree structure and they demolished their TechDocs team and it all went scattered to the wind. So I kind of had to invent a TechDocs team from scratch and then go execute with my team. I can't remember how many of them, six or seven or eight. I had to hire them and then we had to execute this really complicated process where there were deliverables for software, deliverables for hardware, all sorts of things. And in doing so I started looking around. I thought, gosh, there's got to be some sort of off-the-shelf framework for doing this. And all I could find at the time was a 1994 book, joanne Hakos, managing your Documentation Projects, which is actually a really fantastic book, but it was really hard to get all of it in Australia back in 2013. So I didn't have much to go on, you know, and eventually we got there right.

Kieran Morgan: 17:51

We developed the process and, through our collective wisdom as tech writers, and we figured it out. We made you know plenty of mistakes along the way, of course, and when I get to the end of it, I thought you know what? Actually, this is a really good process. I've got here for publishing tech docs in a biomedical environment. What if I can kind of make that into a generic version and publish a little guide of it? That's kind of how it started out.

Kieran Morgan: 18:14

I published a generic version that I thought people could apply to any scenario, and it was like a 10,000 word little manual, and I sent that around to some friends and I said hey, karen, this is really cool, you should add this, this and this.

Kieran Morgan: 18:27

So, okay, I added this, this and this and I it grew a little more. I sent it around to some more friends and some colleagues and I just kept getting bigger and bigger and bigger until this thing snowballed into a book and um, and suddenly I was reaching out to tech writers from all around the world and tech docs managers to, you know, help me review it and fine tune it and validate all the templates and everything. And yeah, that was the 2015 book and you know, it seems to have done pretty well. We've sold eight and a half thousand nine thousand copies over the years and people seem to like it. I had a consultant rush up to me at one of the conferences I spoke to and show me this really dog-eared copy of it with all these post-it notes, and that was just fantastic. I was like, wow, people use this thing every day in their daily life and in their work and apply it and they love it, so that's fantastic.

Zohra Mutabanna: 19:16

Well, congratulations. I'm sure a lot of hard work has gone into this production and I have a copy of the latest book, and I will say what I like about it is it is very. It has made information very accessible. It's very easy to read and especially when, as technical writers, we are juggling multiple projects and also doing project management and a zillion other things, you want a book that is going to give it to you straight without having to break your head over it. So I highly recommend to my listeners do check it out, especially if you are new to this role, if you are in a new leadership position, this book will come in extremely handy because it is tailored to technical communicators. I highly recommend that book because I'm using it and very soon it may be a dog-eared copy for me too. I have it sitting on my desk. I do refer to it Absolutely Now. Did you do this writing while you were doing a full-time job?

Kieran Morgan: 20:14

Yeah, I did. Actually, although I had to take, you know I did it on evenings and weekends and I was contracting, so you know I wasn't working every day, I see.

Kieran Morgan: 20:23

Yeah. But look, I did kind of get to the point eventually where I realised, wow, I'm never really going to finish this book if I just do it on weekends and evenings and squeeze in a bit here and there. So I took three months off, yeah, and just to finish it and get it over the line and get it, you know, polished to the level of readability Like you say. Okay, and thank you very much. It is by readable, right, but you know, as every tech knows, the more readable a document is, the simpler it is, the more work you put exactly, exactly.

Zohra Mutabanna: 20:54

Oh my god. I'm so glad you mentioned that because I've been in at companies where the stakeholders that I work with have said how hard is it to write? Of course anybody can write. Yes, anybody can write Absolutely. Content is very easy to create. I was recently talking to somebody and they said content is so easy to create Absolutely, but creating meaningful content that is accessible and that is in plain English is the hardest to write and you validate, so we get each other.

Zohra Mutabanna: 21:23

It's not easy to write content that is easily scannable because there is I believe there is a science to it and you have to approach it with that. As you said, cognitive psychology that informs this process. Now, I haven't done any cognitive psychology, but I have read enough on how we process information, what our attention span is. So you start thinking about accessibility, you start thinking about scannability, you start thinking about findability and then you kind of apply that to the content that you're writing. So I think creating a book or creating any content that requires that approach. There's a lot of work that has gone into it to make it as simple and as accessible as possible to the right audience. We touched upon scoping and we, as technical writers at companies on product teams we have when we start thinking about the project plan now in my with Agile for me, we are mostly doing online content. We are rarely producing any print content. Would the same process apply to the other communication channels, other content type, in your opinion?

Kieran Morgan: 22:33

Yeah, absolutely. I think the process at a high level is pretty. You can abstract it to pretty much any writing projects Plan, design, write, edit, review, translate. If you have to publish, you know that's pretty high level stuff and it's not. You know, it's not meant to kind of be like a straight jacket. The way we've written the process is you well, you can take this process and customize it. And I think in the second edition of the book we have two case studies. So we have a case study of hey is company A, and these are all based on real examples from the writing team.

Kieran Morgan: 23:11

Or you know tech writers we interviewed. You know company A. They're a startup doing agile software development. Here's what their process looks like, you know, and it's quite abridged and straightforward, but it still uses that terminology the phases. Company B is a multinational manufacturing company that does engine parts that go into other machines and ships them all around the world and has printed documentation translated into multiple languages in the box. Yeah, same high-level process, but it's got additional steps that whole translation and production aspect obviously. That whole translation and production aspect, obviously.

Zohra Mutabanna: 23:44

Awesome. Again, coming back to developing these project management skills I mentioned earlier, this is something that I have, over time, learned. Now, if we were to offer some advice, if you were to offer some advice or suggestions to writers who are new in their roles to this profession, what kind of skills would you recommend as they start approaching project management?

Kieran Morgan: 24:13

and I guess my advice would be look, go, get some training. Project management it's not rocket science. But if if you're trying to do it with no you know understanding and just you know you work with project managers and you've seen the output right, You've seen the trackers, you've seen the schedules, Well, you know you might go into it with the wrong impression that that's 100% of what project management is right, but you don't see everything behind it, so you don't understand. Well, what are the steps leading up to that? And, just like technical writing, project management is a process as well and it can be learned and it's pretty straightforward.

Zohra Mutabanna: 24:54

Okay, so I'll be very honest. I have a friend who's a project manager and when I think about the PMI Institute and just the whole process of going through that education and training, it sounds very intimidating as an outsider. And of course, when she talks about her journey it seems very intimidating and I'm thinking I'm a technical writer, I'm working full time, I don't have the chops to go through that education One. I feel sort of deficient because I feel like there's numbers to it and you're learning budgeting and whatnot. So is this really for me? Now my question really is how much do they educate themselves? Because project planning to me seems like there's planning, there's scheduling and probably budgeting as well, and technical writers rarely manage budgeting. So, in your opinion, when you think about these different phases, what should they really focus on when they decide to get themselves educated different?

Kieran Morgan: 25:45

phases. What should they really focus on when they decide to get themselves educated? I would focus on doing a kind of fundamentals project management course. Those things you've mentioned, you know, scheduling, budgeting they all kind of flow from that scope definition that I talked about, right? So once you've got your scope defined, actually it's pretty easy to put that into a schedule. It just kind of translates and flows through and it's pretty easy to put that into a schedule. It just kind of translates and flows through and it's pretty easy to put that into a budget too.

Kieran Morgan: 26:09

And some of this stuff is just like, you know, you just need a bunch of templates and somebody to show you how you know, to kind of walk you through that process one time. So that's the kind of training I'd look for, not for you know, you don't need PMI're unless you're really interested in that. You know which is, which is absolutely fine. But yeah, look for a fundamentals project management course which takes you through the basics of that and that skill set of defining your scope, translating that to a schedule, translating that into a budget. You can take that and apply that to tech writing. If they they're worth their salt, they'll teach you about risk management as well, and those four I think four things I mentioned are essentially they're the top success factors in project management scope definition, cost management, time management, risk management and stakeholder management as well. It's actually a really important aspect.

Zohra Mutabanna: 27:03

Really important. So my follow-up question is for again, as we explore the different options online, one of the things that I wanted to ask was how do you negotiate with stakeholders while you're getting educated? Because that's one of the biggest challenges that I've had. When I am working with stakeholders and setting expectations, I would believe that that is also a part of a project. And what does that look like and what skills do I need to cultivate to improve negotiation skills?

Kieran Morgan: 27:53

And look, I think my answer to that is well, if you follow the process, that will kind of sort itself out. I mean, you don't have to be a kind of influencer extraordinaire or something like that to work your stakeholders. I think you just have to be, you know, a kind of you know, influencer extraordinaire or something like that to you know, to work your stakeholders. I think you just have to follow the process in the right order and try your best. And essentially, you know what does a project management manager do when they're figuring out scope, getting agreement with a project, with their stakeholders. So what they do is you know they might do a scoping workshop, you know. Or, for a tech writer, you might interview your key stakeholders right at the start of the project. What do you expect me to do? And then you put it into a plan. So you've got to document it. It's got to exist outside your head because otherwise you don't have any proof of what's being agreed to. And then you have to socialize your plan. So you know you've talked to your stakeholders, you've extracted the information from them, and this is exactly what project managers do. They might, if they have a massive project, they might have to hold workshops with multiple people. You know, for each project, break it down, get the whiteboard out, get them all in the room, do a few rounds of that and create a breakdown structure For a tech writer. You know, that might just be your documentation plan.

Kieran Morgan: 29:05

And once you've done the interview process, you've extracted the information, you've regurgitated it out on paper. That's great, because you've got an artifact that then everyone can agree on. So that's the first step. You send that around for review. Hopefully all your stakeholders agree on it, or you know. Obviously this is a real chance to apply your active listening skills and show that you know you've been paying attention. So you take on board that feedback and hopefully what you do is come up with, you know, an agreed baseline, which is the hey, this is the package of documents I'm going to deliver and we've all agreed on that, and this is a collaborative process that we've all you know together. So yeah, so hopefully that should be a common understanding collaboration skills, stakeholder interviews.

Zohra Mutabanna: 29:51

These are things that we already do as technical writers, so bringing those into project management, I suppose, is not a hard ask. It's just pivoting a little bit to work on how you are going to lay your documentation plan, since we are talking about specifically for technical communicators. Yes, a doc plan is something. That documentation plan is something that I have used in the past to set those expectations. It's an important artifact that you start with and you build on. In your opinion, what are the most high level items one should have in a documentation plan?

Kieran Morgan: 30:27

It doesn't have to be a full-on project management plan with 15 subsections Purpose, audience, deliverables and e-review team are the essentials. So you can remember that with PAD, or PADRE as we call it in the board Purpose, audience Deliverables and Review Team.

Zohra Mutabanna: 30:48

Interesting. I never knew that.

Kieran Morgan: 30:50

Yeah.

Zohra Mutabanna: 30:51

So the deliverables would also have the timeline. Do we need to be very detailed about our timeline or that is again something that we can negotiate and pivot?

Kieran Morgan: 31:00

on yeah, well, you should negotiate it. So obviously, obviously, the business or the organization, they're going to come to you and say usually, hey, I, I need these documents by x, right, and, and often that's driven by a product launch. So, right, you know, that might not be something that you can negotiate too much, yeah, but if you think it's unreasonable, yeah, of course you should have a discussion. You know, if you've been brought on as a solo tech writer and you think, wow, look, this work looks like the job of a dozen tech writers, well, that's not good and you need that discussion up front. So, yeah, in your documentation plan, alongside your list of deliverables, there should be, you know, some sort of expected delivery date when the organization, your manager, whatever wants to have them published. You might have to work with them to figure out what's realistic, absolutely.

Zohra Mutabanna: 31:51

So, again, with being a solo writer on a team, all the stakeholders want the world of you. They believe that you can deliver everything. And the asks are just coming in over everything. And the asks are just coming in. And that is where I've encountered this in my experience, especially with younger writers. They do not know how to say no and they commit and then later suffer. And I have struggled to. Because I'm not a project manager, I'm not a trained one. It's been hard for me to kind of provide them the right support.

Zohra Mutabanna: 32:28

If somebody is in this sort of a situation, what would you say to them? How do they approach? Because time management is a really big issue in our field and, setting those expectations, it's very hard to say no. I think the reason I'm it may seem like I'm fixated on this question, but I think it's something that also, because we are considered as quote unquote cost centers, we rarely have that seat at the table. Sometimes Somebody else commits for us and then we are trying to do the deliverable. In those sort of scenarios, what do you have to say?

Kieran Morgan: 33:03

Yeah, look, I think it's really essential to be able to gatekeep your own work and, like you say, it's really tempting just to say yes to everything, be the most agreeable and productive person in the team, but that can totally burn you out. So you don't want to do that. You don't want to be in that situation where you're super stressed and overcommitted. And really experienced tech writers and really experienced knowledge workers know how to guard their time really well and they're really good, you know. They're really good at that pushing back. So if you've worked with senior writers or senior folks, you'll find that one thing they're really good at is saying no, and that's okay to do. But look, what I would say to a junior writer is well, firstly, you know, do your planning right. Right, do your documentation plan. Understand what the scope is.

Kieran Morgan: 33:46

So, if somebody asks you to do a new piece of work, how many documents do they want to write? Make a list If it's a big user guide, make a list of topics, try and figure out. Well, how long is this going to take me, you know, if I take a week or three days on each topic, you know, and I have to take, you know, two weeks on reviewing them all. Well, how long do I think it's going to take? Have a try at planning that out. Even if it's not particularly sophisticated, it doesn't matter.

Kieran Morgan: 34:11

That's something you can take to your manager and work with them and say, hey, I've got all this work on and they might not be aware of it because subject matter experts take us. They love to go directly to the most productive tech writer on the team and short circuit everything. You know Person who always says yes. So you got to work with your manager and if they're a good manager, they're going to be someone who can help you. You know. Say no and push back on that and say, hey, sorry, sorry, stakeholder, this is a fantastic piece of work you want me to do, but my managers told me no. So have that conversation. It's essential.

Zohra Mutabanna: 34:47

Yeah, what you brought up is estimation and even for experienced writers sometimes it's very hard to estimate how long this is going to take, especially if it's a whole new set of content and different channels that it's going to be published in. But going back to the basics, let's say I'm writing a user guide or a quick start guide for somebody who has not created that content but is now going to be creating that content, somebody that is new, be it a new writer or just somebody who is experienced, but focusing on something entirely new, a new set of content channels. How do they estimate, not having a baseline? What should they think about?

Kieran Morgan: 35:31

The more experience we have, well, we develop our own baseline.

Zohra Mutabanna: 35:33

Exactly.

Kieran Morgan: 35:35

Becomes a lot easier. You can instantly look at a project Wow, that's got 20 topics. And if you've particularly been in the company for a while, this topic looks like it's on a really tricky module of the new system and I think that's going to take me two weeks. But if you don't have that experience, yeah, what do you do, Right? So, yeah, the first step is, well, like I said, you know I feel like I broke a record to myself, but you've got to figure out the scope. So you've got to break it down and figure out exactly what the topics are. And then, you know, talk to people, right?

Kieran Morgan: 36:07

So, if there are other tech writers around, well, how long does it take them to make a topic at this site? And you can get an idea, and usually there will be someone there who's done some work before who can give you a rough idea of how long it took them. If there absolutely isn't and there isn't anyone there you can talk to and there's no one at all well, you can have a try at it. So you could write a topic or two and say do you manage to look? I really don't know. There's no other tech writers at this fictional company, right? No one's done this before. This is uncharted territory, so I'm going to write one or two topics and then I'm going to figure out and get back to you what the timeline is going to look like, because then I'll have a better idea.

Zohra Mutabanna: 36:46

That's fair. Now, I've not worked for a startup. Usually, with tech companies, you have the benefit of time to create a documentation plan or project plan. With startups, do they have this benefit where they can create these detailed or even high-level documentation plans? Is this something that you recommend? Because I recently attended a webinar where a technical writer who's working in startups talked about how you approach creating content for a startup, but she didn't really touch upon how you project plan for whatever you're going to be working on. But in your opinion, would the process be the same? Or, because you're on this accelerated track, would that process be condensed and is it a good idea to do it when you're in a startup environment?

Kieran Morgan: 37:38

I have a startup, so I can answer that question from my perspective as the founder of a startup. And if I had a tech writer and asked them to produce a bunch of docs and they said, yeah, I'm going to spend, you know, two weeks creating an incredibly exquisitely detailed documentation plan, first I wouldn't be impressed and, like you say, you've got to be mindful of the company scenario. So, you know, if I was in the startup, yeah, I would do a documentation plan because, you know, startups can be pretty chaotic places and people can get swamped with work.

Zohra Mutabanna: 38:14

Yeah.

Kieran Morgan: 38:14

So, even if it's just a list of deliverables, right, that would be a place to start. What are my deliverables, when am I agreed to produce them by, what's the expectation and what do the topics look like underneath them? And I think if you only have that, well, at least you've got your scope defined and you've got a nominal deadline, you know, and that kind of reduces that swirling chaos to a list on it that you can then put in the status tracker and start, you know, tracking and marking down as you hit and complete those live builds. I think that's essential. I would do that anywhere, even a startup.

Zohra Mutabanna: 38:49

That's awesome. It gives me a lot more confidence. A few years ago, I was invited by a startup and I was interviewed and I just, I guess, had this imposter syndrome where I felt like I wasn't good enough and I rejected that offer and for this very reason, where I felt like I was inept. However, now I have some confidence and I feel like, okay, this is up my alley. But one of the things that came up in that interview was budgeting, because they said we have the budget. In case you want to expand the team, so we are hiring you as a loan writer. But if you want to expand the team, so we are hiring you as a loan writer. But if you want to expand the team, now, throughout this conversation that we've had, at least in my experience, I've not had to deal with budgeting. But if we had to add that layer to our project management as a technical writer for a startup, what would your advice be?

Kieran Morgan: 39:40

Yeah, like my advice would be go do that fundamentals course on project management.

Zohra Mutabanna: 39:44

I see.

Kieran Morgan: 39:46

Yeah, equip yourself with that knowledge, but don't be intimidated by it as well. You know, because budgeting is not. It's actually not a complex process and if you look at a budget, you know it breaks down. It's linked to your work breakdown structure, right? So a budget is just transposing the scope of what you have to produce and putting you know like an hourly rate against that, essentially, and then plotting that out for every month. Yeah, so it's pretty straightforward. But maybe you just need the template to do that and actually also realize that it is a two-step process, right?

Kieran Morgan: 40:21

Someone asked for a budget for a tech docs project. You don't just materialize a budget out of the blue. You know. First you have to do that scope definition, figure out what you've got to do like that's that estimation and then you've got to estimate, well, how much work is involved. So, as you mentioned, you've got to know how much time is it going to take me or a writer to write these topics. So that's really important. And then, if you know the scope and you know the work breakdown and you know the effort involved three days to produce a topic or whatever and you know the cost of your tech writers on an hourly basis or a daily basis. Well, that's all you need for your budget. You're ready to go Basically. You just need a template and maybe someone to walk you through that process one time, and it's super straightforward.

Zohra Mutabanna: 41:06

You simplified that so beautifully, Kiran. It doesn't sound as intimidating as I was listening to you share how you can simplify that process by breaking it down. We have covered a good chunk of questions about project management. Is there anything that you would like to add in addition to everything that we've talked about?

Kieran Morgan: 41:27

Well, look, you touched on it before Zohra, you talked about the psychological aspects.

Kieran Morgan: 41:35

Yes, that's also something I'm really interested in. When we were writing the second edition of the tech writing process, we kind of bolted on at this additional layer of information, which is the concepts, right, the why I didn't have that first book. I wanted it to be a really practical book for practitioners. They could just pick up and there wouldn't be any of this annoying, you know irrelevant fluff which explained why you do this. And for the second book I thought, well, no, actually that's a bit of an oversight. I really want to know why. Now, right, so what we started doing is, for every chapter, okay, you want to include screenshots and documentation, you want to include diagrams? Well, why do you do that? So we started going on this journey of well, let's find the why for every practice, every how to do something in tech writing.

Kieran Morgan: 42:25

And we sort of stumbled into this whole field of cognitive psychology, which is really really kind of well known in the field of information and instructional design. It's all based on how the brain works and how we process information and, crazily enough, it's not very big in tech writing, which is weird. That just seems to me like this huge oversight that tech writers, unlike educators, aren't trained in the basics of psychology. So they understand how the brain processes information, right? You know things like what do we have the multimedia learning effect, right? So that's a really simple principle. It's all about words and pictures together, which is something every tech writer does. We know, hey, if we want to create some great documentation, we want to bring words and pictures together and that's really effective and we all know that right, because that's what we all want when we consume documentation. But why is that right and like, okay, I know that instinctively, to be true, that's what a good tech writer does.

Kieran Morgan: 43:23

So if, if you go and you know, delve into cognitive psychology, that gives you the why and actually what it tells you is that your brain kind of has it's like a dual core processing computer, right. One core processes images and one core processes text, and what that means is, if you look at a document with images and text, you're doing that in parallel. So what your brain's doing, it's absorbing almost twice as much information in the same time, and that's why it's good to have images accompanied by text and vice versa. That's the why. So that's the other thing, Zohra, that's the thing that kind of interests me. So if people want to know what the difference is, I guess, between our first and second book. There you go. We've added a bit of interesting. Why is that? Into the second edition?

Zohra Mutabanna: 44:09

It's true that, as a technical writer, until recently I did not think about how psychology informs what I write and why I need to write it a certain way. I believe it was one of my guests who talked about our I think it was from TechSmith, who mentioned our attention spans are so short that, as we are consuming content, we want to accelerate. Our attention spans are so short that you want to push content at a rapid pace so that information overload is happening.

Kieran Morgan: 44:45

Look, I think you want to avoid information overload. That's a thing called the working memory bottleneck, which is really well known in psychology, and the idea is, you know, you've got like, if you imagine, a kind of a bow tie shape, right? So on one side of the bow tie it's got this funnel and that's funneling in all the information from the outside world which is limitless, right, you can, there's so much. There's the internet. I'm looking out the window, there's trees and birds and stuff, right. So there's a lot happening. And then the other side of the funnel, right the other side of the bow tie, is your long-term memory, which is your long-term memory, which is what you actually retain upstairs.

Kieran Morgan: 45:22

And you know that doesn't last. That kind of diminishes over time. We forget things. But you know we can store a lot there. But in order to get there we have to put it through this. You know really narrow choke point, this pinch point called our working memory, where we process information. It's incredibly limited. We can only really grasp two or three, up to four chunks of information at once. That that's what the science tells us absolutely absolutely yeah, right.

Kieran Morgan: 45:50

So people who are really good natural educators or natural you know speakers or presenters they know this intuitively. You know they understand. I don't want to overload my audience with information. Right, really good tech writers know that I don't want to overload my audience with information. Really good tech writers know that I don't want to overload the people with information. That's why I chunk things up.

Zohra Mutabanna: 46:08

And actually this ties back beautifully to project management, and I'll tell you why. As you're doing your scoping and your estimation, you're not writing everything about the product. You are going to write what 80% of your users are going to consume.

Kieran Morgan: 46:24

Yeah.

Zohra Mutabanna: 46:25

Right and address that first, not the edge cases.

Kieran Morgan: 46:31

Yeah, absolutely.

Zohra Mutabanna: 46:32

Right that I think it's called the 80-20 rule. So you start thinking about eventual progressive disclosures. You start small and then you add more layers of content. So, as you're thinking out how the project plan is going to be, what are your deliverables going to be, start thinking about who are the customers that need the most hand-holding, and you're going to address those issues first before you start writing for every audience that exists, because that is humanly not possible. So that also should inform how you project plan. What do you have to say to that? You think I'm thinking right here.

Kieran Morgan: 47:07

Definitely Look. I think that sounds to me like the Pareto principle right, which is the 80-20 rule.

Zohra Mutabanna: 47:13

Yes.

Kieran Morgan: 47:14

And I'm probably hideously misquoting it, but I think it's something like 80% of the problems are caused by 20% of the causes, like that.

Zohra Mutabanna: 47:23

Yeah, that might be right. That might be right and again, I should probably also look it up. I know of the 80-20 rule and when I approach writing, I'm thinking who is the audience, what is the majority of them and how can I solve their problem? That information comes through analytics, through the user-full feedback. So there's this communication loop that has to be set up. So really keeping it simple, keeping it small and iteratively building on it.

Kieran Morgan: 47:50

Some of the principles that we leverage right yeah, absolutely Minimum, viable product of documentation.

Zohra Mutabanna: 47:57

MVP right Absolutely.

Kieran Morgan: 48:01

Same thing for tech writers to go on. We love to document everything right. So same thing for tech writers to go on. You know, we love to document everything right. So same thing to go on a journey where we we have to capture every edge case yeah, yeah, you know, you know that's your natural tendency.

Kieran Morgan: 48:12

Well, you can, you can work to avoid that, but it's something you consciously have to do. I, I know myself I've got to include everything and I have to be conscious. Hey, hang on a minute, what am I here? Let's try and narrow it down to the important stuff.

Zohra Mutabanna: 48:27

Yeah, keeping it simple is important. Sometimes there may be a need to over-communicate, but there also, you need to think about why you need to over-communicate. You have to think about the why. That why is going to be your guide, and that's something that I'm starting to apply to when I'm writing why do I need to say this? And then I tie that to my persona type and say, okay, does this user have the information? If not, it's okay to over-communicate or progressively disclose that in a separate topic so that they don't have everything on one page, because that also creates that information overload. So you can have all that information, but how are you going to chunk it down so that it is consumable and accessible, right? So there are different strategies, but such a fun conversation. Kiran, thank you so much for your time. I want to return you to your family, to your young newborn, and have a great weekend. Thank you so much.

Kieran Morgan: 49:20

My pleasure, Zohra, lovely talking to you, and I your audience, and I'll talk to you soon.

Zohra Mutabanna: 49:27

Subscribe to the podcast on your favorite app, such as Apple, spotify or YouTube Music. For the latest on my show, follow me on LinkedIn or visit me at wwwinsidetechcomshow. Catch you soon on another episode.