Tool selection and the unpredictable variable

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | Amazon Music | Email | TuneIn | RSS

How do you really choose the right documentation tool? In this podcast episode, Sarah O’Keefe (Scriptorium) talks with Paweł Kowaluk and Michał Skowron (Guidewire Software) about building a successful tool selection process, the realities of docs as code, and what happens when the technology becomes the unpredictable variable.

Paweł Kowaluk: It’s funny how programming used to be deterministic, and it was the people who were messy. We always knew that people are going to be whimsical and maybe harder to rein in, but the technology is going to be predictable. Whereas now, technology is not predictable anymore, and you give it a prompt and you hope it’s going to do what you want. You adjust the system prompts and change the weight of things which are retrieved versus metadata, et cetera, and it doesn’t always work the way you expect it to.

Sarah O’Keefe: And now the people are being asked to be the deterministic layer, right? To be the QA on top of the AI.

Paweł Kowaluk: That’s actually very insightful. I like that. That is true. The human in the loop or whatever you call it, that’s supposed to be the voice of reason.

Related links:

• Scriptorium: AI in the content lifecycle
• Tech Writer Koduje podcast
• Tech Writer Koduje: DITA as code – a modern approach to the classic standard
• Tech Writer Koduje: Are people abandoning docs as code?
• Tech Writer Koduje: A tech writing CCMS can also be a broken promise

LinkedIn:

• Host: Sarah O’Keefe
• Guest: Paweł Kowaluk
• Guest: Michał Skowron
• Tech Writer Koduje LinkedIn profile

Transcript:

Introduction with ambient background music

Christine Cuellar: From Scriptorium, this is Content Operations, a show that delivers industry-leading insights for global organizations.

Bill Swallow: In the end, you have a unified experience so that people aren’t relearning how to engage with your content in every context you produce it.

Sarah O’Keefe: Change is perceived as being risky; you have to convince me that making the change is less risky than not making the change.

Alan Pringle: And at some point, you are going to have tools, technology, and processes that no longer support your needs, so if you think about that ahead of time, you’re going to be much better off.

End of introduction

Sarah O’Keefe: Hey, everyone. I’m Sarah O’Keefe, and welcome to the podcast. In this episode, we are going to talk about tool selection with a couple of special guests. With me today are Paweł Kowaluk, who is a software architect at Guidewire Software, and Michał Skowron, who is a documentation tools developer, also at Guidewire. Both of them are based in Poland. Welcome.

Paweł Kowaluk: Hi.

Michał Skowron: Hello.

SO: I am glad to have you. For those of you on this podcast that speak Polish, you’re probably already aware that they have the one and only techcomm podcast in Polish that is available out there, and Michał and Paweł are also experts on doc process and tool selection, so that’s what we wanted to focus on today. So I will start and throw it to Michał and ask you the big picture question, which is what does a good tool selection process actually look like?

MS: For me, good selection tool process would be divided in three stages. The first one would be gathering requirements, looking what’s out there, defining what you want to basically achieve with this new tool. Then I would go to a pilot project where you can actually test the selected tool in the real world. Manufacturers and producers of software will tell you that it can do anything and it will promise that, “Okay, you can meet all your requirements easily and we can fix that, we can improve that, we can adjust that,” so everything can be done is usually what we hear, but then you want to test it in real world on a real project, so that will be a pilot project for you and your team.

And the third phase that depends on the outcome of the second phase, which is you either productize the selected solution or you just say, “Okay, that was a bad choice and we don’t need that.” Then we need to go back to the first stage and then say, “Okay, we need to select another tool,” and again, requirements, et cetera, et cetera. So for me, that’s the whole process, and the first stage would be probably the longest one because you need to make sure that you are meeting all your goals.

SO: So what’s the most common reason that a pilot doesn’t succeed, that you have to go back and say, “That didn’t work. We have to try something different”?

MS: It’s usually because you didn’t see everything when you were planning. For example, you have some projects that are very specific or you didn’t see all the problems or things that are coming your way. It’s hard to say exactly what the reason is, but it can be multiple reasons.

