Kate Mueller: [00:00:04] Welcome to The Not-Boring Tech Writer, a podcast sponsored by KnowledgeOwl. Together, we explore topics and hear from other writers to help inspire us, deepen our skills and foster our distinctly not-boring tech writing community. Hello my fellow not-boring tech writers. Today I am so delighted to welcome to the podcast a man whose blog posts, social media posts, and Write the Doc Slack posts I have followed for a long time, and I think he does a lot of really interesting thinking about our space in the domain, both now and looking forward. And even if I don't 100% of the time agree with where he thinks we're going, he does always challenge me to think differently about the assumptions that I think I have, and that form of intellectual discourse is so valuable, I think. And I am kind of astounded that he said yes to come on the podcast. So I am incredibly delighted to welcome to the pod, Fabrizio Ferri Benedetti. Fabri, thank you so much for being here.

Fabrizio Ferri Benedetti: [00:01:12] Good day. Thank you. Thanks to you. I'm really glad to be here.

Kate Mueller: [00:01:17] And so for folks who do not know a whole lot about you, I want to start off with, what is your tech writer villain origin story? How did you get into this crazy field that is kind of a field?

Fabrizio Ferri Benedetti: [00:01:29] So I was a psychology, cognitive psychology student in university. And there I realized that I like two things. One is computers, and specifically software. And the other thing that I liked is writing. So communication written form psychology I did like. And I completed my graduate studies, but I realized that I preferred to do experiments with computers, like simulations, the sort of things that also needed to be documented. I hung out more with computer science students than psychology students back then. So everything came together a few years after I left my PhD. Academia sucks, but that's for another topic. Essentially, I found this job offer to become an editor at a website, Softonic was called, where people reviewed software, and I saw that as an opportunity, pretty unique opportunity because I wasn't sure about technical writing back then. I didn't know what it was, exactly. But I did know I wanted to write, blog and be there and explain technology to people, and that was my opportunity to get there and mix those two things that I love with a sprinkle of psychology on top of it. So that's, yeah, I don't know how villainous that is, but, you know.

Kate Mueller: [00:03:01] I like to frame it as, let me hear you monologue a little bit about how this all began. And some people go back as a child, I interacted with blah, blah, blah. And I'm like, wow. I mean, so did I, but I didn't think of tracing the origins of my documenting abilities back that far.

Fabrizio Ferri Benedetti: [00:03:19] Yeah, no meadows, no flowers in my story. Nothing like that. I do have a bit of something quite villainous, which is I got this nickname, my first job, which was Computer Shrink. So I think that hits the spot, I think.

Kate Mueller: [00:03:34] Computer Shrink! Also maybe full circle moment, I think it is your, you have a blog post predicting the future of where tech writing is going in like 2049. And you talk about us becoming technical therapists. So this is just you full circling, getting back to that idea.

Fabrizio Ferri Benedetti: [00:03:51] I think yeah, I mean that's actually like from a very young age, I wanted to talk to computers. That is true. Like, I remember when I first switched on my Commodore 64, I was seven years old and the prompt was saying, ready? And I was like, oh my gosh, I can do like, remember War Games, that movie from 1983? I thought I could do the same, like talking to the computer like that and just typing. And then once I got the first syntax error, it was the dream that broke a bit. But now I feel like we are finally there. And it's interesting because our role as writers now is more relevant than ever, I think because we are, I think, very well positioned to communicate now with large language models and extract the best out of them because we know how to write. So yeah, we are back at square one in a way, but in a different way.

Kate Mueller: [00:04:49] Yeah, in a way that hopefully people recognize the value that we add there sooner rather than later. Talk to me a little bit about your current role. I know you were at Splunk for a while, and I know you've shifted roles somewhat recently. So what are you doing now?

Fabrizio Ferri Benedetti: [00:05:05] So currently I'm a principal technical writer at Elastic taking care of opentelemetry documentation. It's software observability is my field. It's been my field for a few years now and I love it. It's very technical and I get to also do lots of open source contributions, which I love. And that's where I'm currently. Before that, I had a stint at a Spanish startup, and that's where I really got deep into LLMs and using AI at work. It was a very good experience.

Kate Mueller: [00:05:36] Sounds fantastic. I mean, I think it's good to have that diversity of you've worked different places with very different types of roles, really different sizes of organizations, different levels of maturity, because what those things need are often very different tooling, very different skills, and it really helps you kind of stretch as a writer in a lot of ways, and sometimes forces you to learn stuff that you wouldn't have learned any other way, frankly. So we have a lot of folks on here who use different labels. You described your role as principal technical writer, so I'm assuming tech writer is an okay role name for you, but is there one that you would prefer? A label that you would rather use instead of a technical writer?

