Kate Mueller: [00:00:04] Welcome to The Not-Boring Tech Writer, a podcast sponsored by KnowledgeOwl. Together, we hear from other writers to explore writing concepts and strategies, deepen our tech writing skills, get inspired, and connect with our distinctly not-boring tech writing community. If you're passionate about documentation, you belong here, no matter your job title or experience level. Welcome!

Kate Mueller: [00:00:29] Hello my lovely, not-boring tech writers. Today I'm pleased to introduce you to Vladimir Izmalkov, an experienced technical communicator who has written documentation in both English and Russian. Over his career, he's assembled and managed a couple documentation teams and has worked on everything from open source to enterprise documentation and almost everything in between. Vladimir, welcome to the pod.

Vladimir Izmalkov: [00:00:54] Oh, thank you very much. And hello. So nice to meet you.

Kate Mueller: [00:00:58] Oh, lovely to meet you. So for those of us who don't know you well, and I would include myself in that category, can you tell me a little bit about your tech writer villain origin story? How did you get into this field in the first place?

Vladimir Izmalkov: [00:01:12] Oh yeah. Sure. After my university, I actually joined the Research Institute, becoming a scientist myself. My passion throughout the childhood and school years was information technologies, mostly computer hardware. So naturally, I joined the Information Communication Center section of the research institute. But the application field of work was mostly emergency response, helping people in disaster recovery situations. So basically, I was in the field of studying how we can use information technologies and communication systems to help people in disasters. I quite enjoyed the experience. I joined as a junior researcher there, and basically the first task I was given was a kind of a huge set of documents called technical project of a system called system 102. That's like the system implementing a single emergency number in Russia, but in one particular region of Russia, if I remember correctly, it was Vladimirskaya Oblast Vladimir region. It's a region named basically by my name, my first name. Don't get confused.

Kate Mueller: [00:02:21] No relation, though, right? You just happened to get the project.

Vladimir Izmalkov: [00:02:24] Yeah, it's just pure coincidence. But I quite enjoyed the experience because it was my first time learning about such an interesting system. Obviously, I was provided with some documentation and standards and some expected requirements, but the document was huge and it required a lot of attention and a lot of just being brave and boldly go and read the whole thing to figure out what's wrong with it. And of course, since I was very inexperienced at the time, I was given a task to find something, and I found a few issues with the document and I was quite proud of myself. And basically the document itself. The set of documents was about 100 pages long and it was a very tough to read document. It wasn't a user-oriented document. It was a very bureaucratic speech kind of stuff. And I was very proud of myself actually finding something to be able to highlight for improvement. Let's put it like that.

Kate Mueller: [00:03:26] 100 pages of wading through dense bureaucratic text. I mean, yes, the fact you came away with anything from that is an accomplishment.

Vladimir Izmalkov: [00:03:36] Yeah. But I felt a very interesting curiosity about this because the topic was such a new topic for me and it was a very interesting one. It was for helping people, very practical in a way. So it was exactly what I wanted after university, after studying all this stuff that you cannot even imagine how you would use in your real life, and now I was doing something actually useful, actually helping people, you see. So it was very refreshing at the time.

Kate Mueller: [00:04:05] That's fantastic. So how did you go from working at a research institute to being a technical writer? How did that happen? How did that transition go?

Vladimir Izmalkov: [00:04:17] Like I said, I had this interest in information technologies and computer hardware. So naturally working in this Information Communication Center of the research institute, I was all around technologies and how to apply them and all about newest tech, both software and hardware. At that time, after like 8 or 9 years in the institute, I just got bored of the governmental body bureaucracy and inefficiency. So I wanted to try something enterprise-ey and after analyzing my skill set, I figured that I'm rather good with documents like I've been reading and writing them all this time. I know a lot about standardization in the fields of documentation and technologies, and also I have quite a wide area of knowledge about all the latest tech again: software development, life cycle, hardware testing, acceptance testing, anything really. So a very wide area of knowledge. And I figured that this skill set actually can be quite useful for someone who I figured called technical writer or someone who works with documentation. So it took me about two months to realize that this is the name of my future profession.

Kate Mueller: [00:05:34] I would say you're not alone in that. I think a lot of people kind of fall into the profession after doing something else, and then they find that there's an actual profession for this thing that they have some skills for and some interest in doing. And then it's really exciting because you have a title to look for, right? Roles to actually seek out and potentially get.

Vladimir Izmalkov: [00:05:56] Yeah, it is very interesting how basically, I figure that I can be a technical writer. And when I got into the role, I figured that a technical writer can be so many different things, you see. There are so many different people who can and should call themselves technical writers, but they do such different things with all kinds of different technologies, all kinds of different fields of study. That's also very inspiring to me because I was, again, always a person who struggles to stay on a single topic for too long. Basically, it becomes a little bit boring for me. So I am always constantly seeking for something to learn, something to explore. So I never get bored with this because I can always learn something new as a technical writer.