For example, using of, I don’t know, branching, let’s say, in a specific tool. When you have multiple versions of your product and you want to keep them separate when it comes to documentation, it can turn out that the feature says, “Okay, you can use branching and then you can do it easily,” and then you start using it and it turns out that it doesn’t work the way you expect it. This is actually a real life example because we had a system that… I’m not going to mention any names or anything like that, but there was a system and they promised us… That was years ago and it was a vendor that promised us that they’re going to introduce a feature called branching, and it turned out after they did that that it wasn’t what we expected. So it can turn out in many cases, in many ways, it can be the problem, but branching is just an example, but it can be many other things that can go wrong.

PK: Hey, if I can jump in here, I got a couple of examples. One is I could call it releasing strategy or versioning strategy overall, which is very hard to test in a pilot project. It’s very hard to scope for requirements because the little problems come out after a while, after a year of publishing, after two years of publishing. And another example which is related is reuse, and this one is down to formulating the requirements correctly. Because I think just saying, “We want to reuse something,” is not enough, because you have to say exactly what you want to reuse and how you want to reuse it and what you want the result to be.

So for example, if you say, “I want to reuse notes and warnings and things like that.” We sometimes call them admonition. So, “I want to reuse these notes in my docs, and if I update a note, I want it to update in every published version of the doc.” Then only if you have these details, like I want to update it once and then want it to automatically update and publish docs, then you will see it’s not working the way you expect it. Because if you just say, “I want to reuse notes,” every system can reuse notes. Even in docs as code, there’s scripts and macros that allow you to reuse notes.

MS: It can be also another thing that, for example, you compare the benefits with the actual cost of implementation, and it can turn out it’s not worth it because people are, for example, reluctant to use your new tool. The training, the cost of licensing, the cost of support is too big, and then you realize, okay, we want to achieve a goal like, I don’t know, reduce the time to market, and then it turns out it doesn’t work because people are struggling with using the product on a real project. And on paper, everything looks cool and you have all these features, you can use them, like Paweł mentioned, for example, reuse conditional formatting and things like that. And then it turns out it’s very hard to use, it doesn’t serve its purpose, and then you have to pay for every additional stuff and people don’t want to use it, so what’s the point?

SO: Yeah. And I think we find that the technical problems in general, if you’ve done your requirements work, then usually, the technical problems are solvable if the people engaged in the project want to solve them, and that’s where you run into the change management issues that you’re talking about, that if the team that is being asked to pilot, to test, to try things out is sufficiently disinterested in making it succeed, they will find a way to make it fail. And the reverse is true as well. If they want it to succeed, you can implement tools that are … Well, all tools are imperfect, but you can implement tools that are not perfect solutions and succeed if the team is behind you, and if they’re not, bad, bad things will happen.

PK: Oh yeah, that’s true. And I’ve been on projects where we did not do proper change management and I’ve been on projects where we really did it well. If you start early and you involve people, like get the biggest troublemakers, people who are the most opposed to any change, get them on the team, and if you can convince them, that means, one, you are making the right choice because you’re convincing people who are skeptical, and then two, you are set up for success. These people are going to be your biggest champions of the new solution.

MS: But it’s good that you mentioned it because I think it’s worth emphasizing that the goal of the pilot project is not to succeed. That’s not the actual goal. The goal is to verify the requirements against the real project, and so the failure is also a success to some extent. It’s not like you have to do everything to prove that the selected tool is the right one. No, you should be aware that the pilot can end up with your let’s call it failure, and then you realize that it’s either a bad choice or you don’t need that at all. For example, you don’t need that tool at all. It can be also the outcome of the pilot project. So there are many different outcomes, so don’t be fixated on the success path that is the only right way. It means, okay, the pilot project was a success because everybody agreed that that was the right tool that we want to use, so keep it in mind.

SO: Yeah. I think that there’s … I got into actually a debate with somebody about this. They were telling me that pilot project, proof of concept, and what was the third one? Prototype are not the same thing. Okay. Well, so a pilot project is, “We think this is the right answer and we’re going to try it small and then we’ll expand.” A prototype is, “We’re just going to try it and throw it away,” and a proof of concept is, “We think this is the right answer, but we’re not sure and we’re prepared to throw it away.” And I thought, “This is way too specific for me, but okay, sure.” But to your point, the project, whatever category it belongs in, has different purposes, and it’s important to be clear about what kind of a project is this? Is this essentially beta testing, this is step one, or is this more speculative? We’re just really, really not sure.