Fabrizio Ferri Benedetti: [00:06:18] Well, I've been toying with the idea of using Documentation Engineer. That was my previous role at the startup, and I like that because it brings together again the two very important things. One is that you are embedded to an engineering team most of the time at least when doing software documentation. And I think having the engineers in the name really helps bridge somehow that mental distance with the team, although it also comes with expectations that you know your way around the stack and you know how to read the code that they write, etc. and as of late, I've been thinking about like Contexts Engineer, Context Curator, which is very much tied to AI right now.

Kate Mueller: [00:07:05] Yeah.

Fabrizio Ferri Benedetti: [00:07:06] And that's why I've been noticing this trend of developers essentially feeding documentation, writing documentation for the LLMs. They weren't maybe doing it for us before, which is kind of ironic. Now they do it for LLMs. So I feel kind of envious.

Kate Mueller: [00:07:23] They were compelling in a way we were never able to be.

Fabrizio Ferri Benedetti: [00:07:27] Like they like their machines. I get that. But the idea here is that we could assist. We could help them in organizing and curating what they call context, so that coding then becomes easier using those tools.

Kate Mueller: [00:07:42] A kind of pivot a little bit in the emphasis of what you're working on, but not necessarily in a totally different direction, so to speak.

Fabrizio Ferri Benedetti: [00:07:52] Yeah.

Kate Mueller: [00:07:52] Interesting.

Fabrizio Ferri Benedetti: [00:07:53] There's always a bit of shape shifting when it comes to technical writing. And I think it's okay. It's totally okay. Like, we have to take on the shape that best suits the situation at any given moment. We all know that we are. We're just deep down we're writers. We are. All of us are writers. We know that. But then we need to just wear a different hat. And it's totally okay. It's not the end of the world.

Kate Mueller: [00:08:18] No, I like the shape shifting metaphor there, because one of the repeated themes that comes up on this podcast is the fact that we have to learn and adapt a whole lot in the role. And I think shape shifting is a nice way to kind of encapsulate all of that in a single term to be like, different, different roles, you have different organizations you work with, even different projects you work on or different teams you're a part of. Who you are has to shift a little bit to be able to fit into what they need at that given time to produce whatever it is you're supposed to produce.

Fabrizio Ferri Benedetti: [00:08:51] Yeah, we are. It's about being versatile, and it makes even more sense if you are a World of Warcraft player, then you know, if you play, if you play the druid, then you know it will make sense because it's a shape shifting class. You want a tank, it can be a tank. You will be a healer. It can be a healer. That was the nerd moment right now for this podcast.

Kate Mueller: [00:09:14] So world of documentation rather than World of Warcraft and we're all druids in it. There you have it folks.

Fabrizio Ferri Benedetti: [00:09:20] Just think of the possibilities.

Kate Mueller: [00:09:23] So good. That makes me feel so much more positive about the future. So Fabri, I will admit, I'd thought about having you as a guest on the show for a long time, and I had a little bit of, I don't know, I guess I want to say imposter syndrome about asking you on to be like, oh, what am I going to ask him to talk about? And then at some point, you shared the Seven Action Documentation Model, and at that time I had been super into exploring content types. And I got so excited about the model because I felt like a lot of the content type stuff A. is really prescriptive, and B. felt maybe not quite high level enough to me. And what appealed to me about the seven action model was that it felt much more high level and a lot more descriptive rather than prescriptive. And so I was like, you know what? This is it. This is my moment. I'm going to ask him to come on the podcast. I want him to come talk about this model. So can you tell me a bit about how you came up with it? What prompted you to come up with it? Did you just wake up at like 3 a.m. one day and go, aha! Or was it a more slow, deliberate process?

Fabrizio Ferri Benedetti: [00:10:37] Well, there's always this brewing process of course. So it takes a little bit of time. But usually, I'm gonna tell you a secret here. Again, I think this connects well with the super villain theme. Again, my reflections and blog posts start from a feeling of rage, being enraged with something or being upset with something like this cannot be. I regularly follow Hacker News, this tech forum to stay abreast of tech news, and from time to time there's always an article surfacing about documentation or technical writing written by engineers. And it's kind of, it's actually quite nice to see them talk about documentation. It's like, oh dear, discovering documentation, but more like in a, in a cargo cult way. Like, oh, so you know, those planes we're gonna build our plane too and they do this bamboo contraption. And for them, the cargo cult version of documentation are documentation frameworks. Specifically, there's the Diataxis framework, which is nice. It's quite a nice framework, but if folks actually took some time to read all the documentation of that framework, one of the things the framework says is you don't have to follow these to the letter, but of course they all follow this to the letter because that's what a framework is meant for. It was mentioned again in this framework. And I thought, well, how about we technical writers also say something about this and maybe provide our own point of view, because yes, there are comments here and there saying, yeah, this is a nice framework, but reality is much more complex than this.