Kate Mueller: [00:06:41] It's true. It's true. Whether it's the tech stack for the writing itself, whether it's the domain that you're working in, the company you're working for, the skill set is so broadly applicable that there's a ton of places that you can move when you do get tired of whatever particular thing you're working on. And for me it’s one of the most delightful things about working in this field is like, “Oh, when I get tired of doing this thing, my skill set is useful in all these other places.” And I think there's something a lot of us have in that we are kind of curious. We're used to having to learn stuff really quickly and try to get up to speed on it. And so that means that we can go learn new tools, new processes, whatever really quickly. So we become effective fairly quickly. But also it's not intimidating to go learn a new thing because it's kind of part of the job, right?

Vladimir Izmalkov: [00:07:36] Exactly. It's part of the job to go there with a very exploratory mindset, basically being curious about the topic. And I quite often find myself talking to very smart people about topics that they know a lot about. Basically, they created the stuff that we are documenting, but I know much less about. So I constantly find myself asking somewhat simpler questions. Some might even say asking stupid questions, but there are no not really stupid questions because I ask them from the perspective of our users. Basically, I'm being an advocate for our users. If I ask them, the chances are that our users will struggle with this topic and would like to find more about it. So I myself find it pleasurable in advocating for users, kind of representing their best interests and also guiding them in a way through my documentation.

Kate Mueller: [00:08:26] It's a really great way of describing the dual role because on the one hand, you're trying to create really good documentation for those users. But on the other hand, you do end up filling this voice of user role or user advocacy role as you are talking to the folks who actually built/designed the thing and trying to translate all of the amazingness that is in their head about what they did into terms that that user can understand and actually benefit from.

Vladimir Izmalkov: [00:09:00] Yep. User-centric communication, I think it’s key for efficiency. Basically, we can think about so many different things we can improve in documentation, but I always ask myself whether that actually improves someone's life, basically. Whether we’re doing that because we think that that's better just because it's better for some reason of our own, some internal feeling, or whether we do that specifically to optimize the user experience or flow of their day to day task or something, something they will experience, basically, whether we think about them or us or our model, our mental model of how it should work.

Kate Mueller: [00:09:41] Yeah, yeah. Who are we centering there and what does that mean? In many ways, that does still feel like a natural extension of your kind of shift from school into the research institute, from a whole bunch of theoretical conceptual stuff, to I want to do something that's actually practical and hands on and makes a difference out there. So it may not have been the most linear path, but it does seem like you're kind of continuing that same theme.

Vladimir Izmalkov: [00:10:09] In a way, yes, but I must say that I had to change a lot of my habits and learn a lot of new stuff, because you have to understand, at least back in Russia, the science in general is not about being very inclusive and accessible to people. It's all about overcomplicating stuff, basically to sound smart, sound complicated, that we did a lot of stuff. So basically we do some simple work well, relatively simple, like analyzing something and making conclusions. But then we have to write a report. And the report must represent this work as something grandiose that they should pay us more to do. That's the usual setup, like everyone does that, unfortunately. But if you think about it, the stuff that we do in real enterprise-ey technical documentation is the opposite: we have a complicated product, but we want to simplify the experience to make the product easier to use, to make less number of steps necessary, to optimize for better user experience. So in a way, instead of complicated instructions, we try to simplify it and make it very accessible and easy to read and use.

Kate Mueller: [00:11:18] Instead of from simple things to complicated docs, you go from complicated thing to simplified docs. Ideally, anyway, not always and it doesn't always work out that way, but it's a great goal, right?

Vladimir Izmalkov: [00:11:31] Yeah. And I quite enjoy this transition. So creating, working with complexity in general in life, making things simpler for people to enjoy them with less effort and less time spent. I mean, that's something you can definitely feel you're making the world better.

Kate Mueller: [00:11:51] Yes, yes, this is exactly my own feeling about doing technical documentation. You make life a little bit easier, a little bit better for somebody else. And boy, do we need more of that in the world just in general at this point. Everything feels complicated, everything feels a little overwhelming. And isn't it great when like some little piece of somebody's day was more pleasant, easier, whatever, because of something that we created and put out into the world. It's such a good feeling. Now, we don't always get to directly see that, but just knowing that that's a thing out there is fantastic.

Vladimir Izmalkov: [00:12:29] Yeah. Fortunately, I had the experience working directly with some clients, and they expressed their gratitude for such great documentation that helped them a lot, but it's not always possible. Sometimes you write this documentation and you don't have a direct line of feedback from your clients, your users. And that's probably one of the hardest parts of this job. If I have a role where I don't see users directly and I cannot communicate with them, that makes it very tough because I have to put this model like me, have to imagine basically what users want, what they like, what they don't like, how they think. But I cannot test this model. I cannot verify it. So it involves a lot of mental exercise to make sure that the model stays correct. But there is always some doubt.

