Patricia Boswell: I can say one thing that I don't like to see in a technical writer, and that is a kind of person who only wants to describe how it works. So a good technical writer is somebody who describes how it is used, and in order to do that, we tie all of these vision pieces together.

Sam Ramji: Welcome, Patricia Boswell. So delighted to have you on the show today. Thank you for coming.

Patricia Boswell: Thank you. I'm pretty excited to be here, Sam.

Sam Ramji: Well, I got a chance to work with you and meet you at Google, when I was in Google Cloud. You're a staff technical writer at Google and you've been there for almost 16 years.

Patricia Boswell: That's right.

Sam Ramji: How the worlds of documentation and training and enablement come together with technology and cloud computing and the particular lens that we're taking in our conversations is about open source data: open data, open systems, how these things come together to create a sort of a space of possibility. So I just thought that having the level of intellectual horsepower that you put into understanding technology, such that it's explainable, it's adoptable, you coach teams on this, you cause good documentation to happen. But documentation is really sort of a cognitive stairway to heaven for somebody to be able to walk up, to understand what they're supposed to be doing. So I'm just delighted to have you here, and I think it's going to be a really fun conversation. You have a really spectacularly, eclectic and diverse background for someone with your stature in the technology industry.

Patricia Boswell: You do, too.

Sam Ramji: Yeah, I'm an odd duck.

Patricia Boswell: Right back at you. Yeah, my background is... I started out as an English major, actually Education, teaching. Then I did Lit, but throughout my entire academic career in Lit, I taught composition and I was always sort of a nerd. I made my way through college by doing medical transcription on the side, which meant that I had to use a lot of different transcription machine devices and word processing languages and so I brought that into my composition and teaching.

Patricia Boswell: And so I think I was really a tech writer from the very beginning. I wrote my first quick start guide, probably 1988, when my students wanted to give me papers in my composition class that were on a typewriter and I forced them to use the word processing lab that was then available. And they didn't have any guides, so I wrote the guide for them.

Patricia Boswell: So my classes, the first week always became how to use this computer system. And then my last class that I taught in '94, I pulled them onto Unix systems and there was no documentation at all. The only handout that they had was the first command to learn how to use Unix was sed and awk.

Sam Ramji: Wow.

Patricia Boswell: So I wrote a guide for my students and had them email their papers to me. And I corrected them using Emacs macros and made them look their code up so that I wasn't copy editing their writing. I was actually giving them codes and forcing them to learn. So for me, I think that was probably one of the first most impactful realizations about the power of technology to teach. So I wasn't effectively writing documentation, but I was using technology to enable people to learn how to look at their writing and develop it.

Sam Ramji: And that was a challenging audience to win over, right? The technology adoption by sort of hardcore literature folk can't have been super easy.

Patricia Boswell: Yeah, that's interesting. Actually it was poor freshmen and sophomores. So as a Lit major you have to teach freshmen and sophomore composition classes, poor guys. ... But my colleagues really thought that I was an odd duck. They didn't understand why I would use these computing systems, but now it's all the norm. I think they resisted at first because it was new but then once I got them on board with it they realized the value of it because it gave them a leg up. So it was great.

Patricia Boswell: And I'm just kind of interested in the fact that you started out in this amazing space. You start out in cognitive neuroscience, you became a software engineer, and now you're a technical adviser across many high tech companies and the chief strategy officer for DataStax. I just think that's kind of amazing that we're connected here in this medium with such different diverse backgrounds.

Sam Ramji: It's pretty wild but at the same time, I think there's something fundamentally the same, which is, it's all about seeking for knowledge and making that knowledge productive and procedural. So the fascination of cognitive neuroscience and AI and software is all about, how do we augment human intelligence? How do we make individuals more competent, more capable to take care of what they care about? So you and I have just been solving two sides of the same coin. The shift in the structure of the industry is kind of the shift of our careers, too. There's a fluidity at the core of it.

Patricia Boswell: Right. And the background, again, for learning and understanding. I agree.