Fabrizio Ferri Benedetti: [00:12:29] But we never sit down and write about our opinion in full. So we are there just mumbling, which is unfair. Like we have an opinion. We should voice it. So I sat down and wrote this, I didn't want to call it a framework. So I went for the word model, which I think is more neutral. And then seven is kind of catchy because it's also like, yeah, it's a reference to the magic number seven, which is a very famous paper in cognitive psychology. For those of you who don't know, seven is minus plus two is the amount of items that short term memory usually retains. Like you remember, seven words on average, things like that. So seven resonated and yes, as you say, the intent was descriptive. Like it's not a framework, it's not prescriptive. The post I wrote is an invitation to think about what your users are seeking in your documentation or need in your documentation, and build a system out of it. And like, it could be like the start of a taxonomy if you want, or content types or templates, but really focus on the needs, which is a more US oriented approach, I think, to frameworks and such.

Kate Mueller: [00:13:49] Yeah, it's really just sort of a different starting place, I guess, is what I found refreshing about it, that instead of starting with the type of content, you're starting with the users needs and what they might be coming to the docs for, not in terms of like, oh, 'I need a how to thing on this', but in terms of particular sort of needs that they have or actions that they're going to take as a result of finding that. And that for me was a little bit like, okay, I'm gonna try to make people have user empathy without calling it user empathy. I'm instead just going to say, hey, think about this. This is like all of us go to documentation to meet some of these basic needs. Here are those needs. Let's make those explicit. So why don't we kind of walk through the model a little bit for folks who aren't familiar with it, and we can kind of go from there?

Fabrizio Ferri Benedetti: [00:14:41] Yeah. So the model is seven actions, and it's seven actions identified are at least from my point of view you could use others. So the first one is appraisal. And this is something you will seldom see in a classic documentation framework which focuses on the what, the how I do things, etc. and appraisal is a need that users have. Like is this thing for me? Like, is this something I need or not? And that's you could say there's a slight overlap with marketing there. And it's true. I mean, but it's also fine. It's fine to find those points of contact with marketing. Then I don't want to be like the laundry list, but the other dimension that I want to bring out is troubleshooting. Troubleshooting is another one that usually you won't find in documentation frameworks, but it's another reality of our work. Like users will run into trouble because products are not perfect and they will need solutions. And you can provide those. You know what happens if you don't listen to the user's needs? You end up with FAQs. That's what happens. Yes.

Kate Mueller: [00:15:57] Yes it is. Yeah. And actually you hit on the two points that I think most appealed to me in terms of the actions themselves, because that sort of appraising function, we often cede that territory to marketing, and I think that there's sort of two different ways to do that. There's the explicit marketing way, which is typically what happens in marketing websites and all of the copy that gets added there. But then there's the fact that in your documentation, there is a sense of 'I'm trying to give you enough information to figure out if my tool is correct for you, or this feature or function is correct for you'. And that's not necessarily sales, but it is very much an informed decision. Here's what you need to make the informed decision. And people are using your docs that way whether you intend for them to or not. So you might as well be explicit about it.

Fabrizio Ferri Benedetti: [00:16:55] And marketers know that documentation is also a marketing asset. So that's why they're so pushy sometimes. But you know, they have good reasons for that. But the thing is, some users will prefer documentation to find out whether the thing is for them or not, because documentation is by definition, factual. So they will probably trust us more sometimes than some marketing copy. And you can still sell things being factual like well of course it depends on everybody's likings and preferences, but it's like going to a car dealer and instead of listening to the pitch, you focus on, well, what are the specifications? Well, that's not a way of selling.

Kate Mueller: [00:17:34] It is depending on what the person's looking for. Often specifications make a big difference for what people want to buy or don't want to buy. And also to that point, the troubleshooting action. This is something that content types just sort of ignore as a function, I think, because it doesn't necessarily lend itself to a different template layout per se, but it is a very different need. And sometimes that means different forms or functions to achieve that need. And like I loved that you specifically call this out as an action that folks are coming to try to do. I also personally love that you note that if you were mapping these actions to content types, a single content type or a single topic or piece of content might meet multiple needs for an end user and very often does meet multiple needs. So it's not like a 1 to 1 mapping to say. I mean, there are some of them that do lend themselves really nicely to a mapping to a content type, but like appraise is a good example. I think that's a thing that you're probably working into overview pages like even little meta descriptions, you're adding about what certain things are that are just displayed on landing pages. A lot of that are those sort of appraisal signals. And that's not necessarily 'I'm creating a whole document that serves this purpose', but I might have a few sentences or a paragraph or a sentence that's going to help address that need, while what I'm actually putting in here is a totally different type of content overall structuring it differently.