Kate Mueller: [00:13:20] Yes, yes. Although maybe the doubt also keeps us a little bit humble, so I'm not sure it's a terrible thing, but. So what are you doing now? So we have this sort of research background that you did. And then you discovered tech writing as an actual role and shifted into that. And then what has happened between then to take you to where you are now?

Vladimir Izmalkov: [00:13:41] Well, that's a very interesting story because I managed to actually relocate to a different country using my, well, professional expertise and just obtaining employment here in the United Kingdom through my job as technical writer. Basically, I got a job in a smaller startup in London and they paid for my relocation, for my visa, and sponsored my skilled worker visa. Yeah, I'm very grateful for them. And it was actually a very, very interesting job. I learned a lot from there. They were like just a couple dozen of people at the time, and they were all very highly skilled and highly motivated engineers. And it was such a pleasure working with such people and in such a new environment for me. I don't know, I quite enjoyed the experience and it gave me a lot in a sense of experience, in a sense of learning, expanding my view of the world, even, you see. It gave me so much. And I find myself in a very interesting situation professionally, too, because I was here in London in a quite new area, working with the technical documentation of a database, which I did a lot previously. But the approach I've been doing since it was a small startup was again, not just technical documentation for the sake of technical documentation, but also a little bit of advertising, just a little bit because again, it's an open source database. So we need to get these people on board with using our database. But the database itself was built on a very novel principle, so we have to explain a lot, and we had to do it in a very inspiring way, so people don't get bored, they get inspired to actually use this stuff. It was quite a challenge, and I think it was again, quite fun.

Kate Mueller: [00:15:26] And was that the first time you'd had to do sort of like that marketing type of writing?

Vladimir Izmalkov: [00:15:31] Well, it was not fully marketing. I'm not a marketing person fortunately or not. I tried my best at combining technical documentation with marketing, which I have to admit, I do not enjoy doing that in general, because I totally believe that these two types of content, they pursue very different purposes. Basically, marketing tries to sell you something while technical writing has to be honest, like brutally honest and trustworthy. You see, we should not exchange this trustworthiness for just selling something to people. So you have to be very, very careful when you do that. And I had to, like I said, it was quite a challenge. I had to make some compromises that I didn't like at the time, but they were necessary and it was quite an experience. Not enjoying working with marketing, but still it was quite an interesting experience.

Kate Mueller: [00:16:24] It's an interesting overlap. I've had to do a little bit of this work myself and it's an interesting overlap because you tend to know a great deal about whatever product you're writing about. And so in that sense, you can contribute a lot. But I think there is that little bit of, as you said, we're used to being brutally honest about the limitations of the thing or the things that are a little awkward about it because you're often explaining those things to make someone able to actually use the product in spite of it. And marketing is often the other view, which is like higher level, bigger picture, doesn't this sound amazing? And for me, it was always work to try to strike a balance there and that was often influenced by the other people involved in the project. So I'd write something that I thought was really good, and then sometimes that would be really good and sometimes like, nope, you've got to amp the marketing part of this up. Nobody needs all these details here and you're like, okay, I really don't totally understand how to write about this. I can write about it passionately and positively, but also, I'm not going to tell you it can do something it can't do or make it seem like it's super easy to use when there are some complicated factors that might influence how you use it or whatever. But I think it's a good exercise for us to have to do, to shift into forms of writing that we aren't as comfortable in, even if it's just to be like, wow, I don't ever want to do that again. Or I have a whole new level of respect for people who do that type of writing all the time, because I don't think I could do it. I think those are always useful experiences, but sometimes they just make me very thankful for the type of writing I get to do most of the time instead. And so how long were you with this little startup?

Vladimir Izmalkov: [00:18:18] I think it was one and a half years. And then there was some kind of a turbulence in the startup. Usually startups have a little bit of turbulence. And I figured that basically I wanted something a little bit more stable in terms of my employment, because my visa in the country also depends on my employment.

Kate Mueller: [00:18:35] Yes. You need some stability there because you don't want to have to leave the country. Right.

Vladimir Izmalkov: [00:18:40] Exactly. So I kind of started looking around and I found this bigger company, which actually has quite a name in open source. It's called Canonical. So I got into Canonical, and they are very famous with their very elaborate process of hiring, basically taking a lot of time and a lot of stages. And I definitely remember also going through all of them. And I think in total, it took me about six months to complete the whole process up to the hiring moment.

Kate Mueller: [00:19:10] I have heard it's quite elaborate, the materials you complete, kind of how the whole process works. It feels a little bit like if you can make it through the process, that alone is a mark in your favor because you actually completed all of the things. So how long have you been with Canonical then?

