Embedding empathy in your software development with Andrea Goulet
Aug 6th, 2021 | 47 minutes
Andrea Goulet is a sought-after keynote speaker for conferences around the world who is best known for defining Empathy-Driven Development. She's a co-founder of Corgibytes, a software consultancy that helps organizations pay down technical debt and modernize legacy systems.
Rob Zuber is a 20-year veteran of software startups, a four-time founder, and three-time CTO. Since joining CircleCI, Rob has seen the company through its Series F funding and delivered on product innovation at scale while leading a team of 250+ engineers who are distributed around the globe.
Rob interviews Matthew Skelton, co-author of Team Topologies and founder of Conflux, on how to structure your team for a fast flow of change. Discover the signs, symptoms, and metrics that indicate your organization's structure may need a redesign.
Rob Zuber: Hello and welcome to The Confident Commit, the podcast for anyone who wants to join the conversation on how to deliver software better and faster. (music). Today you’re listening to episode eight, and I’m speaking with Andrea Goulet, co-founder of Corgibytes and upcoming author of the book Empathy-Driven Design. I guess active author is maybe a better way of describing that. I’m your host Rob Zuber, CTO of CircleCI and the industry leader in all things CI and CD. Andrea, welcome to the show.
Andrea Goulet: Thank you so much for inviting me.
Rob Zuber: Thanks for joining me. I’m really excited about this. So we’ve known each for a while. We’ve met under many different circumstances, different conferences, and I think we’ve done some panels together, et cetera.
Andrea Goulet: Yeah.
Rob Zuber: And actually, I was on your podcast a couple years back, but I think you were unavailable, so it was just myself.
Andrea Goulet: Yeah. It’s been a little crazy this past year. 2020 I struggled to make synchronous events happen.
Rob Zuber: I totally respect that. I think it’s been exciting and interesting and a learning opportunity for many of us and for those of us who were fortunate for whom it was just a learning opportunity. But yeah, I totally get that. But I was thinking of you recently and only then came across what you were up to thinking about empathy and software development. I’m super excited to talk about this today. It’s such a fascinating subject, and it probably will come as no surprise when I say like many people in this field when I think about what’s really important, that’s not the first thing that comes to mind. But interestingly, as a CTO now, when I look back over my career, I became a CTO thinking the T was all about technology. I don’t actually know what it stands for, but really my life is all people, right? All of our lives are all people. And so this is such an interesting subject to take on. So I’m curious, I guess was there an uh-huh moment? Was there a specific point that just tipped you into really spending time thinking about this and even getting to the point of writing a book about it?
Andrea Goulet: Yeah. I think to answer question it’s probably relevant to give a little bit of context about my background and then how I came into the software world, because it’s a little non-traditional. So I graduated with a degree in marketing and business law. I am, quote, the business. And my first few jobs I spent a decade in sales and then more specifically copywriting, which is different from copyediting, which some people who have done technical manuals or things like that tend to think what it is.
Now, I was in advertising, and my job was to sell things with pretty words. And the act of understanding empathy was critical to that job because I had to understand what people needed and what their motivations were. And then the more that I could adopt that feeling and really feel what they felt, the more impactful the writing was. And I specialized in web copy, and I really enjoyed it. And the thing that I really wanted to do more than anything, and this was, gosh, early 2000s. I was like, “I really want to fix error messages. Is there a way that I could be a copywriter but for software applications and not just websites?” And everybody was like, “That’s not a thing. People don’t hire copywriters. The developers write that.” I was like, “Oh, okay.”
A few years later, so around 2009, I ran into a friend of mine, he’s name is Scott, at our high school reunion. And I had been publishing a blog about how I thought about writing, and he told me, “You’re not actually a writer.” I was like, “What?” He goes, “You’re a programmer because your entire thought process and how you’re communicating about writing is all about inputs, processing, and outputs,” because I was trying out using Boolean searches and all this. He’s like, “You are thinking about pros the same way we think about code. By the way, I love fixing bugs and working in Legacy code using XP and Agile. Would you want to come and be my CEO because I love doing this work, but I don’t want to run the business?” And I was like, “I don’t even know what half of those words mean. Are you sure you want me to run your business?”
And so I was working at a large firm at the time, so it was a side gig. I decided, “Yeah, this is a good thing. And the first iteration was, “Okay, let’s build apps,” because the app store had just launched. It was like, “People have good ideas, and turn it into something.” And it failed miserably. I had to take another job, and then I watched Brené Brown’s talk on vulnerability, the TED talk, and this was maybe 2013. And she talked about how empathy was antidote to shame. And during the gap when we were trying to figure between Corgibytes 1.0 and Corgibytes 2.0, I had taken a job where I revised 400 email templates for a customer service for this very large organization. And I developed a framework called using your EAR for customer service. Almost every customer service email starts with, “We’re so sorry that you experienced.” And it’s like, “Wait, you’re apologizing for my experience. That’s actually creating disconnect.” What if we opened with empathy like, “Wow, having this experience really is awful, and we’re sorry that it happened. We’re not sorry that you’re experiencing it.”
And understanding the nuances of those things and how empathy gets executed, I learned a whole lot in there. So the EAR is empathize, acknowledge, respond. And so if you’ve got something … Anyway. So then we were watching This Old House and Scott was like, “I really want to do that. I want to take the craft that they have and I want to apply it to software. I want to take existing code bases, and I want to fix all the bugs, and I want to pay all the technical debt.” As a marketer I’m like, “That’s awesome because that’s a huge market, and nobody else really wants to do this. Why hasn’t anybody gone into this before?” He goes, “Because software maintenance is demeaned. There’s a lot of shame. I am actively bullied because when I tell people that I like fixing bugs, they make fun of me.
And he said, “I’ve worked at so many jobs, and they make me write features. And I don’t want to write features. I want to refactor. I want to improve the test suite. And no one will let me.” And that just seemed really interesting to me. And I had experienced this in coding like, “Okay, let me ask something on Stack Overflow as a newbie.” And just like, “You’re an idiot. You don’t know what you’re talking …” I was really taking it back at them now of shame in the software industry and then within the software maintenance community more specifically.
Rob Zuber: You call it the maintenance community, but what I think what you were talking about with Scott is even within an organization as someone-
Andrea Goulet: Oh, totally.
Rob Zuber: … who’s interested in working on that.
Andrea Goulet: Yeah. It’s like the movie Office Space. We now say Menders. So Scott and I were like, he was like, “There’s this maker community. Where are the people for me?” I was like, “Well, we can create a community. What do you want to call yourself?” He’s like, “I don’t know.” We went through all these iterations. And so Mender. And so then we started like, “Okay, we’ll do Legacy Code Rocks. Let’s reframe the narrative on Legacy. Let’s make it a good thing like it is everywhere else. You’re writing your legacy. Let’s think about this differently.” Now we organize MenderCon. Reclaiming that. But it kind of felt like Milton from Office Space where it’s like there’s no power in it, you’re made fun of. It’s like, “Go code in the basement.”
I think a lot of this had to honestly with the release cycles, because in the ’90s when we weren’t doing CI/CD, it was like, “Okay, software maintenance is where good careers go to die.” Because we weren’t thinking about continuously improving. And so we had this idea of like, “Okay, shame is really a thing that’s the problem. Empathy would be really good. I understand empathy, so I can lead with this.” And what was fascinating was that we got so much pushback. We hired a consultant early on. And we were like, “Empathy needs to be the anchor of our organization.” And we had a consultant say, “You can’t use the words empathy and software in the same sentence. You will be laughed out of the industry.”
Rob Zuber: Well, it’s really interesting because one of the things I thought as you were telling that story you said 2009 launch of the app store. I’m like, “I can’t quite picture 2009, but I remember when the app store launched.” Kind of these anchor points. So when would that have been? Because I feel like now-
Andrea Goulet: Yeah. This is like 2013 maybe.
Rob Zuber: Got it. Yeah. I mean, a lot has changed in software development. A lot has not unfortunately, but a lot has changed in software development. As I said, I feel like I use the word empathy hourly, if not more. And part of that is just also career growth like what we learn to do as we are leading teams versus just being a team member. That’s really fascinating. It’s going to take me a second to wrap my head around that. One thing that you called out in there was thinking about pros the way that we think about software. And I saw this quotation that you had. I’m going to get it wrong, but in one of your pieces about we’re not communicating with the computer. We’re communicating with people through a computer.
Andrea Goulet: Yes.
Rob Zuber: And thinking about the software that we write even, yes, it has to be syntactically correct to get the computer to work, but it is a means of communicating with our future selves, with future others, both developers and then with the people that we’re actually … The error message story is absolutely comical to me. As much as I love knowing that error 1957 occurred, what am I supposed to do with that piece of information?
Andrea Goulet: Exactly.
Rob Zuber: So tell me about that. Tell me about communicating with people. What does that mean to you as you think about software and as you built out this view of Legacy and mending?
Andrea Goulet: Yeah. I think part of it is through the podcast. So we’ve interviewed, I think, 75, maybe 80 different people now. And I started to notice themes, and one of the things that people who love mending software, they connect to the people. That was something that came through very clear. That and thinking about the value. It’s like I get to work on something that actually is making money and impacting people’s lives. I’m not working on this greenfield thing that theoretically could make a difference. The work that I am doing actually makes a difference to people.
And so I noticed that there was already a lot of empathy. And then when you start to look at just software history, anything that has been built to make somebody’s life better is rooted in empathy and compassion. So the whole reason that we have DevOps, right? We had developers and we had operations. Hey, let’s make them to work together and understand each other. That’s empathy, right? Why do we use compiled languages? Grace Hopper was like, “You know what, my brother is a banker. And transposing octals into decimals is a huge waste of time. Let’s create a language that is easier for people to use, right?” And so there has been this everything even back to the earliest machines with Blaise Pascal and his earliest calculators and Charles Babbage and Ada Lovelace. It’s all rooted in how can we help people.
But what has happened, especially in the 1960s. I think there’s two inflection points. One was in the mid to late ’60s. There started to be an abundance of aptitude tests. And there was one study in particular that outlined very clearly based on some kind of dubious methodology that if you are in business, you have no place in programming. And if you are in programming, if you’re a business programmer, then you’re less than. And they even have these comics of women, voluptuous women, and it’s like the scientific programmer gets this voluptuous woman. And it’s like, “Okay, that’s a problem in and of itself in a research paper.”
So we start to bifurcate and value judge, and they even list there. It’s like, “Feature development has more value than software maintenance.” And these myths get built back. I think the other inflection point is when we introduced the graphical user interface, so the introduction of Macintosh. If you think about Tron, which was produced in 1982, the line in there is I fight for the users. And at that time user and programmer were synonymous everyone used command line. That was what you had to do. But then with the graphical user interface, the user became something different than the programmer. And you start to see real programmers understand the command line. And if you’re not, then you’re not technical. Not only were you not a programmer, you had zero technical skills. You don’t even belong.
And as somebody who was on that side, I grew up with a Macintosh. My dad bought one in 1984 when I was a kid. I didn’t even use a command line until honestly I started at Corgibytes. And so I’d always embody this non-technical piece. And [Sky 00:15:20] had had the opposite. He used a command line and really understood. And so he got the message of, “You’re bad with people.” It’s like, “Why have we separated this? This is all here. Empathy, I mean, it’s complex. And at the same time once you understand it, you can start to see it everywhere.” A well-written commit message is an act of empathy.
Rob Zuber: Oh my God. Commit messages. We’re about to go down a whole other path. I’m going to let that one sit. I mean, actually, I’m not because commit logs. I find myself in this conversation all the time where I’m saying, “As the person who’s going to be debugging your software with your commit logs, it would be super awesome if they made any sense.”
Andrea Goulet: Yes.
Rob Zuber: Safety commit is not helpful to me. Please squash that out. That whole thing of this is a historical artifact, and I need to be able to understand. I want to highlight that I also had a Macintosh in 1984. So I’m not a software developer by formal training. I went through engineering physics. And at my school I was the only kid in my entire engineering program of 500 kids who was using a Macintosh. Interestingly though it got me a summer job. So that was cool, but a long back story there. Yeah, there is a bunch of different pathways. There’s a bunch of different experiences. And all of them can help you grow and bring different perspectives to the table that are super valuable.
And I spend so much of my time now talking about helping engineers build a connection to their ultimate end user, right? That you drive more business value and you develop more successful when you understand the needs of the user directly. A huge amount of what we try to do with CI and CD is put your work in front of a user as quickly as possible so that you can get that feedback and feel more connected. I feel like a lot of what you’re talking about I see us actively trying to undo. We just haven’t named it as effectively as you have.
Andrea Goulet: Right. Yeah. I think that’s the book, right? That’s my goal with the book is to basically say, “Okay, you all. Here’s where empathy is. We’re going to use some precise empathy language. Here’s how empathy is different from pity and sympathy and compassion and understanding and all these things. And then here is how we are embedding it into our software.” And we are actively already doing it. It’s pausing and just paying attention. And so the way I describe it it’s about anchoring your decision-making and your deliverables on the perspectives of other people. That just takes a moment to pause.
I think people already do this. A lot of software engineers I talk to or when I give a presentation, the practice of perspective taking is for most people how we code. A lot of times it’s like you’re thinking sometimes even about like, “Oh, let me take the perspective of the electrons flowing through the system.” So you can use that same skill. Honestly, empathy is about collecting data about both logic and emotions. It requires both, and then validating that that’s correct.
It’s about increasing our understanding and increasing our alignment. Am I truly understanding you? Am I walking with you? Because you can never replicate somebody else’s experience, but you can verify and double check and get closer to. And pointing out that, “Okay, if every single commit title that you have is update API, then that’s not useful to people who come later, right? And let me just think for a moment what will be useful to myself in six months,” and then widening that circle bit by bit as you get more advanced with it so, “Okay, what is my CTO going to need?” And sometimes you don’t know. And so it’s about building that understanding, right? And so you as the CTO being able to say, “This is really important to me. These are the things I need in order for me to do my job better.” And then also communicating, “Here’s how I feel if I do get it or if I don’t get.” And then we are building rapport. We’re building better products. We’re having fewer missed experiences.
When we extend this into society at large, it helps us understand the implications of our decisions not just for the people who we interact with what we build, but who will be impacted by what we build, because sometimes they’re not the same people. And just pausing and considering. So really, with the book is kind of an index of consideration sets and, “Okay, if you’re writing a commit message, here are some possible audiences. Here’s the anatomy of it. Here are some things that you might want to think about.” But in the end, it’s like pragmatic programming where it’s like, “I can’t provide every single context. This is on you.” But the practice of pausing and thinking and saying, “Do I have enough information, or am I operating on assumptions?” And then constantly striving to do better. I mean, it’s continuous improvement. That’s really what it is. And so linking the terms that feel odd to the practices that we already know, I think that’s where I feel really impassioned. And I feel like I understand both these worlds, and I can be a translator to help people recognize that this divide between technical and non-technical is a complete illusion.
Rob Zuber: I mean, to me, that’s such an awesome perspective. I’ve heard you mention that empathy is something that can be learned. I’m assuming you wouldn’t be writing a book just for people who are already rich in empathy and applying it everyday.
Andrea Goulet: Yeah.
Rob Zuber: So tell me a little bit about learning. And tell me how do you get someone to acknowledge or recognize that that’s a thing that they should learn? What’s the hook to then get me to open myself up to say, “Oh, now I want to import all this information and absorb it and learn from it?”
Andrea Goulet: Yeah. It is the what’s in it for you. And it’s the benefit. By running an organization with empathy, our developers get a lot of focus time. We have fewer interruptions. Is that something that you would find valuable? Would you like your managers to interrupt you less? Because, guess what, if you take their perspective and if you learn what they actually want, people interrupt you when they are feeling like they’re not understood, or they’re feeling that there’s a disconnect. So if you’re getting constant interruptions, yes, there absolutely might be a cultural aspect to it too and a cultural urgency. But we had this happen.
I came from the marketing world and advertising, and everyone is fleeting all around, “Hey, you got a sec?” Scott and I we’ve been working together for a couple of years. And there was an email that he needed to respond to. And it had been a couple of days, but it got to the point where it was really urgent. And I needed to interrupt him because there was a business reason. We would lose a client if this didn’t happen. So it didn’t feel to me like a fake emergency. It felt like a real one.
And so I interrupted him and said, “Hey, you got a sec?” Which worked perfectly in the context of advertising. And he nearly flipped the table, and I saw his face. And he just looked so frustrated. And I was like, “Okay, I can tell that I really hurt you. What happened?” And he responded of, “I was nine inception layers down. I had six different mental models that I had to construct. And you even asking me that question like the movie Inception I saw all of my work that took me three hours to get to break apart, and it’s going to take me another three hours to get back.” And I was like, “Oh my gosh, that’s a lot.” I don’t want to do that again, but by knowing the frustration, we were able to come up with the solution. So what we do now is we call it inception. And it’s much easier just to name how deep are you because you don’t lose your mental model when you just name something. It’s like diving deep. What’s my barometer say? But, “Hey, how long is it going to take you to get back up to the surface?” It’s like, “Ahhh.” There’s a lot of cognitive load that happens there.
So then we were able to co-create these systems that really worked, but it doesn’t happen unless you proactively take the time to understand each other’s perspectives.
Rob Zuber: Yeah. I use the expression flow. I’m really enjoying this inception analogy, but I think it is a huge thing. It’s fascinating. Even as engineering leaders and managers, you start to lose that perspective because you get further away from it. I had chills as you’re telling me. I’m like, “Oh yeah, I remember that state.” I was like, “Oh, wait, fewer meetings. How would that work?” But it’s a real thing. I mean, it goes back a long way. I think it was a Spolsky post on the calendar and what happens with these 15-minute meetings every three hours. It’s like, “Well, I might as well not even bother doing anything for the next two hours because it’s going to take me too long to get back in there,” sort of thing.
Andrea Goulet: Exactly.
Rob Zuber: So it’s interesting actually that you tell that story because it’s a very clear example, and as I think about all the examples of people expressing that. As a developer, thinking so clearly about sharing that understanding. I mean, maybe we’re not good at sharing it sometimes, but sharing that understanding, but then not necessarily acknowledging, “Oh, this is the true model of empathy, right? This is us understanding each other in a way. So let me stop and understand your needs.” Clearly there was a need around that email. I mean, I wasn’t there, so I can’t project how this could have played out, but there was probably a point where Scott wasn’t deep in something and could have taken-
Andrea Goulet: Exactly.
Rob Zuber: … a moment to have that conversation and build into that path where you [crosstalk 00:26:45].
Andrea Goulet: Yeah. And his was, “I’m an engineer. I don’t have to respond to emails. That’s your job.”
Rob Zuber: Well, okay. So I could see there was some work to do.
Andrea Goulet: He told me I could say [crosstalk 00:26:54]. I mean, that was his thing because he was like, “No, I’ve been told. We have patterns. We have gatekeeper patterns.” Like, “That’s not my job. Somebody else is supposed to communicate that. That’s why I hired you.” And I was like, “Wait, that’s not what I signed up for.” Like, “No, you’re an entrepreneur now. You are not an engineer. You’re a business owner. You need to reply to emails.” But it was one of these like, “Okay, when you take that previous context assumption and put it into this one, it’s not going to work.” And so then getting to the heart of it and understanding like, “When you don’t reply to an email and then I have to drop everything and respond to that, it hurts me, and here’s how I feel.” And it’s like, “Oh, okay, now I understand.” And then you can recall that frustration. It’s like, “I care about Scott. I don’t want to interrupt him unnecessarily. Let’s find a solution. Let’s stop these misunderstandings.”
And that’s what happens in the code too back to commit messages, right? If you document, it’s almost like anthropology or archeology. I call what gets embedded in the code, right? Because that’s the part of the driven development is that there’s something that’s executable that gets imbued in the code. And the thing is communication artifacts. And you can look at things that are really close like tightly coupled to the code, so commit messages are ones that I use or test even variable names and method names. But then you’ve got architecture decision records, you’ve got user-facing documentation, you’ve got emails to colleagues, you’ve got slack messages. There’s a whole lot there that when you start to see them as like this is an artifact of my thinking, that I am living for posterity to leave a legacy of my thinking so that somebody else can pick up, and it’s going to be less frustration for them to understand where I was coming from or understand what I was trying to accomplish.
And what we’ve seen in the 12 years that I’ve been doing Legacy code is that the teams that do this, there are teams that do this really well, they don’t have technical debt. They’re the ones who are actually able to achieve a true CI/CD pipeline and actually do it. The ones that are doing things based off of just like, “Ah, checklist. I got to do this. I hate this. Who’s even going to read this?” Who is going to read this? Take a minute. Think about it. Provide some value for them. And then you can really advance. So yeah, it’s been a marrying of these two worlds, but it absolutely has to do with technical debt and code quality and how fast you can deliver. And so to me it’s another type of impediment.
Rob Zuber: Yeah. I love that connection. Our intro, our tagline on this, whatever. Of course, I live in a world of CI and CD, but thinking about delivering software better and faster. Well, I have no idea what the percentages of that. I’m trying to think of what percentage of people wake up in the morning and think, “You know what, if we all want to move faster, let’s have more empathy.” That’s the first thing that comes to mind. There are some. I mean, obviously you are amongst them. So it’s such an amazing question. When I think about then downstream where downstream is either somebody else in the process, me tomorrow because I was in the state of flow and I had all this stuff loaded up like, “How fast can I get it loaded up again?”
If I’ve taken this really gnarly algorithm or whatever and pulled it out into a method or function and given it a name, it’s so much easier to come back and say, “All right, it just does that thing.” And now I don’t even need to remember what the implementation-
Andrea Goulet: That’s an act of empathy.
Rob Zuber: … was of that thing, right? Again, maybe it’s for me, maybe it’s for the next person who comes along and says, “Okay, I need to add this one edge case. What is this thing, right?” It’s funny that you mention also … Mending in general just reminded me of this … It’s like a dumb thing, but a project that I worked on before I got to CircleCI where we had this function, and it was this really complicated log in thing or something. And we always joked that it needed constant gardening because the number of edge cases that came in kept growing and growing and growing. And then about every month someone would volunteer to pull it apart and name subsets of it and say, “Okay, now it’s grown so much again that we don’t understand it, so let’s pull this piece out, and we’ll call it this.” And everyone knows, “Okay, I don’t need to think about that unless I’m dealing with that particular case.”
So I was going to ask you this question. I feel like it’s all coming to me in this moment. When you think about this, what are the long-term impacts? How does the overall project, your ability to get more done to deliver more value? I guess how does that show up between, as you mentioned, teams that really have empathy and focus on this and teams that … I don’t know what to describe the other team as, but that don’t?
Andrea Goulet: Yeah. I think it shows up in a few different ways. And I do think that the culture has something to do with it. So I think that it needs to come from both a bottom-up and a top-down for it to be most successful. Now, given that we have seen teams within larger organizations that have created their own culture that have been able to do really well. One example is we had a project that we have been working on for years and years now. When they first came to us, they couldn’t build. They couldn’t release. The process was so difficult, and they had hired a marketing firm that got a little over their heads and just named all this different stuff and how to custom build process that didn’t work. And I think what we do is when we come into a project … This is why empathy is at the heart of our organization.
I think so many times people who adopt the work of other people really degrade it, and this is where Shane comes in. It’s like, “What idiot wrote this?” Somebody who is in marketing who learned how to code and did the best they freaking could, right? And we’re going to honor that work, right? We have some clients that come to us, and it’s like they’re not at this goal. It’s like, “You’re revenue generating, right? You created this thing. You have a successful mess. Be proud of that. We can build on that. We can make it better.” And so a lot of it is the attitude, and this is the attitude of empathy. And so that client we were able to … The business need was they had a huge convention where they were going to showcase this in March, and we had inherited it maybe four months prior.
We got it, and so then it’s like, “Okay, what do you actually need?” And that’s working with business people, salespeople who we’ve been told like, “Oh, we’re developers. We’re not allowed to talk to them.” No. Like, “What do you need to sell your product? Let’s use that for prioritizing, not what I think.” And then over the years it’s we monitor technical debt and test coverage and all of that. It was going to take them 500 years to pay down their technical debt when we first inherited to now it’s clean. The backlogs are always groomed, and they’re releasing regularly. And I think that’s the thing is that you can absolutely transform a Legacy system into a beautiful garden. And like you said, it takes nurturing. That’s the key.
And when we plop shame on top of that, and it’s like, “No, the only great thing is building something new.” It’s like, “No, there’s a lot of amazing work in nurturing something and watching it grow and developing something, right?”
Rob Zuber: Yeah. It’s so interesting that personal connection. I feel like at some point you get to a place where … You mentioned earlier. It’s usually the Legacy system that’s making all the money, right? It’s not some theoretical future revenue stream. It’s that thing that’s sitting in the corner that nobody wants to work on that is actually driving your business. And so these personalities or goals that we give ourselves make it difficult to focus on the things that really matter sometimes like, “Oh, I want to work on this new either features or new tech, right?” That’s another big driver. It’s written in … I don’t know. Whatever. It’s [inaudible 00:36:03] these days. But like, “I don’t want to work on the Java thing.” Like, “Someone’s building this new thing in Rust over here. I want to go work on that or whatever.” And there is so much value in maintaining and building on top of these really, really important systems.
So let’s talk book for a second. I mean, what was the driver, I guess, behind putting this in a book? I’ve never written a book before. I mean, you talk publicly all the time, you write blogs. This content it’s developing and it’s out there. What motivated you to put it all down and the full package?
Andrea Goulet: Yeah. I think I published my first blog article in 2016. And I’ve been featured in the first round review, and that went viral. Yeah, I have been talking about it for a while. I’ve always wanted to write a book, and honestly it was one of these COVID shook everything up, and it accidentally gave me the space. I have one of my friends in … But they were like, “Yeah, of course, you’re the type of person that’s found a book deal in a pandemic.” And I’m like, “I’m sorry.” But it did happen by circumstance. And I recognize that’s not the normal path. But no, I’m friends with Lyssa Adkins. She wrote a book about Agile coaching.
And we were just catching up last year. I was telling her about I had taken a step back from Corgibytes operations just because I have two kids. We needed to get some work done. So that was my thing for a while. And it gave me space to really think about like, “What do I want to actually do? I enjoy working on the organization, but is there a way to have more of an industry impact?” And I was describing what I was thinking about to Lisa. And Lisa said, “It’s really interesting. I just got off of a call with my editor. And they are looking for a project that is pretty much exactly what you just described, so let me put you in touch.”
And so I think a lot of it was timing. I think people are ready. I mean, because genuinely 10 years ago people laughed at me, literally laughed at me. When I said I want to build a team of people who love paying down technical debt and fixing bugs all day, laughter from people. And they were like, “You’re never going to be able …” Now it’s like we have no problem finding developers who love doing this because we’ve created the culture and the operations that’s going to support that work. I think the industry is ready. I think it’s very topical, especially all the stuff with 2020. People want to know how to do this.
And so that’s the audience, and then the next one is analyze of how accurate is the information? Do you have the information you need? How confident are you in understanding? Act, which is actually building the artifact or doing the development, delivering the thing. And then the last one is accelerating, which is sharing information, building a culture of it, building systems that will support it.
Rob Zuber: Got it. So you mentioned as you were describing that, and I love that framework, by the way. I was thinking about how we use data sets plus personas to think about who are our customers, to give it a name and a description feel like, “This is someone I’m friends with.” And then maybe I project a little bit of someone I know, and then that gives me a much clearer picture. To your point, charts and graphs are awesome and knowing that this person represents a good subset of our audience. But you mentioned maybe that’ll evolve as you continue on the manuscript. I’m curious, you’re about a year from publishing on the current timeline, right? So it sounds like you have a lot of thoughts. Is it still evolving? Are you through this process, getting even deeper and building out new things, or is this just about now getting the whole message down on paper, which I’m sure is time consuming also?
Andrea Goulet: It’s a lot. I mean, writing a book is the hardest thing I’ve ever done. It’s really hard. I’ve heard people who have written books say, “It’s really hard.” I have a lot of experience in putting it into a way that’s really concrete. Because when I’m talking to somebody, if somebody doesn’t understand, then I can give them context or I can answer questions. But with a book, I’m not going to be there. I have to transmit all of this information, so trying to find a way of using empathy while writing the book, so trying to get practitioner feedback. So I have a website, empathyintech.com, that people can go to if you want to sign up. I’m going to be asking for more practitioner feedback on how does this actually land, because I want this to be useful. I want this to be something that people can implement.
Alistair Cockburn, who is one of the Agile manifesto signatories, his is great framework. He calls it ShuHaRi. I don’t exactly remember the context, but I do remember that put things into a shoebox, make things very concrete kind of like SCRUM where it’s like, “Okay, first do this. It’s two week sprints. We do this and replicate it.” And then as you go up, it’s so instinctive and it’s so intuitive that it’s hard to decouple and make it really concrete. I think that’s where I am. I’m in that middle place where I want to make sure that what I’m talking about is effective and that I’m communicating it well, but I know that it works because I’ve been doing it for over a decade. I’ve been talking at conferences. People have told me that this makes a difference, but being able to find a way to … I feel like I have a duty to do the best that I possibly can.
I think you’re always evolving. When do you stop? When do you stop making a code base better? When do you stop making your personal growth better? I don’t think you do stop. It’s constantly honing or refining. But I will have to stop at some point because my editor needs to send it to press. So yes.
Rob Zuber: Right. That’s so fascinating to think about, that sense of finality and wanting it to be perfect. I’ll just say, first of all, I super appreciate your sense of duty around this. I think it is really, really important. It’s also just very cool. I mean, I’m excited. I will sign up and see the pieces as they come, but I’m also excited to read the book in its entirety and see the flow. You can create posts, and then you can go back and revise and edit them, and the next person to come and read it. I mean, Errata and second editions and stuff. Books they’re really fixed in that way, which is cool and probably motivating and at the same time a little scary I would guess.
Andrea Goulet: Yeah. Well, and I think some of it it’s the feedback loop, right? I’m used to moving towards a more continuous integration mindset.
Rob Zuber: That’s right. A book is waterfall.
Andrea Goulet: I mean, the nature of it is that you send it out and then I’ll get feedback, but I won’t get to iterate on it very fast because maybe there’ll be a second edition if it sells, but there’s no guarantee that there will be.
Rob Zuber: It’s so funny. I read tons of books, and I don’t try to then engage in a community around those books other than maybe my local book club or whatever. But is that something that now folks are doing where there’s more, “And now here’s the dialogue and come join us here, and we’ll talk more about it?”
Andrea Goulet: Yeah. We have a Discord channel. So if you sign up for the email, you get a link to the Discord channel. It’s open to everyone. And I think this is the thing that I learned with building the Legacy Code Rocks community is let’s take the shame out of it by using empathy, right? Let’s create a place where if you love software maintenance and you want geek about refactoring and, “Oh, I use the Strangler pattern. This is amazing. Yeah.” Awesome. You’re not going to be laughed at here. And just like what we did with Menders, my hope is that we can build a place where no matter whether or not you’ve been called good with machines or bad with people or bad with machines and technical or non-technical, whatever. If you think that we can be understanding each other as people better and then using that information to build better software, great, you belong. Let’s have the dialogue.
Because, to me, I think the problem has been we’ve been isolating. We’ve been self-selecting out. We’ve been unconsciously using language the others people. And when we recognize it, we can change our habits, and we can start to learn things in a new way.
Rob Zuber: I just want to end right there. I don’t want even want to say anything after that. You belong. Let’s have the dialogue. We’re done. Andrea, thank you so much for joining me today. This was amazing. I learned a ton. And I’m not going to be shamed about the things I didn’t know, but just delighted that we had the chance to speak and for my own continuous improvement. Hopefully, everyone listening has enjoyed it. And to everyone listening, thank you so much for tuning in. If you enjoyed this, if you enjoy our podcast, sign up or subscribe on all your local networks or maybe you just need one. Anyway, and if there’s anything else that you want us to talk about, hit us up on Twitter @CircleCI. Andrea, thanks again. Just absolutely amazing. I love what you’re doing, and I’m really looking forward to reading the whole book, but I probably will have devoured all the content before [crosstalk 00:47:19].
Andrea Goulet: Awesome. Thanks, Rob. (music).