Fabrizio Ferri Benedetti: [00:19:17] Exactly like so, you know, if you have in the end, products can be quite complex. So it's not as easy as saying, well, it has three features and they're all quite like boxes. It's often not like that, especially with very mature products or solutions. But you do have journeys and a discrete journey, meaningful journey or happy paths through a product. Then you can do the check of saying, so for this path, am I, you know, touching upon all the key actions like is the user able to appraise whether they need this? Can they troubleshoot anything? If anything goes wrong with the action, are they able to explore on their own, to experiment, to deepen their knowledge, etc.? So yeah, the thing with action is that there are real tool chests that you can pick tools from and apply to your documentation without having to constrain yourself to a unit of content.

Kate Mueller: [00:20:18] Yeah. And for me, it is also just useful to think about my documentation as a whole. Am I addressing these needs in a broad sense for all of the documentation about X tool, or am I just completely, have I not explicitly addressed some of these? So I'm implicitly addressing them? But I've never given that thought to say, oh yeah, I do have troubleshooting stuff. It's nestled in here. Is that the best place for it? Is that an easy place for somebody to find it on their journey through here, or not? It can help you take that step back to review things like how you're structuring your content, but also stuff like information architecture, content hierarchy, a lot of that. So I find it a really interesting model to use.

Fabrizio Ferri Benedetti: [00:21:07] Now the drawback is that you have to think. So you have to ask yourself questions. And users of frameworks usually are looking for frameworks to avoid thinking sometimes, which is okay. It's understandable because we are, you know, we have so much to do, right? It's totally understandable. But with the framework, you just say, well, there's four content types. I'm just gonna cookie cut everything into those four content types and call it a day. But then you realize that you have content that you don't know where to fit. And that's what happens when you don't spend some time bleeding, sitting on a chair and thinking, like Hemingway used to do and writing, because that's the content strategy work you have to do anyways at some point.

Kate Mueller: [00:21:54] Yeah. I mean, I think that's it is that it's a nice distinction to say that the frameworks are, in essence, whether they're intended this way or not, the way people are using them is as this is exactly what I have to do in the way I need to do it. And to some extent that's useful, especially if you're trying to facilitate contributions from folks who don't want to think about that, don't need to think about that, have no background experience having to think about that. But as actual tech writers thinking about that larger strategy, and are we hitting all of those things can be.

Fabrizio Ferri Benedetti: [00:22:29] Yeah, I think.

Kate Mueller: [00:22:30] And maybe this gets at the core of why I like the model, because I think it gets at some of that larger documentation strategy that we don't necessarily talk about really explicitly in a 'make sure you're doing these things' kinds of ways without being overly prescriptive. I think you walk the line on that really nicely.

Fabrizio Ferri Benedetti: [00:22:50] Yeah. And I think that is also connected. The whole thinking about the strategy or even just thinking is connected to the way I think technical writers should grow. Like one recurrent theme as of late in my blog is that we need to think, we need to go deeper. It's very comforting to just take the handbook or whatever course you took in uni about tech comms and just follow the manual, but that will not lead you to grow. Especially now in this age of change and LLMs and AI.

Kate Mueller: [00:23:26] Yeah, it is a time of a lot of change in the industry in general, but it's also a, I think it's so useful to us to stretch and grow, because very often companies know that they need documentation. They have a feeling that they need a writer, but they don't actually know what the role should look like. And so if you're doing that growth, if you're digging deep into the strategic pieces of that, you can make that role into something that's really engaging and exciting, and you can do stuff that is incredibly useful to the organization you're working with, much more so than if you just come in and follow the manual, basically continue the status quo of whatever had been done before.

Fabrizio Ferri Benedetti: [00:24:07] Yeah. And I think our position is uniquely suited for that thinking activity. Like I often think that we need more humanists in tech or philosophers, more thinkers in general. And you don't see that in companies often. And companies also for again, very understandable reason, try to sometimes just steer people into cookie cutter roles where they do this thing and they follow sprints and you do X tasks. You have such capacity and you do these things and you follow whatever rules are in place and you have linters. So everything is very orderly, very clean. But reality is messy and you need people to think about it. And writers, by definition, are folks who can think very deeply about the situation, any situation. We absorb knowledge. We process that knowledge into something else, and we can be, I think, those humanists, it's those thinkers in tech companies that really bring the depth that sometimes products need.

Kate Mueller: [00:25:24] I think that's a fantastic note for us to pause and take a break on, because I don't think I can think of anything useful to say to that other than yes. So we're going to take a break. We'll come right back.

Kate Mueller: [00:25:36] 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:26:00] And we are back. All right, so Fabri, I want to know because I was thinking about this as I was going through the model. What kind of have you gotten critical pushback or criticism or just general disgruntlement about it at all? And if so, what does that look like?