Vladimir Izmalkov: [00:19:28] I think it's been two years that I've been with Canonical. Again, it's quite a different company, not a small startup, of course. It's a very, very special company. It's very unique. It has nothing to do with anything I did before in terms of organization and how the company works. It's so unique as in really, we have a lot of things going on in documentation practice team, and basically we even call ourselves differently. We call ourselves technical authors in Canonical, not technical writers. And the idea behind that is that we are supposed to have this authority over documentation. So instead of expecting that we will write all the documentation, we expect our engineers to actually participate in the process and write the content. While technical authors maintain authority over the documentation, take decisions also, of course, edit and review the content and collaborate with engineers to create better content and improve the existing one. So it's a very collaborative process involving lots of human interaction, lots of guidance, mentorship, influence. So yeah, it's a very, very different kind of work, I would say.

Kate Mueller: [00:20:40] Yeah. And I like the distinction between technical writer and technical author. That's not one I've heard before. So that's interesting, I like it as a distinction, I think, to kind of differentiate between anybody who might be tossing some content in, in some way, shape or form versus people. I like that idea around like, who has authority to make decisions about some of the larger questions here? Do you find yourself preferring that title now that you have it?

Vladimir Izmalkov: [00:21:12] Well, I never actually had a very strong opinion on how I should be called. I really like technical writer, it’s the most generic term used for the profession combining all kinds of different professionals. Technical author is fine too for me. And if I want to be very, very specific because I mean, usually in conversations, I classify myself as a very technical technical writer, which sounds a little bit silly. So that's why I think on LinkedIn, I named myself a documentation engineer, just to sound a little bit techie.

Kate Mueller: [00:21:46] Maybe that's a little bit of your research institute bureaucracy roots back there, too, trying to make the distinction very clear. I know a lot of folks who talk about being like a more technical technical writer or I would call myself a less technical technical writer. I don't have software development experience, even though I've documented SaaS products for a really long time. And I think that distinction is interesting, whether you call it technical technical, or whether you call it something else. I do think that that level of nuance around what the role can be or could be or is for you is really important. And actually, this might be a great time for us to take a break. So let's do that and we will come back.

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

Kate Mueller: [00:22:56] So, Vladimir, I think we actually ended up on a perfect note to get into the other thing I really wanted to talk to you about. So you have given, I think, at least one presentation on the sort of technical writer skill tree and that there are sort of different flavors of technical writing, different skill sets that might apply to that, and I don't want to make you rehash everything that's in the talks because we will definitely link to them, but I would love to hear you talk a little bit about…maybe let's start with: where did the idea come from for you to tackle this idea of presenting a skill tree for technical writing?

Vladimir Izmalkov: [00:23:38] Yes. My career, my own career as a technical writer was not as straightforward as one could imagine. So at least I had this naive idea in ten years, I guess that my career would be always growing from step to step, and up until very old age, when I would be a very smart person with a very high salary, that I can go on to retirement maybe, and someday. That's like a very linear model, which for me didn't work that well. It's actually the career itself. My career pivoted quite a lot, and I had actually experienced working in many different roles. I was a software engineer. I was like a system administrator, even like leading the IT department of a company. I was a researcher and I actually led a research department. It's not like the whole research department of all research in the company, but rather one research department for one topic. So not that big. And I also quite enjoyed most of these roles. And when I became a technical writer, I figured that a lot of this experience actually helps me a lot, not just by providing a wide field of knowledge that I can use, but also I can use the skills like I can apply, I can genuinely apply some skills from here and there in technical writing, and that helps. And that made me think that maybe the technical writing itself is not as simple a craft as I would think it is. And at some point, probably somewhere like 2024, I started thinking about it as a multi-dimensional problem.

Vladimir Izmalkov: [00:25:12] Basically, when you have some progress in your own personal development in some area, for example, like software development, right? You achieve some goals and then at some point you decide, “Okay, now I want to start working towards my goal in some other area, like communication, like I want to advance in my soft skills, being able to interrogate these engineers to get all the details.” I don't know, something in the lineup. So basically these two different lines of development are completely independent of each other. There is some synergy between some of the lines, but you can imagine them as being completely independent at first. So they to me felt like dimensions, like basically multi-dimensional fields where if you move in one dimension, it does not move you in another dimension. So whenever you advance somewhere, it does not say a lot about some other dimensions. It has no detrimental effect but has no positive effect. So it's just independent. So if we think that in that way, we can actually map some kind of a full skill set of a person in a set of dimensions and imagine that these multidimensional spaces that they occupy, that's their professional expertise. And that could be big, that could be small, that could have weird shapes and forms, of course, but it's unique to this person. And of course, it's really hard to have a judgment on a person's full set of skills and knowledge.