Sam Ramji: Yeah. And I really like the fact that you took very intelligent people... It's common for those of us who have Bachelor of Science degrees, master's, PhDs in technical fields to kind of dismiss the intelligence of liberal artists. But a literature student is extremely intelligent. They're just not a technical expert. So I think that's a great microcosm of what we try to do in technology adoption is to say, "We assume that the person on the other side of this terminal is really, really smart. They just don't know what we know." So how do we make it approachable? How do we have a user model? How do we start doing documentation to be able to break those boundaries?

Patricia Boswell: Yeah, that's so true. One of the things that I realized in my journey from academia into high tech is that there is a little bit of unfortunate arrogance in high tech that I kind of adopted in the beginning. I thought, "Oh, I'm just a Lit major. I don't know this stuff." ... I wanted to tell you a story about this sort of thing, coming full circle for me, where my first dot sig file. Do you remember those dot sig files?

Sam Ramji: Absolutely.

Patricia Boswell: It had a quote from Leslie Marmon Silko, who is an author who wrote a book in 1977 called Ceremonies. She's a Native American writer. And there's this quote that says something along the lines of, "You don't have anything if you don't have the story." So I put that in my dot sig file. And when I got into high tech, I thought, "Oh, it sounds like a literature person and now I'm a technical writer, so I'll take it out." But I realized as we've come full circle, especially in the world of developer relations and now developer relations itself is kind of a thing across the high tech space. They started developing this whole idea of a narrative and thinking about the developer narrative and what is the user flow, what's the narrative of a product and all of those things center around stories. So no matter how technical a topic is, the framing is always the story. You can make something more approachable by framing it as a story.

Sam Ramji: Yeah. The frame is kind of how our mind grabs hold-of it and works with it. And I think there's an underlying evolutionary arch here where once upon a time it was the software codes themselves, right. It was the code we wrote that was scarce and the programmers were scarce. So just having something, meant it was cool. But now that stuff is all abundant. So the new scarcity is like, do people even want it? How do you attract people in a cloud native world. How do you attract people in a world of GitHub to an open source project where you've got literally tens of millions of open source projects? The differentiator is, is there a frame people can grab, is the story compelling enough that someone's attracted to stop what they already know and what they're already doing to come hang out with you and check out your stuff and spend enough time developing a little bit of competence to use it and become a member of your community. So the techniques you've been developing over all this time, I think, are kind of the razor's edge of how we get people's attention.

Patricia Boswell: And I would even say that it's always been the case that in order for us to wrap our minds around it, we always have to tell the story. Even back in the early days, I remember a software engineer I worked with, [Jared], back in B2B eCommerce company, and it was a front end HTML system, eCommerce system. And he was trying to explain to his stakeholders, the engineers in the room who are more senior than he was, how this thing worked. And I'll never forget - they were having really hard time wrapping their mind around the fact that HTML connection to the web server was stateless, right?

Sam Ramji: Mm-hmm (affirmative).

Patricia Boswell: And they kept expecting there to be like a staple connection. You pull up a webpage, you get on to the store and you buy it. So he basically broke it down for them like a story, saying, "The web browser picks up the phone, calls the web server. The web server says hello and hangs up." And he just kind of hammered that story. And it was very simplistic thing that I think you could tell to any person, whether they're technical or not, but he actually needed to tell that to his stakeholders. And then they came back and they understood it and he was able to move forward that way. But I think it becomes more and more apparent, like you said, in this world today, where there are so many options out there. A differentiator is how you simplify it, how you make it easier to understand and use and fit your mental model.

Sam Ramji: It was something that we were really putting a lot of effort into and changing while I got to work with you at Google, right. I think we doubled the size of the cloud computing and cloud platform writing staff while I was there, because there was, I think, a growing sense that in order to break through in the market, your documentation was going to be what engineers took as relative quality of the code. Right? If your documentation was poor, probably the code and the service were poor. If the documentation was good, told you enough thought had that had gone into the experience itself was actually going to be pretty good. I think that's continued. Since we worked together, you've changed roles from cloud to core data. So I'm really curious to know, is that sort of sensibility around the overwhelming importance of the quality of documentation and user modeling still there in core data for you?