Fabrizio Ferri Benedetti: [00:26:15] Well, disappointingly, no. I would have. Yeah. I expected actually maybe some pushback or even maybe from the author of the attack whatever actually have good words for the model. But yeah, it was expecting a bit of debate, but I got almost none. And it was kind of disappointing because I wanted a fight. But yeah, but you know, it's tech writers are too nice. We are too nice people. Yeah, I don't know. Like, if you feel like it, send me some negative feedback or opinion, folks.

Kate Mueller: [00:26:47] There it is. If you have feelings about the model, Fabbri isn't just inviting you to flood his inbox.

Fabrizio Ferri Benedetti: [00:26:53] With, you know, more seriously, I think we need more debate and more discussions and in a polite, almost academic way, if you want. Getting into a fight for an Oxford comma is something we do sometimes. But we should not just argue over petty little details like that. Let's also talk about the bigger picture. And like a model for example, is a wonderful opportunity for that. So yeah, I welcome that sort of discussion. I would love to see them more often.

Kate Mueller: [00:27:27] Yeah. Same. I mean I think we don't have a lot of these kind of big picture strategy models or frameworks to work with. And that feels like a whole in the domain. But also if people aren't engaging with the stuff that's out there, maybe it's less of a whole, I don't know, I feel like it's a whole. Right. I'd love to have more of that. So I will admit I have not yet tried to apply this model in my documentation. I have spent a bunch of time thinking about it, which is not at all the same thing. But I'm curious, have you done an application on it? Or do you know anybody who has that? You might have some feedback around it.

Fabrizio Ferri Benedetti: [00:28:10] So I also haven't received much feedback yet. And as for myself, I am applying it, although it's not in a systematic way like I'm not. I've just joined this new position and every technical writing shop has their own point of view and model already existing, etc. so it's easier to do, perhaps in a startup when you're starting from scratch, which is something I only had the opportunity to do once. Otherwise, I think, and this is another thing that is interesting is, a model like this is not like a programming framework that you need to apply in its totality. A framework you have, you would have to like to do a refactor. If you're talking about code, if you're talking about docs, you would have to rewrite everything. No, I think a model can be something even like your own brand of model. You can have your own personal model, and you can apply it to the documentation you write and adapt to whatever style guide, to whatever content templates you are agreed upon at work. You don't have to impose it. So in my case, the question, for example, of am I addressing the need for appraisal? Because I strongly believe that need is something that I always asked myself when planning a new documentation set with the tools I have at my work. So a model is something that you apply always if at whatever job and whatever tools you have at your disposal, because it's your model of reference that you have in your mind to write a docs. So it's actually quite flexible in that sense.

Kate Mueller: [00:29:48] I will say what's been interesting about it for me, so I've been slowly overhauling all of my feature documentation for much of this year, partially through the lens of content types, because my documentation set historically hasn't had consistent templates and structures used. That's mostly my fault. I inherited it, but I didn't commit to it until this year. But over the course of the year, I made a bunch of decisions about the content hierarchy within each feature. And I definitely did not follow, like I'm going to have a thing for each diataxis types. I don't like for me, for my features, for my users that did not feel like the right architectural choice. But in looking through the model, I realized that I had made choices based on user needs instead, and that that's the information architecture I backed myself into by accident, being like, oh, this isn't like I'm using content types to kind of inform individual pages. To be sure I'm structuring stuff consistently when it's the similar type of thing. But in terms of how I'm laying out the content hierarchy, the labels that I'm using for that hierarchy, I didn't realize this until I read the model, and then I was like, oh, that's how I've been making these choices, but I've been doing it without explicitly applying a model, just doing it from a gut place.

Fabrizio Ferri Benedetti: [00:31:17] That's the thing. Yeah. I mean, one of the things I also stress out in that blog post is that you have to find your own model, and you probably have an inner model already of what you believe documentation should help with and contain and address. So it's about surfacing it a bit. And here again I'm being the shrink. So you see, the curse is still there.

Kate Mueller: [00:31:41] It's there for you always.

Fabrizio Ferri Benedetti: [00:31:43] Always always always. And yeah, and then the other interesting thing you said you talked about is content templates. The interesting thing is that when you realize the purpose, when you make that model available to your consciousness and you know what you're doing and why you want to do it, the content type becomes a tool in service of that purpose instead of you serving the tool. That's probably the thing that enraged me the most was seeing folks trying to appease the framework. No, the framework is there to help you write what you want to do.