Vladimir Izmalkov: [00:26:40] And it's really hard to actually visualize such a multidimensional system, you see. How do you even put that? Visualization is a problem. So I started thinking somewhere around last year how to do that. And I thought about the skill tree idea. Basically the usual way to represent skills is through a graph. Basically we have role playing games, computer games, RPG style. They have this notion of a skill tree where you have all these branches of different skills, you have these professions and you have even sometimes tabs to switch between skill trees of different classes. And then I got the idea, okay, classes. So if we have one class with one skill tree, then we have another class with a different skill tree and they are independent and that's what we're looking for. And that's where I started thinking that we can combine the idea of a graph, but also the idea of independent branches of a graph. And you can improve yourself in all kinds of different variants on the same skill tree in this way. So I tried to visualize that, and I made it basically a talk that I presented at the ICC conference last year, and it also got published. There is also a video on YouTube about this technical writers skill tree. And I also made it published like an article in Communicator Journal.

Vladimir Izmalkov: [00:28:03] So the idea behind that is that we can imagine that as a class just for our own better understanding, to understand specialization. For example, a writer class who specializes in linguistics, right? There are a bunch of skills that you can imagine would be useful for a person who just wants to write better, who wants to specialize in that. And there can be a bunch of other classes, for example, like, I don't know, some kind of an engineer who is tech-curious, who can easily understand some field of knowledge, for example, software development, and rather simply go and figure some technical aspects out. Or docs tool sage, how I call it, I like quirky names. Basically, a person who really likes automation and building the documentation with all kinds of different tooling, could be Docs as Code, could be something else. Also, there could be marketeer as I call it, right? So a person who specializes in marketing-oriented content, doesn't have to be like pure marketing materials. It can be like marketing-related documentation, like I said, I once did for a startup. But that can also be like a branch for a team leader, like as a bonus class, which you open when you actually have enough proficiency in other branches. You see, there is some element of gamification here. And if you try to actually take all of them at once, you inevitably need to represent a multidimensional field on some kind of a scale. And in this point, I figured that the best way to do this would be a radar chart.

Vladimir Izmalkov: [00:29:40] Basically, the radar chart has these axes like multiple of those, how many you want. And if we have like, I don't know, 5 or 6 dimensions, we can put all of them as a single axis. We can put our proficiency in this axis, in this specialization basically there, and just draw a line around it. And we will get an area which represents some kind of a way to put your expertise on a map, to map your expertise. Unfortunately, the scale we will be using is very, how do I put it? It's very simplistic. It's a one dimensional scale, basically from, let's say from 0 to 10 or whatever scale you're using, some imaginary numbers, they don't mean much by themselves. The important part here is what you assign each number to. So to build such a scale, you would have to build a grading system, basically build a leveling system for yourself in this specialization. For example, if I am to be like a writer style character, what would be my levels? Like level zero, I don't know much. I'm just starting. But level ten, I can do everything, like, I'm the hero, and something in between, there will be other levels and you have to put the requirements for each level there to understand which level you are. So unfortunately these levels, they could be very, very different for different roles in different companies, for example, different people, if they try just to grade themselves because some people work with one set of requirements, some people, others.

Vladimir Izmalkov: [00:31:16] I really like to use the example of tooling here. So some people could work with, I don't know, Google Docs, something simple like that, or like Microsoft Office or some other editor. Others work with Docs as Code. Some other people work with DITA, others work with LaTeX. So there are so many different tools and you can be a master of your craft in your own tooling. You can achieve level nine or even ten or whatever the maximum is in your own set of tools, but you don't know much about other tools. So here's the problem. If the company you want to apply for a role in requires a specific set of tools, your other set of tools might not be as relevant, so there needs to be an interesting process where you grade the requirements, judging by what is required by a particular role, for example, a company's job posting. So they need this and this and this. Ideally they also need this and this and this. So you build this grading system judging by the requirements, then you grade yourself. But then you decide, okay, they need DITA, but I don't know DITA. But I have a lot of experience in Docs as Code and I know how DITA works. And I can apply some of my knowledge to learn DITA quite fast because I know what it is about and what's the difference? I don't have practical expertise, but I think I can learn it fast.

Vladimir Izmalkov: [00:32:37] So basically you can build a projection of your skills in a little bit different area with different tooling on the requirements they have. So that would help you represent yourself even during the talks with the hiring person, when they will ask you, “Do you know DITA?” That will come up, that you actually don't have practical experience with DITA, but you have these adjacent skills, let's put it like that, which could help. So this representation, when you're building this grading system, when you're understanding how adjacent skills can be projected on something that the company requires, the whole process helps you to prepare yourself to understand your strongest sides, weaker sides, and how to compensate the weaker sides by all other skills that you also have that can be used, can also be very helpful to boost your profile, basically. So if you think about this as an exercise, sorry, if you build this map, not just for the sake of having a picture and showing it. Here is me, not just for that, but for your own understanding, for your own deeper understanding of your stronger and weaker sides and how you can compensate one with another. I think that helps a lot in your positioning on the market and your negotiation, basically.