PK: I think it has to be falsifiable. Like they say in the scientific method, there has to be a failure criteria somewhere. This will fail if ABC happens, because if you don’t have that-

MS: Or a success criteria, right?

PK: Or a success criteria, but I’ll be more focused on the failure criteria because you can always show, “Yeah, we accomplished this, 30%,” but if your failure criteria is below 50% is fail, then you will say, “I failed this.” You fail five out of six and the project is a no-go.

SO: So I wanted to switch gears a little bit and talk about some specific tool chains and problem sets. I think it’s fair to say that the two of you are, I’m going to say mostly but not exclusively, focused on docs as code, so what does that look like? And there’s a lot of debate about docs as code versus structured content and they’re very much pitted against each other, but ultimately, what’s your perspective on the situations where docs as code is appropriate or maybe is not appropriate, and what do you look for in a project or in a problem set that matches the docs as code model?

PK: I think the reason people associate us with docs as code is the last eight years, we’ve been working at Guidewire and that’s the strategy we’ve chosen there, so I think we’ve been entrenched in this worldview. My previous job before Guidewire was a consultant, and I would go from a company to company and set up different systems for documentation. That was my specialty, systems for publishing and updating documentation. So yeah, circling back to your question of when it works, when it doesn’t, I guess docs as code is more about it works when the right mix of people are creating the docs and the mix of people includes software developers. So for example, at Guidewire, we have several dozen static websites which are maintained by software teams without any technical writers involved, and those are a variety of internal tools, tools which are almost external, and then tools which go out to customers, and all of these little websites integrate very well with our publication system.

And I think this is the main criterion for docs as code fitting is you are giving tools for writing to people where they work. So software developers work in code. You give them tools for writing in their codes so they don’t have to buy extra licenses, get training on anything external, use some alien process, alien to them, just because they follow SDLC, the software development lifecycle to update their docs. And it’s what they’ve been doing, and then it’s easier to convince or it’s easier to fit in a smaller team of technical writers, I don’t know, like 40 technical writers versus 2000 software developers. It’s kind of everyone contributing to the same documentation system. It’s easier for the tech writers to adapt and join the docs as code platform than the other way around.

MS: Just like Paweł mentioned, docs as code makes sense in certain environment. It’s not like we are tribal about it. We love this solution because it works for us. So after a few years at Guidewire, we realized that this is the way we want to go, because as I said, it makes sense and it just works. We tried different things before, and before I joined Guidewire, there were different solutions. We used, for example, CCMS and we had more a traditional approach to producing docs, let’s call it this way, and then we started building our own pipelines, our own solutions. We started integrating with what was there that other devs used for their work, not related to documentation, but we decided, “Hey, maybe we can use what’s out there and just plug into the same infrastructure.” So as I said, it’s not for everybody, it doesn’t work in every environment, so I wouldn’t say, “Okay, if you’re in a factory, you should use docs as code.” No, I wouldn’t say that. So maybe we positioned ourselves as docs as code proponents, let’s call it this way, but this is because we use it every day, we build it, and this just works for us. And also maybe I can mention that we decided to end this holy war by putting DITA into Git and CICD pipelines, so we have DITA as code, and now everybody’s happy.

PK: Oh, this is actually a great point because Sarah, also mentioned docs as code versus structured. Now we’re doing docs as code in a structured way, and where technical writers are working on the docs, they are free to use DITA and a lot of teams do that with all the reuse and all of that, but even if it’s something simple like some markdown files in a repo, we still impose a metadata structure which allows us to integrate the doc into our publishing pipeline, and the two key aspects of what we’re integrating with our authentication and search, and that needs metadata, right? It needs to know who has access to this content and it needs to know how to filter and direct the searches, and from that, our next project emerged. Like everyone else in this industry, we started working on AI solutions, and the AI solution is a third integration point where this structured approach to content also pays off.