Kate Mueller: [00:32:20] Yeah, I've seen at least one long blog post from someone trying to kind of make the diataxis content types fit their ideas about what purpose documentation serves, and they got there eventually, but had to adapt the framework, and it seemed like it caused them just a great deal of stress to get there. And I was like, I feel like you're interpreting this a little too literally. But on the flip side, I think there is something really important about having that dialog with the framework or model to say, okay, it's making these things explicit, and that has caused me to realize that. I'm not sure I agree with that entirely. And it helps surface that internal model that you don't know. You have to be like, oh, I actually believe really strongly about appraisal, and that's not in here at all. And now that I know that I can kind of adjust my own mental model or my own mental checklist to be like, are my docs doing this? And so it's not necessarily about rigidly following the thing to a T, but using it as a tool to kind of force yourself to surface. These are my beliefs about documentation, or, as a team, what does this make us respond to? Can we come to some sort of consensus on what we care about in our documentation and use this model or framework just as a way to kind of force that conversation? So we're talking about the same things, right?

Fabrizio Ferri Benedetti: [00:33:55] Yeah. It's quite a realization, right, to find out that we can hold beliefs like developers do. Like they have lots of them. Like I prefer C instead of C++, or Java is better than Python, or whatever. And they have lots of those opinions, and so why not us?

Kate Mueller: [00:34:13] Yeah. So we're allowed to be opinionated. That's just kind of how it is. And let's be real, we're all opinionated anyway. It's not like any of us is not opinionated. We just like to pretend that we're not. Let's just own that and recognize that those opinions, whether we're aware of them or not, are informing the decisions that we're making. And leveraging models like this or frameworks helps you better understand what those opinions are so you can name them. You can actually make a conscious choice about whether that's a thing you want to incorporate or not. I love the feel of that, making it a more of a thoughtful, deliberate choice instead of I'm just knee jerk applying this and I can't tell you why. So, Fabri, I want to pick up on a thread we've kind of touched on already in this episode in terms of the idea of being shapeshifters, the idea of having to kind of grow with what's happening in the world around us, particularly right now. And it's a thing that I see a lot in the communities is that idea of like, okay, I'm a tech writer. How do I grow and develop further, even if I'm in the same role I've always been in, or the same type of organization I've always been in? And you've done this a lot. So I'm hoping and you've written about it a fair amount as well. So I'm hoping I can pick your brain a little bit here.

Fabrizio Ferri Benedetti: [00:35:38] Yeah. So there's always the risk with any position, not just ours, to feel like you've reached a plateau and you feel like there's no growth, that everything is stagnant. I think there's always the risk of incurring into that situation. But that feeling usually surfaces when you reach senior level. The thing I like to ask everybody to invite everybody to think about is what seniority really means and is not. It should not be about the amount of time you spend at a company. Or it could be, but I think that's a poor criterion for seniority. Like, you are there and it's like a senior resident. It's not really descriptive of your skills or capacity, and it's not really.

Kate Mueller: [00:36:31] Descriptive of your longevity there.

Fabrizio Ferri Benedetti: [00:36:34] Exactly. Your longevity. That's the word. So that's what I call stagnant seniority. Like you are essentially, you're plateaued and you're stuck and you feel like there's no growth. Everything is very stable. On the other hand, there's a pattern which I call dynamic seniority, which looks more like a ladder, like you are in a period of stability, and then all of a sudden you climb up and your skills go up and your capacity, your maturity in a role also goes up with it. And there's two important things here. One is growing like that, which is like, real growth requires that you have optimal circumstances around you. That means you are in an environment where you can't actually do the sort of dynamic growth, and that they will not cause you issues. You're in a good company, literally, and you can do that. And also you have to like what you're doing. And that's the other side of the coin. Like it's totally fine to do a job you don't particularly like. And there are folks who do it very well even though they don't like it. But to grow in a job like that without liking it, without loving it is almost impossible. Like, I don't recommend trying. So if you like your job and you have a good environment around you that supports your growth, then yes, by all means try this.

Kate Mueller: [00:38:06] If these perfect sets of circumstances exist, which I think that's the work environment we all want to be in, is the support for me growing. And also I'm doing a role that I actually want to continue growing. And I think a lot of us have that to varying degrees. Or maybe we definitely personally want to keep growing, even if the way that the organization is structured doesn't necessarily naturally support it, as long as it's not explicitly discouraging you from doing it, there's opportunity there for you to flex a little bit, right?

Fabrizio Ferri Benedetti: [00:38:44] Yeah. And if not, if not at your everyday job, it could be on the side. I mean, because there's also the matter of capacity or being the lone rider of the company, which is always complicated. But one of the points I make in my blog is the amount of work you pull is never enough to grow like it's not about volume. It's not about the quantity of work these days especially. It's more about the quality, about how different your work can be. And well, this comes with the smart work. I don't like that expression. To me it's more about doing work that is more meaningful and not just more work, you know. I say this because sometimes I see folks wondering, 'why don't I get promoted', 'why I'm not growing if I'm doing, like I'm closing so many issues and I'm doing so many comments to the docs', but that's just volume. It's not scaling your capacity, it's just scaling your work. You know what I mean? Like, an LLM could eventually do all that for you tomorrow. So then where's the value you're bringing?