Kate Mueller: [00:33:58] There's several things about this approach that I really love. One of them is that idea that there really are very different classes of how you might do this work, what those skill sets might look like, and I would say that there's probably far more than what you've outlined even. And I think that that, that alone is really useful to think about in terms of what do I bring to the table? What am I looking for? What might be close enough to my skill set to be kind of a case I could make if I'm applying for this role, but I also really love that entire idea of the grading system to be able to say, okay, let me rate myself on a few things, but then let me look at this job posting and see which skills it feels like they're looking for. Let me pull a number out of what I think they're looking for here, what level it appears that they have. And then where do I line up with that? Where do I fall short? What can I do about the fact that I fall short? Is there something similar enough in my skill set that I can kind of pitch? “Hey, although I haven't done this exact thing, I've done a similar thing in this other way. I think it would directly apply in these ways, and therefore I'd be able to learn this.” Or almost like an action plan for if I get this job, where are the things that I'm most going to have to improve my skill set? What are the resources I should be looking for now? What do I expect I'm going to have to do in that first week, month, quarter, or whatever it might be to get myself to the level that I think I'm going to have to be at to handle this?

Kate Mueller: [00:35:40] And I think it just takes something that we kind of intuitively feel we need to do, but makes it a very explicit grading process and evaluation process, that feels like it would be incredibly useful for somebody as they were job hunting or as they were considering, maybe like, I'd like to make a pivot a bit within the industry overall, I've always kind of been this kind of writer, but I find that I'm more interested in these things now. How do I improve my skills there so that I could start to actually apply for jobs that are maybe more about docs tooling and automation, or might be more about maybe instructional design or customer education, which I would consider very close to tech writing, but also slightly different.

Kate Mueller: [00:36:30] And so I love it as a concept. Also, I'm a visual person. So just the idea of like, yes, there's a sort of three dimensional blob that represents my unique experience and that there are pieces of that blob that are going to overlap with stuff I'm applying for. And then there are pieces that kind of overlap, but I could stretch to make it work. And then there's some stuff that they're just not going to care about. They won't care about the fact that I have skills in X, Y, and Z because that's not what they're looking for. So let's not play those up so much in my materials or in my interview or whatever. I just think it's a fascinating concept. We will link to what the talks that we can link to, anything else we can link to if other people want to dive into it, just to kind of use it as a self-evaluation tool, I guess I would say. And since you started the work on this, Vladimir, have your thoughts on it changed? Are there areas that you're expanding on it? I feel like when we talked about this, you were like, well, AI has definitely entered the picture. And so I must ask about that.

Vladimir Izmalkov: [00:37:37] Yes. I don't really like talking about AI as a topic because everyone does that and not everyone does that in a good conscience, as in talking about AI just for the sake of talking about it is not that interesting. But in this kind of situation, I think it's justified because I created such a tectonic shift in the field of technical writing and documentation. Because if you think about it, large language models are notorious for creating texts. And yeah, that's basically what we do. So we have to compete against them. But the whole notion of competing against them, it doesn't sit really well with me because when I was trying to use it, I figured out that you shouldn't be competing with me versus AI, because it's so different. It's hard to compare. Yes, of course you can be replaced. In your particular situation, people can tell you, okay, we are laying off people because of AI, but sometimes it's not even the true motive. They say that it is, but sometimes it's not. I think what actually is happening is that instead of having like ten technical writers, a company might decide to downscale to just like 3 or 4. But with AI, these 3 or 4 should be doing more or less the same amount of work, which is, I must say, quite a tough expectation. It's still a very intense work expected from these 3 or 4, and I'm not sure it will play out nicely in the long term for the quality and sustainability of this effort, but I think that will be the goal of many companies in the upcoming years. And in this line of thought, the use of AI tools becomes a mandatory part. So it becomes a very prioritized field of knowledge, or rather a branch of the skill tree.

Vladimir Izmalkov: [00:39:30] But having said that, AI is not as independent as other skill trees. Because if you think about it, almost every other branch of the skill tree can be affected by your usage of AI. By using AI, I can basically write better texts. I can review my text for the sake of tone of voice or for the sake of native language. I'm not native speaker, so AI can help me a lot by rephrasing stuff for it to sound better and how I want it to sound. Setting the tone, setting the nuances that I sometimes struggle to read. And there are so many different other ways I can use it for technical expertise replacement and stuff like that. The problem with that is cognitive depth. If I, as a specialist, I don't know what the good looks like, what the good results should look like, and I cannot recreate it on my own without AI, how do I verify that it did a good job about it? It becomes a very weird situation when you have to trust the AI that it did a good job and you should not do that. So ideally, you have to be able to produce the same result, just much slower and you rely on AI to do it faster, and then you still spend time verifying. So it's still faster, but not as fast as it could be. That's the compromise that we should be taking, and that's part of the AI branch, of course, it's basically an expertise on how to use AI tools in a safe way without risking too much, undermining the trustworthiness of your documentation, without just putting yourself at risk of embarrassment when your documentation contains pure hallucinations and AI sloppy. Just AI slop as a text.