SO: Yeah, I did want to touch on AI and so we should probably just jump to that. What are the implications that you’re seeing? What are the effects that you’re seeing on your current processes of the use of AI or the requirement to deliver to AI, and how do you see that working?

MS: Paweł, you want to start?

PK: Yeah. So the content remains the same that we’ve been working on for years, and the structure, the metadata is all the same. We could not change this overnight, but overnight, we had to introduce this AI which is going to look into the content, find the topics, the chunks we call them. It’s going to find the right chunks of documentation and generate answers based on those chunks. So what happened is we had to adjust the AI, but since we were so structured, it was pretty easy, and then we gained a new source of feedback from customers through the AI. Because when people started using our chatbot, we built a chatbot which is available on [email protected], but it’s only available to customers and partners, so you need a login on the website.

When you go there, the AI answers questions, and then we monitor the exchanges that people have with the AI and we see what needs to improve as far as content ingestion, as far as content structure. We generate a lot of internal tickets to our tech writing team and identifying gaps, because we’re seeing now that this AI interaction is possible, here’s what people are asking of the content. And other people are asking, “How do I implement X, Y, and Z in the scenario where ABCD?” Which we didn’t know people were looking for before because they had no interaction with the docs. So they just come to the website, they either find or don’t find what they need, and we don’t know anything about that, and we could ask them, but we’re just going to ask a small group of people, whereas now, it’s as if we’re asking everyone.

So we’re seeing these new patterns and something emerges out of those patterns, like everyone’s asking for code samples in this specific area, so we go back to the team and we work on adding more code samples, or people are looking for illustrations of these particular workflows, so people create these illustrations. It’s amazing how rich of a source of feedback this has become.

MS: And it also adds complexity to even testing all the solutions that we have right now, because with keyword search, I’m not saying it was easy because it wasn’t easy, but now we have another layer where you have this middleman, let’s call this chatbot, let’s say. It’s a middleman that can hallucinate, so you can either have a problem with your content or you can have a problem with the agent that responds. So before, when you had a keyword search and you were missing results, you were going usually to the content and see, “Okay, I’m missing this topic. It wasn’t indexed properly, or I just need to move some knobs in my search engine and just see the fuzziness or something like that.” And now you have this content, it’s being processed by this AI tool, and then it gives you some answers and you don’t know why the answer is wrong. Because it didn’t find the content? Because it’s not there? Because it’s not the right content? Because the content is right, but there is something that it missed? There are so many moving parts right now, more than before that it adds complexity to our job, and this is just one side of it.

The second thing is writers using AI for creating content, and we’re also exploring this path because everybody’s trying to incorporate AI solutions into their work. We code mostly on a daily basis and we use some tools that help us with coding that are AI-based, but we also want our writers to benefit from all this development in technology, and we’re exploring, let’s say Oxygen, XML, Positron. Just to clarify, we’re not sponsored anything. We’re just using it so I’m just mentioning the name specifically, but even if you don’t have any specific tool for writing that integrates directly with a AI tool, you can still use, let’s say, Copilot or any other solution that you like and you can just ask it to help you with the content, but it comes with a lot of caveats.

It’s not like you just throw a prompt and just get what you need. It involves a lot of fine-tuning, a lot of working on instructions, giving it context, giving it information that it needs to use for producing code or docs. Because I use it for both, for coding and for documenting, for internal purposes mostly, but it takes time to make it work the way you want it.

PK: Yeah. It’s funny how programming used to be deterministic and it was the people who are messy and the processes, and working with setting up the process for the doc tools, we always knew, people are going to be whimsical and maybe harder to reign in but the technology is going to be predictable. Whereas now, technology is not predictable anymore, and you give it a prompt and you hope it’s going to do what you want. You adjust the system prompts and change the weight of things which are retrieved versus metadata, et cetera, and it doesn’t always work the way you expect it to.

SO: And now the people are being asked to be the deterministic layer, right? To be the QA on top of the AI.

PK: That’s actually very insightful. I like that. That is true. The human in the loop or whatever you call it, that’s supposed to be the voice of reason.