Patricia Boswell: Yeah. In fact, that was one of the things that lured me to this opportunity is that I'm able to work with a great director who really believes in... I'm just going to use my term for it - I call it the "product pie" - where to make a really effective product, you have pie slices of contributors. It's not just SWEs. You need to have product managers, technical writers, user researchers, UX designers, and SWEs all working together to make great products. So now this is something that this leader believed in and it was an opportunity for me to help structure a team and put that together with that idea in mind. So now I'm working very closely with that team and it's exciting because oftentimes documentation is sort of seen as an afterthought. So now that we're kind of involved at the ground level, we can set the direction so that we can have an effective user surface. So sometimes the documentation is the main surface that somebody has to the product itself, especially when we're talking about like APIs or things like that.

Sam Ramji: Yeah. In a way, documentation is an anchor of that team because it's traceability for user experience. And I think one of the things that we got to do, and that made me happy when I was doing cloud dev ops at Google, was we transformed the basic nature of a team from what was seen as two in a box, which was a PM and a software engineering lead to making it a quad, which was a PM, a software engineering lead, UX lead, and a tech writer. And we did that in a pilot that was transformative. I think now that's kind of the ideal core of the two pizza team. Like if you're building a microservice or you're building an application, you're moving quickly, you're breaking things. But what you don't break is the affinity of the user and a written conceptual user model.

Sam Ramji: So I think that's kind of how the world has changed around not just open source and cloud native computing, but just how we think about software in a world where software is abundance. Right?

Patricia Boswell: Right. Can you tell me what two pizza team means?

Sam Ramji: Oh, this is an Amazon expression and it's very vivid. I would love to use something else because it's kind of a funny metaphor and not everybody likes pizza. Personally, I'm violently allergic to wheat, so I can't eat much pizza. But the apocryphal story is that Jeff Bezos said that if it takes more than two pizzas to feed your team, your team's too big. Right? So they kind of inverted the common sense from saying, "Hey, I've got a hundred human beings in my software delivery organization. So let me break that up properly. I'm going to need like 60 software engineers and I'm going to have like 20 QA and I'm going to have like 10 PMs and 10 UXers."

Sam Ramji: And then you end up with these functional silos where everybody's arguing about whose responsibility it is to do what, everybody's taking care of doing a really good job of engineering or product management or UX or PM, but they're not moldable and they're not incentive to collaborate that much. So breaking it down to a two pizza team, the idea is everybody you need is in there with all the functional competencies they need. So you're going to have like seven, eight, nine, 10 people. And so you should have a quad, like a technical writer, UX, a software lead, a PM. And then maybe you have a product owner, somebody who's really representing the technical user. Maybe you've got a couple more SWEs. Maybe it's more of a user experience heavy stage on the journey, right?

Patricia Boswell: Right.

Sam Ramji: So maybe for the first few sprints your two pizza team is bias 2XR. But that idea of a modular structure lets you then take that 100 human beings that you've got and give them more sense of fluidity. Right. And especially because most practicing engineers these days have under 12 years of experience. At a certain point you tend to migrate out into something else, maybe become a manager. There's a lot of fluidity. If you're in your twenties, if you're in your early thirties, you want to learn stuff. You don't want to be stuck in the old models that you and I grew up in of, "You're going to do this job for 20 years and get your gold watch." It's more like, "No, how do I do a bit of this? How do I learn some of that? How do I have more experiences?" So there's a lot more fluidity enabled by the declaration of a two pizza team, I think.

Patricia Boswell: Yeah. I think it's a continuation of the startup model, because I came into technology being-ness in the '90s with the dot-com and there was just so much demand that you could just pick your role and contribute in some way. So I was front end software developer a couple of companies, and also a tech writer. I also did, like for example, I did some UX research for documentation and Google cloud. They had some extra money hanging around and there was a pause that they didn't know what to do with it. So I said, "Let's do some research on our docs." So I think if you're the kind of person that says, "I'm on this lane and I'm only going to swim in my lane," you're going to miss out on broadening your ability to create a great product. Ultimately you can kind of come back to figuring out what your focus area is going to be. But I totally agree that having that model where you're thinking about covering all your bases makes a lot of sense.