Kate Mueller: [00:41:16] Yeah, it's also interesting, I think sometimes that people assume that the writing is how AI is being used. In the sense that a lot of the writers I've spoken to, where they've had the most successes has been using it to automate some processes around the writing process, so not necessarily to have it be generating text, but potentially to have it help pull in details from help tickets or transcripts of meetings or whatever to just help compile some of that information, which normally would be a completely manual process. And so I think there's also an interesting angle around if you view automation as one of the skills that you're working on, then AI might just be a natural tool to use for that automation component, right? It might help you up your skill there without necessarily touching the writing piece at all, without feeling like you're competing with it, but instead using it to just augment existing skills there. So it is an interesting conversation to me, the different directions people take it. But like, as soon as you mentioned it, I was like, oh, see, to me that almost a little bit falls into maybe docs tool sage as a class. Because if you're thinking about automating, if you're thinking about tool sets, maybe there's something on that side. Perhaps on your engineer side, if you are rapidly trying to, I don't know, prototype a new docs site, perhaps it gets used there. Like there are so many different ways to potentially incorporate it, but doing it in a way that doesn't feel like you're letting AI dominate the entire model also feels important.

Vladimir Izmalkov: [00:43:10] I feel like if we try to feed AI tooling inside the docs sage branch, it will feel like we are trying to feed an elephant inside your wardrobe. It just won't fit. It will occupy too much space. It will dominate for sure. Just because of the sheer power of AI tooling nowadays and all the things it can do, and I think I also have a full video talking about all kinds of different ways of what you can use AI for when you're doing technical documentation. And my least favorite thing to do when I'm creating documentation or working with technical documentation is to actually generate it, like out of scratch, from nothing to a proper document. It's the worst case scenario. I try not to do it anytime. There are so many different ways you can do better than that. And I usually rely on the software development life cycle because I do a lot of software documentation, and I think about it in the same steps as we analyze the requirements. And AI can help you with that. We also gather additional information and context. AI can help you with the research. We also made a draft. AI can help you with the curse of then empty page and some initial draft. Why not? I use it quite a lot for that actually. I draft and then I read it. And I’m like, yeah…

Kate Mueller: [00:44:26] I can do way better than that.

Vladimir Izmalkov: [00:44:28] It's way off and I redo everything, but it actually helps because it's easier going that way, you see, and yada, yada. All the stages. We can use it in such interesting ways. And I think if you just go there and ask it to write you a document from scratch, from nothing into the existence of a proper documentation, that's the worst case scenario. I'm trying not to do that as much as I can, actually. And additional to that, I just wanted to add, because you mentioned automation, recently, I find it a repeating pattern of mine that the biggest success I have using AI is not when I'm trying to use AI to solve some task and then automate this solution, basically running AI each time I need to do it, but rather I'm using AI to create a deterministic solution that I will be automating. So if it's possible, it's not always possible. I try to use AI to create a Python script or another deterministic program that can produce expected results. So I can test this program thoroughly. I can even read the code and understand what it does so I can verify its logic so I can test it and I can be sure of the result. And then I just automate running this program instead of automating running the AI. First of all, it's much cheaper that way because you don't use the tokens each time you run your automation. But secondly, it's much more stable and reliable. And I don't know, I feel like I see this pattern everywhere nowadays.

Kate Mueller: [00:45:54] I've brought up the AI elephant in the room, so hopefully we can ignore it a little bit now. Is there anything aside from AI that you find that you are still kind of chewing on or thinking of expanding or changing as pertains to the skills tree?

Vladimir Izmalkov: [00:46:14] Well, interestingly enough, in my skill tree, I do have a branch of skills for the soft skills, like basically how people can build a rapport and influence and all that. But I still don't have a name, like a quirky name for a character who specialized in that because I feel like all the technical writers should have some kind of proficiency in that. And I'm really struggling at finding a person who would go and just be specializing in soft skills, maybe like some developer relations specialist, but I need a quirky name from, ideally D&D universe style, this kind of stuff.

Kate Mueller: [00:46:50] Oh that's true. Oh, if anybody has an idea for this, please message Vladimir with your naming ideas. Because naming things is the hardest thing, isn't it? It is the hardest thing. Yeah, that and cache management. But I think naming things for me absolutely takes the cake. You want it to be quirky, you want it to kind of fit, but you also need it to be descriptive. I do not have something off the top of my head on this, but I will have to think about it. And if I come up with something at 3 a.m. when I wake up and I'm like, aha, I will shoot you an email and it probably won't happen. But if it does, I will share it with you and it will be amazing.

Vladimir Izmalkov: [00:47:28] Thank you. Oh, I really encourage everyone to share their comments and ideas if they have. Basically, I'm still thinking about expanding this technical writing skill tree. It's just I don't think I can do an exhaustive list of skills. It's not just vast. I think it's almost infinite.