SO: I don’t know about you, I’m not good at voice of reason. I’m much better at causing trouble. So what you’re describing is a fairly complex and time-consuming approach to this in that you’re saying we have this AI chatbot and we’re looking at the metrics and we’re adjusting accordingly and making changes, and then using the AI on the backend for some productivity kinds of things, but not as a replacement. We’ve seen in the US and in North America, we’ve seen a significant number of people losing their jobs because the idea is that, oh, the AI can just do it, and what you’re describing is not that at all. So are you seeing any of this sort of, “Oh, this will make us more efficient, and therefore, we need fewer people,” or is it a different perspective in your piece of the tech com world?

MS: I’m aware of all the layoffs and of all the bad things that are happening right now in the IT world, let’s call it, because it’s not only technical writers because it’s also developers and different jobs, but I think I’m still in this kind of a bubble right now where it’s not happening directly next to me so maybe I’m being too optimistic. But I keep saying maybe I’m going to eat my shirt after some time because I keep saying, “Show me one tech writer that doesn’t have a backlog that is not too long.” So we usually have too much work, and I hope that with the right approach and with a sensible management, these AI tools will be doing all the things that we don’t want to do or we don’t have time to do, and then it will give us time to do something more and something more significant.

I’m looking at my job and I’m not saying it’s perfect because of AI, because it has so many challenges right now and it gives you different problems, but I can see that I can speed up my cumbersome tasks very, very easily. And before, I had to … This is a simple example, and I’m doing a lot of infrastructure work and a lot of backend work, so many things go wrong, and very often, I had to debug difficult problems. It was taking me weeks sometimes to nail the actual place where it happened. Now, I can do it much faster. If I have to debug a problem, it takes me, I don’t know, an hour, sometimes even minutes, and I know that I would spend a day, two, or even a week if I didn’t have these tools. But these are good examples, but there are also a lot of bad examples, but I don’t think we have time for that.

SO: We’ll take the optimistic view.

PK: Yeah, I agree with Michal. The approach we have is these tools can give us tremendous productivity boosts, but not in the sense of getting rid of people. We can redirect people’s work to where it’s more meaningful. And what I mentioned about feedback, identifying these content gaps. Some of these content gaps are going to be very mechanistic and you solve them by generating a bunch of docs out of code, for example, and then you put those docs in the repository where the chatbot can find them, because they’re not going to require a lot of thinking. It’s kind of like API docs where you create the swagger spec and then you generate the dogs out of that. You just grab the source code and you generate some samples, and you use that to generate answers to people. Without people, this wouldn’t work because you need, like we said, the voice of reason, but yeah, people are still required in the process.

SO: I think that looking at it across the industry, if you take AI, take a chatbot, especially a public facing chatbot, and ask it for answers on literally anything, it will give you the average of what’s out there in the world because it’s math, so it gives you the average essentially. And so from a content creation point of view, I think the fact of the matter is that there is in fact a lot of below average content out there. Roughly half is below average, or perhaps exactly half.

If the information is bad enough, if the content being produced is not of high quality or ungrammatical, and we’ve all seen terrible, terrible documentation that was badly translated and is just incomprehensible, then the AI as a tool for creating content may be able to produce something that is better than terrible. It’s not going to replace a professional, well-trained, highly experienced and knowledgeable product documentation group, or it shouldn’t, but that’s not every company. Not every company has a really good group of tech writers that understand the product and are adding value as they produce the content that goes with that product. And so I suspect that what we’re going to see is a split with commoditization on one end, just auto generated, it’s not great but it’s adequate maybe, and then the higher end stuff, which needs to be done well.

PK: Well, there’s definitely documentation which only exists because it absolutely has to, and companies like that can easily generate just some kind of documentation and just use it, right? But in cases where … I think the worth, the value of a technical writer is not just writing and generating the content from below their fingertips. It’s more about the research and understanding, like you said, understanding the needs of the users and understanding how to meet them. You throw AI at a problem which sounds like a generic problem, it’s going to give you a generic answer, not necessarily one that is rooted in the organization you’re in. The list of products that you have, the way those products interact with one another, it’s going to miss all that.