Kate Mueller: [00:39:58] Yeah. If most of what you're doing is tidying up content, for example, at no point in there are you demonstrating additional skills, you're not contributing in a strategic way to what's happening within the organization or within the documentation. And so you're not seeing, how do I say this? You aren't seen as an expert in that sense. You're just seen as a worker. You're like a cog in the machine that does this. And eventually that cog might be replaced by automation, depending on what type of content tidying you're doing. Right. If you are looking at it, I want to redo our entire information architecture because it doesn't feel right, or, I've been exploring these new tooling options that could help streamline this part of our process, or reduce manual stuff, or make it easier for contributors to actually contribute. It's those kinds of things where you kind of have to show that you are a strategic partner or a strategic thinker instead. Right.

Fabrizio Ferri Benedetti: [00:41:02] It's totally fine to have phases like that. Like you don't have to grow constantly. That's why the pattern I describe is like a letter. Because like continuous growth, exponential growth is impossible. It's not healthy. So it's fine to have. I also had those spaces where I felt like a gardener of content, happy with these flowers and tending to the quality, doing maintenance work. And sometimes you need that to recharge. So it's good. It's good to do that. But otherwise what you need to grow is three things right, and at least three. These three things in this blog post about growth are restlessness, courage, and generosity. Starting from courage in the sense of seeking the storms. Like where the real problems are. So go there. Go to where the problems are, and don't be afraid. Restlessness is about exploring, trying to find new ways of doing the same things, or trying to find ways to do the same things faster or better, or even just in a more satisfying way. Sometimes it's just that quality of feeling better about what you're doing. And lastly, generosity is about sharing all that you've learned with others. And I think that's where growth also happens.

Kate Mueller: [00:42:27] Also, generosity can lead you to acquire skills or knowledge in a different way, in the sense that if you know you're going to be sharing this with others, or you're going to be trying to teach it to other people, you learn it in a detailed or more internalized way than you do if you're just sort of like doing it for yourself, at least for me, this is true. Like I've been working on prepping this information architecture class I'm teaching, and it has taken me so far down into theories and concepts and different approaches to handling it that I probably wouldn't have gotten to if I was just like, oh, what do I want to change about my information architecture? And instead of being like, I'm going to try to teach other people how to think about information architecture. You have to think about it in a very different way. If you are expecting to be generous with what you've learned.

Fabrizio Ferri Benedetti: [00:43:21] They say teaching is one of the best ways of learning for a reason, right? And as you say, it forces you to structure knowledge in your head in a different way. You're not just a receptive, passive receiver of knowledge, you are building it into your head. So that's the only way of then passing it on to others.

Kate Mueller: [00:43:45] Can you give me an example of something recently that you felt like you kind of forcibly grew as a tech writer through?

Fabrizio Ferri Benedetti: [00:43:54] Well, AI and the use of AI at work is the first thing that came to my mind. And I was never skeptical about the use of AI at work. I was more concerned about the quality, like 2 or 3 years ago when the first models came out, you could really tell the quality was terrible. Then things improved, and the best tense, I think, is always like being in the middle and trying to assess limitations and opportunities, because there will always be limitations and opportunities with every new technology. And acknowledging that there are limitations doesn't mean you are not. You're not into it or you won't use them. It's actually a very good way of not being dismissed. I think dismissing a piece of technology like AI is not. It's not. It's an unwise choice these days for a tech writer.

Kate Mueller: [00:44:46] And the flip side of that is that the AI space is changing so rapidly, and none of us really knows how we should use it. There's a lot of possibilities in how it could be used. And so it is a space that there's definitely no one right answer and probably not like ten right answers. And it's highly sort of idiosyncratic. How do you want to make use of it? How could you make use of it? What makes sense for you and how to make use of it? So it's a good space. Like if you're interested in exploring a lot of stuff to explore, particularly with a healthy awareness that there are going to be limitations. I think the problem with the AI bubble right now is people being like, it's going to solve all our problems and no, no technology or tool can do that. Come on now.

Fabrizio Ferri Benedetti: [00:45:39] Yeah. But the thing is, if we don't, we as writers, we don't dive into these technologies right now, what could happen down the road is that we will not be able to, like, oppose excesses from an informed position. You know, there might be companies down the road that say, well, we have created the ultimate model to replace tech writers and create your documentation. And if we are, if we don't know the tech, if we haven't explored the possibilities and the limitations, we will be in a much weaker position to say, no, you're wrong. So you have to know well, not your enemy in this case, but you have to know the tech in order to criticize it.