Kate Mueller: [00:47:48] Yeah. And I think it becomes almost like you could sort of provide the model on how somebody could document skills, but that each person might bring to it their own. So many of us have really odd nonlinear work histories. People have done all kinds of different things before they got into tech writing or have taken breaks and done other things and then come back to it in some way. And so there's just this huge amount of unique variability there. And so I think it, I don't know, to me, it also maybe is a bit like, hey, here are ways you can think about your experience that you could then translate into your own version, your own skills, your own whatever, and use those because I think it's as a model, it's useful, and I don't expect it to be exhaustively descriptive of all the possibilities out there, because I just don't think, as you said, they're nearly infinite. People can have so much different experiences. Yeah. Like if I think about my own, I'm like, okay, well, I've done education and training for a long time. Both partnered with my writing and independent of my writing. I did product management for a period of time. I've done a lot of manual testing of software. I give talks a lot. I'm a podcast host. There's a range of skills I have that kind of fall somewhere in my little skill tree, three dimensional amoeba blob.

Kate Mueller: [00:49:20] But I wouldn't expect every writer I meet to have any one of those necessarily. So it's an interesting problem you've given yourself. But I do really love it as just a mental model for thinking about the space and thinking about your skills as they map to jobs or thinking about it in terms of kind of like professional development, like, let me evaluate my skills. What am I seeing out there? What am I interested in? What are the skills I could level up on at this point? And then using that as a way to kind of guide whatever professional development that you do. It's fascinating to me. I love it as a concept. I love the quirky names. I think you've kind of nailed a thing that a lot of us are thinking about here. So I'm glad we got to talk about it. And I guess maybe I will very awkwardly segue from that into my last couple closing questions since we're getting close to time. Vladimir, what is a great piece of advice that you have been given? It does not have to have anything to do with writing, anything to do with career development, anything we've talked about today, just I like really random advice. So what do you have for me?

Vladimir Izmalkov: [00:50:34] I think one of the best pieces of advice I've been given is that at any given time, you should ask yourself whether you're doing the right thing. And the exact wording of the advice was actually a little bit more harsh than that. And I probably won't be able to fully translate it from Russian to English. But the gist of it is that at any given time, just ask yourself whether you're doing the wrong thing, because if you do, just drop it. Just do the right thing, not the wrong thing. And that actually strikes me a lot with a lot of things that I did and then they just sit there and they kind of..they’re there, like, I did them. Yeah, but does anyone need them? Like, does anyone read this piece? Or is it just sitting there because I wanted it to exist? Because I wanted to write it? So yeah, I would say the best advice I've heard so far is thinking about this. Why are you doing something that you're doing right now?

Kate Mueller: [00:51:30] I like that as a good question to ask yourself, and I have already said, I think people should send you feedback on this name. But so that leads me naturally into if they want to get in touch with you, what are the best ways for them to do that?

Vladimir Izmalkov: [00:51:44] Well, it's rather simple. I'm quite open on LinkedIn. So if you contact me on LinkedIn, quite free to communicate. The only thing that I really don't like is when people send me something like a hi without any question or statement.

Kate Mueller: [00:52:00] Are you actually a person, first of all. And second, what on earth do you want?

Vladimir Izmalkov: [00:52:06] I understand that in some cultures it's like it's a norm, but please do send a message with your hi. It's just a common sense of the internet.

Kate Mueller: [00:52:15] Even if it's just, “Hi, I heard you on The Not-Boring Tech Writer and it made me want to reach out.” That's at least some context, folks. You don't even have to get witty and creative here.

Vladimir Izmalkov: [00:52:27] I mean, yeah, just if you're saying hi, I'm quite happy about you just spending some time to send me hi, but we can chat a little bit more than that. If you really want to, I also present on the ADPList as a mentor, so we can actually spend some time discussing your problems and how I can help with them. But I think the best way to contact me would still be LinkedIn.

Kate Mueller: [00:52:50] Okay. And we will provide links to all of the above and Vladimir's talks in the show notes so that you can dive deeper if you want to dive deeper and/or contact him with something other than hi. And I will say, thank you so much for this conversation. It's been a delight.

Vladimir Izmalkov: [00:53:08] Thank you very much. It was a great pleasure to meet you.

Kate Mueller: [00:53:17] The Not-Boring Tech Writer is co-produced by our podcast Head of Operations, Chad Timblin, and me. Post-production is handled by the lovely humans at Astronomic Audio with editing by Dillon, transcription by Madi, and general post-production support by Been and Alex. Our theme song is by Brightside Studio. Our artwork is by Bill Netherlands. You can order The Not-Boring Tech Writer t-shirts, stickers, mugs, and other merch from the Merch tab on thenotboringtechwriter.com. You can check out KnowledgeOwl's products at knowledgeowl.com. And if you want to work with me on docs, knowledge management coaching, or revamping an existing knowledge base, go to knowledgewithsass.com. Until next time, I'm Kate Mueller, and you are the not-boring tech writer.