Sam Ramji: Yeah. We're in an age where collaboration is king, right? So diverse and inclusive teams to bring more ideas in from the outside world and have different and better lenses produces breakout successes. Slack famously has one of the most diverse and inclusive cultures anywhere, and so the range of things that they're able to do and their breakout success has been super interesting. So we're kind of moving from I-shaped, deep, narrow specialization to T-shaped. Yeah, you have to have a deep, narrow specialization, but you need to be able to understand a bit about everything else.

Sam Ramji: And I think to that end, you have a unique perspective as the person who is accountable for making sure that the user has actually been thought through and people haven't just made sort of jumping logical errors. Right?

Patricia Boswell: Right.

Sam Ramji: There's the insight, but also the quality assurance effectively that the product's going to be good. So you have a point of view, I think, on what makes a great product manager. Maybe we can go through the quad, right? The PM, the tech writer, the UXer and the eng lead. Let's just spend maybe a minute on each one from your point of view. Like what makes a great PM?

Patricia Boswell: Well, I think there's certain themes underneath all of them. And I would say that it's somebody who is collaborative, like you said. They're flexible. They're also curious and they have vision. And I think that applies to all of the disciplines. I think vision is key. So I'd say that for me, when I look at a PM, I look for product vision and market vision. I look for that spark. Where do they see this product going? And then I think the collaboration is next, which is, okay, I'm going to push you on that vision. I'm going to ask you some hard questions about that vision. As an experienced tech writer, I know about some of these things. And if they collaborate with me and they're flexible and curious about my point of view, then together we create something that's bigger than either one of us could alone.

Patricia Boswell (18:10):

So switching to engineers, I like to see the technical vision in the engineer that manifests in... You can't do it today, but walk over to their desk and look over their shoulder and say, "What are you doing?" And their eyes light up and they tell you about their code. And they tell you about how this all is going to work or they whiteboard it. And you can just see where they're going to optimize it. They're going to make it go faster. It's going to process more information, whatever, when you see that or reduce the amount of code, even, for example, scale it up. All of that is what I see valuable in an engineer, along with, always, the flexibility and collaboration piece, right? So they own the technical piece of that. They're a product owner, they're going to stand behind this.

Patricia Boswell: It's sort of like... I don't know - the mental model I have is like the PM is the architect and the engineer is the actual... the systems underneath, the carpenter or the plumber, or the electrician. And the UX is the designer. What's the flow like? How are people going to come? How many people is this supposed to manage? What's their experience feel like? And then the technical writer is... My fellow tech writers are going to not like me when I say this, but I think we're sort of salespeople.

Sam Ramji: That's fascinating. That was the last word I expected to hear you say. I want to hear more.

Patricia Boswell: I think we do non-sales selling. It isn't that we're concrete salesman. We're not selling concrete. But we're using the most concrete, non schmoozy terms possible to help people get to their goal. And that is essentially non-sales selling. So I think it's a limitation of it like... I can say one thing that I don't like to see in a technical writer, and that is a kind of person who only wants to describe how it works. So a good technical writer is somebody who describes how it is used. And in order to do that, we tie all of these vision pieces together. So we create this narrative that ties the market vision and the functional vision and the user experience. We're partnering with UX to make sure that we're documenting the experience, and then it just flows from there.

Patricia Boswell: I don't know if that makes any sense to you, but that's how I see it. I see it like... You can't just say to your PM person, "I don't care about what you wrote on the front page about that. That's just crap. Developers don't care about that." What you do need to do as a technical writer is go up to your PM or your marketer and say, "You know what? This is a little fluffy. We need to make it a little more concrete. And I want words that I can use down in my documentation so that when the person who's coming in who decides to use it, the technology based on your description, starts using it, some of these concepts that were described right in the beginning start resonating all the way down through to the guts of the system." That's when you know you have something really solid. That's my two cents.