It’s just going to give you … It’s like ordering a hamburger and you say, “So what’s in the burger?” And the AI is going to tell you, “Well, usually in a burger, it’s a patty and lettuce.” And it doesn’t mention that at your restaurant, you use pear and avocado. It doesn’t know that. You know that. You’re the chef back in the kitchen and you know why your burger is special.

SO: Yeah, I think that’s right. So I did want to touch briefly on the question of, because this is a rare opportunity to talk to some folks that are not based in the US or North America, what differences, if any, do you see in tech writing in the market? Now, you’re based in Poland but working for a, I think, US company, but what kinds of things do you see that are maybe different that especially the people listening to this in the US would not be aware of coming out of Eastern Europe?

MS: For me, always, it was the fact that tech com appeared much later than in the United States, in Poland of course, because I’m not talking about Europe in general because there are also differences between countries in Europe. For example, Germany is totally different from I would say the Polish market, because in Germany, you usually have factories and you have technical writing associated with hardware, let’s say.

SO: Yeah, heavy industry, machinery.

MS: Yeah, heavy industry, that’s right. And in Poland, it’s very often about software, maybe because we have a lot of companies that outsource to Poland when it comes to software development, R&D and stuff like that, so that’s the first thing. And don’t get me wrong, people were doing tech com way before it appeared in the mainstream, but sometimes they were not even aware that this is called technical writing or technical communication. Actually, it happened to me because I moved to techcomm from some kind of IT support job, and then after a year, I was like, “I’m wondering if this is anything regulated or there are some rules or it’s actually a profession.” Then I started digging and here I am.

But it turned out there are so many things, so I was also surprised. Okay, this is called that. These are standards. There are books. Well, actually, one of the first books that I read was your book, Technical Writing 101, which I’ll still recommend, although it’s been years since it was published the first time, but I think it still holds a lot of truth about techcomm. The core values of techcomm are still there. So going back to your question, the techcomm scene is relatively young, let’s call it this way, in Poland, which gives us a big opportunity to skip some stages, let’s say. So we don’t have the legacy, we don’t have some things that we used to do a certain way and we like it or we are just accustomed to it. We can just start fresh and just jump. In 2000s, we just jump into techcomm and we say, “Okay, let’s do it this way because now this is the way we do it.” And I think that people are flexible when it comes to looking at things a certain way. Not everybody because there are also people who don’t like changes.

But I think also what is unique about Polish techcomm scene is it’s relatively small, so if you do something outside your work, you don’t treat your job as only a means to earn money and just survive and you want to do something else, let’s say just write an article, like give a presentation, go to a meetup. After a year or two, you just keep meeting the same people, you know basically everyone who is in the circle, so it’s much easier to be visible if you do something outside your work. So I think that would be something unique about our techcomm scene.

PK: I think what might be a downside of the Polish techcomm scene is a lack of veteran experts, because we don’t have people who have been doing this for 40 years. I’ve been in the industry for 18 years.

SO: But you do understand that you two are the veteran experts.

MS: That’s what he’s trying to say, that-

PK: I’m getting to this. So yeah-

MS: Imagine that.

PK: Putting on my clown makeup every morning. What I mean is there’s nobody to look to who wrote the book on technical writing and has been there for 40 years. I’ve been here for 18 years doing this thing, and out of the people who are visible publicly and who contribute to the scene, I don’t know if there’s anyone who has more experience than me. Because I know there are people who have more experience but they’re just not visible. They don’t share their knowledge with anyone, and we miss that, so that’s why we look to the West, to people like you guys, like Scriptorium, and we read books which were created there and we see there’s definitely value, even though something is as old as the scene here or older.

MS: And people also have this tendency to look at things that were done in the past as like, “This is the old stuff. We don’t need that. This is the old way. Let’s do it this way because it’s better now, because we have all these tools and et cetera.” But I think it’s a big mistake, because what they say? History doesn’t repeat but it rhymes, something like that. So in order to do your job in the present, you just need to look at the past, and this way, you can also be ready for the future.