Kate Mueller: [00:46:21] Yeah, yeah. You have to understand the landscape to make good decisions about how to traverse that landscape. Right. And if you refuse to admit that the landscape exists, then you've opted out of the entire conversation. You don't have a seat at the table anymore.

Fabrizio Ferri Benedetti: [00:46:34] Yeah, indeed.

Kate Mueller: [00:46:36] So, Fabri, I think this is a good time for us to maybe start to wind down a little bit, but I'm going to shift into some of my closing questions. But coming off of that conversation, I'm going to say what is a great piece of advice that you've been given? It doesn't have to do with tech writing. It doesn't have to do with anything we've talked about. I just want some good advice. Hit me with it.

Fabrizio Ferri Benedetti: [00:46:59] So in general, one of the best pieces of advice I've been given is to slow down. Which, yeah, perhaps in my case, I constantly need to remind myself to just go at a slower pace and try to take the landscape in and enjoy the details in the end, because there's always a temptation to just go very fast and roll out things. And it's not about quality, of course. And I wrote a blog post about how to write quickly and how to do docs quickly. So fast is kind of an adjective that people attribute to me. But yeah, if you want to make that more general, is the advice is find the thing that you're good at and see what the what the opposite is and try to to go there to try to explore what the other side is, and realize that if you feel like you're good at writing, but tech is like your weak spot, go and approach tech. See what it can give you and what you can learn from it. If you are very fast, try to go slow and see what that teaches you.

Kate Mueller: [00:48:15] I think this is in line with a piece of advice years ago that was something like pay attention to the things that make you uncomfortable, because that's usually the biggest opportunity for growth you have, is that willingness. Willingness to go through discomfort is the willingness to learn something outside of your comfort zone. Right. So those feel aligned and maybe a little bit more on the tech writing theme. Are there any resources you think are helpful in general about anything that we've talked about? We will link to your blog. We will especially link to the post on the seven action documentation model, but anything else that you'd like to call out as a useful resource?

Fabrizio Ferri Benedetti: [00:49:04] There are a couple resources that I would recommend to everybody these days. One is to join a tech writing community, and particularly I think the Write the Docs Slack community is stronger than ever, and I think is a fantastic place to sometimes just not to be alone, be in company with other writers and share the burden and talk to you about your problems, the issue you're facing and the community is so supportive. I've been there for years now, and it's really a great place to be. And the other resource is more practical right now. I would recommend everybody, if you haven't done that yet, to sign up to at least one LM, one AI model and start using it daily and start exploring its possibilities. Like, I might understand concerns with the environment, of course, but take into account that models are becoming more and more efficient, and also because these companies have to make a profit. So if the models are too expensive to run and consume too much energy, they will not be able to do it though. So yeah. And you can, even if you don't want to use one of the famous models like GPT or Cloud Explorer, running local models, even small ones. And see on your computer you can do that and see what just gets the feeling of it.

Kate Mueller: [00:50:30] Yeah, I would second that in that I have been one of the folks who's been slow on AI for environmental reasons. And the last time I had a conversation with a really knowledgeable tech writer about it, he was like, why don't you just do a local model then? Then you kind of have a feel for how much energy the thing is using, and you have control over it. And it's typically way less than using one of the publicly available ones. And I was like, okay, yes, maybe I can sidestep my ethical qualms here because I do want to experiment and understand limitations and benefits. So I think that's an excellent piece of advice and a resource, I guess. And maybe to close it out, if people listen to this and they want to follow you or get in touch, what is the best way for them to do that?

Fabrizio Ferri Benedetti: [00:51:15] So I would recommend that you go to my blog. I guess you will put the URL somewhere.

Kate Mueller: [00:51:21] We will put it in the show notes so you don't have to scribble that down.

Fabrizio Ferri Benedetti: [00:51:24] Yeah, that's the best way really for now. I welcome all emails or follow me on LinkedIn where usually I post lots of updates there too. And in the blog you will find all the social links. So I'll be happy to talk about that writing with all of you.

Kate Mueller: [00:51:39] And or send him your criticism or constructive feedback about the model, because apparently he hasn't gotten a lot of that yet. So this is your opportunity.

Fabrizio Ferri Benedetti: [00:51:50] Let's debate.

Kate Mueller: [00:51:53] Let's debate. Let's figure out how to make a move. Tech writing forward in interesting ways. Well, yes, Fabri, thank you so much for taking the time out to talk to me today. This has been a fantastic conversation and thank you for being a prolific blogger because it helps give people like me stuff to think about. Yeah, well, even when we aren't interacting with other people directly. Thank you.

Kate Mueller: [00:52:24] 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. That's knowledge with sass.com. Until next time, I'm Kate Mueller and you are The Not-Boring Tech Writer.