Sam Ramji: That's fantastic.

Patricia Boswell: What do you think?

Sam Ramji: I think I have little to add. For product management, as you identified, vision and collaboration. Somewhere in there is the ability to the ability to compromise and be pragmatic while also holding kind of this paradox of pragmatism and ambition. I always think about Tom Sawyer, probably the best product manager ever, right. You know, "Come paint this fence. Like it's a lot of work, but it's going to be beautiful." And people are like, "Wow, this is so great. I'll pay you to paint your fence." So, the PM figures out how to get the system working in their favor because the odds are always against starting anything new. It doesn't matter what you're doing in life.

Sam Ramji: For an eng lead, respecting the need to build something that's going to be used, and I think it comes down to metrics, right? That's something Google's really good at is eng leads tend to really think about adoption and active users as a signal that they're building properly. And that's a really unique point of view, right? Sort of an adoption-centric engineering approach. Not lessening the technical excellence, but adoption-centric engineering solves a lot of problems in terms of being T-shaped because you want to be curious and we want to find out why the PM thinks these things. And why does the technical writer think that what you're coming up with architecturally is too complex for the user to understand. And why does the UX... How did they deploy their curiosity to understand needs of users that aren't met yet in bridging that into the technology is important?

Patricia Boswell: Yeah. I think the most gratifying experience that I had, I came to Google through what eventually became Google Earth, but it was a company called Keyhole. And I worked closely with one of the engineering founders, Mark Aubin. We would just... Like I'd just walk over and say, "Hey, what are you working on?" Or he'd say, "Hey, Patricia, come on over. Let me show you what I'm doing here with this." I'd say, "Okay, tell me, how's it going to go." And then he'd show me and I'd say, "Okay, so the person is going to do this and then they're going to do this other thing. And then they have to exit that and go do this other thing. And then remember what they did before, come back and do it again?" And he stopped and he looked at me and he said, "Oh man, you're right." Because I was thinking about how I would document it.

Patricia Boswell: And then I remember Brian McClendon stepping in because he wanted to know what the hell I was doing bothering Mark. He looked at me and was listening to the conversation. And he said, "You're shaping the product," sort of in a shocked voice. And I said, "Well, yeah, I am." Right. So I think we all shape the product in different ways. And so that kind of collaboration. And I always liked two pizza teams. You can get a lot done with two pizza teams.

Sam Ramji: You can. There's so many shared context and trust, right?

Patricia Boswell: Yeah.

Sam Ramji: You can create a safe space where you can say dumb things and ask dumb questions. And that's really important. And there's an egolessness that can get made in a good team like that. I think that's a really important part of any of these roles. Like an egoless UXer doesn't feel that they need to be the person designing everything or doing all the research, but they will believe that they are the cause of research happening. And they'll teach the team, "Here's how you do a UXR. We're going to do a UXR sprint together." Right? It's about giving away your knowledge so that it can come back in a stronger form.

Sam Ramji: And I think the tech writer component that's often under appreciated is just how technical tech writers are. Right. You're looking at a very complex, multi-variate problem across different releases of software or different versions, different bits of code that are supposed to use it and work with it properly as demonstrations and as documentation samples, maybe SDKs and fully functional samples. And all of those have a huge amount of weight, gravity that you have to carry along with you. Right. When I look at the technical writer who stands out really greatly in my mind is Jared Bhatti.

Patricia Boswell: Jared Bhatti, yeah, I was just thinking about that. I was like, "Oh, he's describing Jared."

Sam Ramji: Right. As Kubernetes was growing up, right? Oh, my gosh. So many changes to deal with. And then the product documentation and the open source documentation, because the open source component makes it hard. And then being able to give away all the credit and do things like organize a Write the Docs Day, where 30 people from the community can get together. And no matter how much any of them put in, they all can take the credit together and share the credit, be like, "Hey, we really improved the state of docs." There's a product ownership mentality in people like Jared that great technical writers and any of the other greats in their domains demonstrate. I'm curious to get your sense of what it means to be a product owner.