I think it’s worth looking at all this, let’s call it legacy stuff, all the experience that people with 30, 40 years of experience in the field have because it’s valuable. Because usually, when you look at it much deeper, it’s nothing new. It’s usually something that already happened but it’s dressed up as something else. So if you look closer, it’s usually something that let’s say you can understand what happened and then you can apply the same rules, maybe slightly change them or bend them. But my experience is the same happens in software development, in coding. People are inventing new things, and when you look closer, it turns out somebody already said that in the past. It was already done this way, but it’s dressed up as something else or named differently or is hyped more, or it was invented too early and now is the time to use it. So the history gives you a lot of perspective, a lot of things that you can use, so don’t dismiss it.

SO: Well, I think that’s a good point, and as we close this out, I want to ask you what you see in the past or where you’re gaining perspective on the introduction of AI. Whether it’s from a delivery point of view or a backend productivity point of view, where do you see that pattern previously, or do you?

PK: There are similarities, but they end. They’re not perfect analogies. So going digital was on example, and when I started, it was just on the brink of companies going from print to web, and that was a huge paradigm shift. And we’re seeing reverberations of this even today where teams are still thinking in books and chapters instead of thinking in pages and thinking about even every page is page one, which is, I don’t know, it’s older than me, the idea, but it still hasn’t been adapted to by teams. Now, the AI thing is probably a similar earthquake where it’s the AI reading your docs, giving you answers. You’re using AI to generate these docs, et cetera, et cetera. I don’t think we’re going to get 20 years of leeway to adapt to that and still see people doing things the old way. I think the world maybe moves faster nowadays, but I don’t know, we’ll see.

MS: It may be something similar to the invention of computer. So instead of writing let’s say manually, people have got this new device that gives you more power and you can do more things and then programming languages and everything, but as Paweł mentioned, the pace was much, much slower. So we had years of development to, let’s say slowly, maybe this is the bad word, let’s say slowly adjust to the change, and now it’s an earthquake. So every day, every week, there is something new and you need to keep up, keep up, so the pace of development I think is the biggest challenge. Because we tech writers survived many revolutions. I just started reading a book by Sharon Barton about the women in technical communication, and women who talk about their careers, they mentioned many, they start very early because there are a lot of examples from the States.

So they started working when they were not even treated equally with men, which was years ago, and they mentioned all those changes, all those revolutions, all those evolutions. And I’m saying, “Okay, this is what we are witnessing right now, but the pace is definitely faster, so we need to just keep up,” which is hard, of course.

PK: Well, I have another one which is a good one. I don’t want to not say it. The dot-com bubble. I think maybe we’re in a bubble again, maybe. You’re seeing the inflation of AI prices right now, and I think we’re going to end up in a position where you cannot do all these things with AI which we’re hoping to do with AI, so the surface of usage is going to shrink and there’s only going to be specialized uses and special case scenarios when you use AI because it’s going to be expensive, and a whole lot of AI applications are just going to disappear. This might be a parallel, but I don’t know, it’s always hard to predict, especially the future.

MS: I’m also predicting some corrections. Let’s call them corrections.

SO: And I three am also predicting some corrections. You touched earlier on the fuzzy. AI is very good at fuzzy problem solving, but it’s being thrown at things that are old problems that we know how to solve with scripting. And scripting from a computing power point of view is cheap or maybe free. You write your script and you run it, and every time you run it, you get the same predictable result. Now, sometimes you don’t want that. Sometimes you need that fuzzy pattern matching thing, but in the cases where that’s not what you want and we’re still using AI, that is part of the bubble, right? Everything looks like an AI-shaped problem. So yeah, I agree with you. I think that any predictions we make on specifics as to where this is going are guaranteed to be wrong, because I’ve tried this before and I’m always wrong. So I want to thank you both. This has been very entertaining and very interesting, and I hope that we will see you again and you’ll come back and tell us more about what you’re up to over there.

PK: That would be lovely. I would like that very much. Thank you.

MS: Yeah, sure. No problem. Thank you very much. That was fun.

SO: Yeah. Thank you both. We will see you soon.

Want to learn more? Download our book, Content Transformation.