Patricia Boswell: Well, I think that for myself, I'd say that I like to see design in everything and patterns. So focus on the patterns, the user patterns, the user flow, sort of the meaning making of the product, like what is Kubernetes about? What problems will it solve? And what it's intended to solve. And so I think when you can get onboard that, from that perspective, you can start to feel motivated about it.

Patricia Boswell: Once you are really passionate about it... So for example, I'm thinking about some of my earlier days in Keyhole, which became Google Earth. And then the graphics engine underneath that. I think about how complicated it can be. A product owner is making it simpler over and over again, just relentless on that. Because people aren't interested... They're interested in the end goal. You're trying to sell them on like, "Hey man, this thing, you're going to be able to load all your visual data into the system, stitch it together, and you're going to have a flyable earth. And you're going to be able to put layers on top of it with roads and all kinds of other different elements that make it literally a globe that you can explore on different levels."

Patricia Boswell: That's exciting, but it's pretty complicated because there's a lot of pieces in there. So you want to make sure that you're trying to simplify the narrative and simplify... And if you can't simplify the narrative, they need to come back and simplify the product a little bit. A really good owner thinks about is the next person. And I think as technical writers, I always think about, we have two audiences. We have the people who are reading the documentation and using the system, but we also have our stakeholders who are working for us. We write for them as well because they may have to take over our work.

Sam Ramji: That's a really good point.

Patricia Boswell: I think that's what I see. I see as like somebody who really takes a great deal of responsibility, but isn't thinking about their craft, right? They're thinking about the problem that the product is going to solve in the world.

Sam Ramji: Yeah. So what I heard you say was a great product owner sees everything as design. They focus on patterns and storytelling, meaning making. They're relentless on simplicity and not only are they thinking about the next user of the service, but the next user of their code, somebody who's going to take over the code and write code, replacing them on the team, maybe in six months or maybe a year.

Patricia Boswell: Or the next evolution of their code.

Sam Ramji: Sure.

Patricia Boswell: Right? Like if you're owning this thing, how is it going to grow? That, too.

Sam Ramji: Yeah. And I particularly love the focus on simplicity. There's a great essay by Joseph Tainter about the collapse of complex civilizations. And what stood out for me in the essay was that as a side effect of human cognition, we add complexity. Like we just can't help it. We just keep like gilding the lily, right? We've got all these expressions about adding stuff. And then at the other end, you've got great designers, maybe a Steve Jobs' quote of design not being done when you can add nothing more, but when you can remove nothing more. He might've been re-quoting Eames, of course. I don't know.

Sam Ramji: But that drive for taking the fur off that invariably grows just by adding humans to a system, super important. And then the respect that you have to pay in modern software, in open source projects, like who's going to be the new maintainer? How do I bring new people on board to understand the code? There's as much need for great documentation of the product and how to interact with it as a developer, if it's an API or a technical product, but there's an enormous amount of value in internal documentation of the code itself to respect that this code could be in production in some form or another for 10 years. You're just the first developer to the fight, but there's many coming after you. How can you make their life better?

Patricia Boswell: There's a responsibility element, so obviously where you're responsible for that. So you think beyond the immediate goal, and you think about the whole life cycle.

Sam Ramji: There's almost a need for like a Hippocratic oath for software development, right? For all of us doing this collaborative engineering.

Patricia Boswell: To be a good product owner, you can take on any different role and be an owner in that role. But oftentimes I think your role will change as well. Really good product owners don't think about their role so much, again, as about the goal and how they can contribute to that whole growth of the product. And tying back again into the two pizza team, sometimes you have to take on those different roles.

Sam Ramji: Yeah, the person that needed to do the job, they've rotated off the team. Job still has to be done. You do it. Or someone's left the company, you've got an opening. You can't just not ship because there's nobody there to do it. Right. You got to step into it. And that's really powerful.

Patricia Boswell: Yeah, it is, definitely.

Sam Ramji: Well, Patricia, I'm really grateful for your time. I'm grateful for the collaboration that we've gotten to do in the past. And now you're the privilege of thoughtfulness as we try to help share what we've learned along the way in building great software, which has got so much to do with the world we inhabit. Users we care about and the data that we have to take care of for everybody in the future. So curious, like, if there's one resource that you would want to provide all developers, right. And we're painting a big tent of developers, all the roles we talked about. If you're a product owner, if you're a product manager, if you're a engineer, if you're an engineering lead, if you're a UXer, if you're a technical writer, what would be the one resource that you'd want to provide all of these developers of software?

Patricia Boswell: Well, I guess I think that rather than a resource, I'd say a little wisdom that I would like to provide is to think about the fact that human beings are story making machines. The story is the way that we make meaning and it's how we communicate to everyone. And so, no matter what your role is, I recommend understanding a little bit about storytelling and then pulling that into everything. Explain your parody as a story, explaining the user's flow through your products as a story, explaining the interactions between the elements of your service as a story. If you can do that, if you can get it across to people, all of those things is almost like an on the fly unit test of your idea.

Patricia Boswell: Does the story play out? Can you get to the end? Did your character find the treasure? Are there too many characters, and it's convoluted and confusing? These are all the things that can come up in the process of telling the story and give you that feedback that you're on the right track or not.

Sam Ramji: That is awesome. Patricia, thank you for your intelligence. Thank you for your wisdom.

Patricia Boswell: Thank you for inviting me on the show, Sam. I'm excited to see where the series goes.

Lorina Poland: Hi, my name is Lorina Poland. I'm a technical writer at DataStax. I've been here for seven and a half years. I've worked on both the commercial and the open source software products that DataStax is involved with, Apache Cassandra, as well as Apache Spark and Apache Solr. I was the primary writer of the DataStax graph product that allows Cassandra to be used with graphs.

Lorina Poland: In listening to the podcast that Sam and Patricia had, talking about the role of technical writing in software, I was interested in a number of points. For instance, Sam and Patricia both felt that telling the story was a very important point. A lot of people don't think that technical writing has anything to do with a story, but in fact, stories are important in a wide variety of different arenas and technical writing is no different than any other. Sam brought up and Patricia really sort of expanded on the idea that if the documentation is good, oftentimes people will assume the software is good. In other words, the documentation oftentimes is one of the primary experiences that users who have not really delved into your product first get their feeling for what your product is about. And if the documentation is not good, a lot of times people won't go much further into checking out your software. That's especially true in open source. People depend on the documentation and the community so much.

Lorina Poland: They also discuss the idea of the two pizza team, a team that's small enough that you can feed everyone on two pizzas. It's an interesting idea. I think that it allows everyone to really feel part of a team and that everyone is a team member, and so you don't get siloed into different aspects of the work. They did talk about small teams needing to have at least four elements, a product manager who is kind of the architect of what the product is going to do. The software engineer, who is the make it so person. Including a UX person for the design to make the user experience one that is useful. And then the tech writer, tech writers tend to play a lot of different roles. I know that I certainly had an impact on some of the products that I've worked on, just from the initial testing that I do to try and figure out how we're going to write about the use, the cases for which our products are a good fit.

Lorina Poland: Lastly, I think that tech writers always have to be cognizant of the fact that the maintenance of the full life cycle of a product will be a long process. A product will generally be online for years, and the documentation for that will need to be updated as bugs or changes are made. Not many other people think about that particular aspect, but like the support teams, the tech writing team is usually on board until the very end of the service life of a product. I thought it was a great talk and there are more talks coming up in Sam's podcast. So stay tuned for what's coming next.

Narrator: Thank you so much for tuning in to today's episode of the Open Source Data Podcast, hosted by DataStax's Chief Strategy Officer, Sam Ramji. We're privileged and excited to feature many more guests who will share their perspectives on the future of software, so please stay tuned. If you haven't already done so, subscribe to the series to be notified when a new conversation is released. And feel free to drop us any questions or feedback at opensourcedata@datastax.com.