Leanpub Podcast Interview #23: Patrick Kua

by Len Epp

published Dec 22, 2015

Patrick Kua is a technical leader and agile coach for ThoughtWorks, and the author of two Leanpub books, The Retrospective Handbook and Talking with Tech Leads. Patrick is also a blogger and frequent conference speaker. In this interview, Leanpub co-founder Len Epp talks with Patrick about how he began his career, his thoughts about the importance of retrospectives, and the various challenges tech leads meet in the course of their work.

This interview was recorded on August 10, 2015.

The full audio for the interview is here. You can subscribe to this podcast in iTunes or add the following podcast URL directly: http://leanpub.com/podcast.xml.

Patrick Kua

Len Epp: Hi, I’m Len Epp from Leanpub, and in this Lean Publishing Podcast, I’ll be interviewing Patrick Kua.

Patrick works mainly as a technical leader and agile coach for ThoughtWorks, bridging the technical and non-technical realms, leading teams and writing software with a particular focus on helping teams improve through the practice of retrospectives. He blogs on various topics at THEKUA.COM@WORK, and you can follow him at @patkua on Twitter. Patrick often speaks at conferences, and you can find a number of his talks on YouTube, including The Geek’s Guide to Leading Teams, where he discusses the idea that the most challenging aspects to software development are always the people issues.

Patrick is the author of the Leanpub books, The Retrospective Handbook: A Guide for Agile Teams and Talking with Tech Leads: From Novices to Practitioners. The Retrospective Handbook draws on Patrick’s 10 years of experience running retrospectives to unlock their potential for your team, while Talking with Tech Leads lets you discover how more than 35 tech leads have learned to balance the technical and non-technical worlds.

In this interview, we’re going to talk about Patrick’s professional interests, his books, his experiences using Leanpub, and ways we can improve Leanpub for him and other authors. So thank you, Patrick, for being on the Lean Publishing Podcast.

Patrick Kua: Thanks for having me.

E: I usually like to start these interviews by asking people for their origin story. I was wondering if you could tell me how you first became interested in becoming a developer, and eventually became a tech lead?

K: Sure, absolutely. I guess I count myself lucky, because I fell into the industry relatively early. I mean, I’d played around with some Commodore 64-type stuff as a kid, but I never really got into the whole geek developer from very young. And then when I was in high school, we got introduced to sort of computers pretty early on. I had a really great teacher who was teaching us about software development, and I really got sort of, I guess my mind blown around the stuff that you could create from nothing. We were asked to develop a sort of film rental sort of system, using - back then - Microsoft Access, of all things – things I would never, ever recommend right now, and I kind of fell in love with the things that you could actually create.

That led onto a natural path of me wanting to study more about this at university, and I did a double degree in commerce and I.T. Double degrees are really popular in Australia, which is where I studied. So I ended up doing a commerce and I.T. degree - partly interested in the business side, as well as the technical side. So it’s already an interesting sort of balance out.

After university I went to start work for Flight Centre, whose headquarters are in Brisbane, and then joined shortly after, Oracle - who had an R&D center in Brisbane. There I was really lucky, because the team that I was working with, they were very early adopters of extreme programming. This is in the very early days of XP, which was - I guess - the early 2000’s, where we were playing around with the first continuous integration server, CruiseControl, which was actually built off of CVS, where we were introducing unit testing and JUnit.

For me, it was just such a really interesting contrast, because Oracle is kind of a behemoth, and there’s probably a lot of very traditional software practices - and we were a very small part of it, trying to change the way that we were doing software. This kind of naturally led on to where I ended up joining ThoughtWorks, whose Chief Scientist is Martin Fowler, one of the agile manifesto signatories. I’ve traveled around, and worked with ThoughtWorks for quite some time now. I think this year is actually the 11th year with ThoughtWorks.

E: That’s a long time. And have you been working with them in London the whole time?

K: I started with them in Brisbane, in Australia. We actually have, I think now - four offices. And, yeah, I transferred over to London - I think it was about 2005, where I’ve been based in London for probably the last 9 years. But being a global consultancy, we ended up - we were pretty good at actually shipping people around the world if they want, because it keeps our culture very consistent. It’s a way for us to sort of build our own network, and get exposed to new sort of experiences.

So, I’ve spent the tail end of winter in Calgary once - and summer, which was a beautiful city. I’ve spent about four months in India, amazing country - sub-continent. And I’ve spent, I don’t know? Probably on and off, probably a whole year in total with ThoughtWorks in Germany.

E: I read a blog post on your website about your year in Germany, and becoming fluent in a year. It was quite impressive, I thought, and I was wondering if you could maybe say a little bit about how you approached that year long project, and what the results were?

K: Absolutely. I guess I was kind of lucky in that - with ThoughtWorks, after 10 years, we have a sabbatical period. So, you get paid the equivalent of about three months’ worth of time, where you can choose what you want to do. When you’re presented with an opportunity to take three months off of work and do what you like - I was kind of like, “Oh, it’s really tempting. I never took that gap year that a lot of people take after university, maybe this is the time to do it?” So I actually had the year off, which was a fantastic opportunity, and I have so many great memories from that time.

I think, if you live in Europe and you come from an English-speaking background - like Australia or the U.S - it’s amazing how many people that you meet in Europe who are at least bilingual, if not more. For me it was kind of, like I don’t know - I would have always loved to learn another language fluently, and so for me this was a really great opportunity to do that.

Because I’d spent a little bit of time there for work, I’d learned some German. But it was what you might use as a tourist. So, I could order a beer, I could order for the bill, I could read some things off menu. But it’s really far different from actually living there and being there. So I made the choice to live in Berlin, which, to be honest, is not the best place to learn German. It’s so heavy with so many tourists, and I think Germany’s level of English is actually pretty high, so you can get away with actually not speaking any German if you really don’t want to. I know a few expat people who lived there for maybe three or four years, and their level of German is still sort of rudimentary, I guess tourist-level.

But knowing this helped me prepare. Because my motto going in was, it would be very easy to fall into this expat community and only speak English. So I really forced myself to sort of to pretend that I was in a small, little German village somewhere, where I was surrounded by only German speaking people. All the opportunities for the first, at least, three months, I would make sure that I’d be forced to speak German.

I had a really great flatmate, who knew that I was learning German, and was patient enough with me to only speak German to me - even though it was a very tough few weeks when I first moved in, and couldn’t communicate. I kind of felt like, I could now imagine how a baby would feel. In that, a baby who’s trying to get across a message - can’t, because they just don’t have the vocabulary, the words. And just that frustration, it’s phenomenal.

I think I remember breaking down one evening in dark winter in Berlin, saying, “Can’t we just speak English? I’ve just got to get this out of my system.” And my flatmate was actually really good with me, and said, “Nein!” in German. That was exactly what I needed, was the soft hand approach, but really firm that I was going to keep doing this.

I signed up for immersive German lessons, which was really important. So, I think we did classes from about 8:30 to about 1:00, every day. And then normally there would be homework and field trips afterwards. I think that really helps provide structure, and a really good learning ground to get the basics.

I think one of the benefits of actually going through an experience like that is, you also meet people at a similar level. So I think everyone’s patient with each other, because they understand, they’re also learning - and you’re just as patient giving other people space, because you know that they know the words in English, but you’re struggling to find and remember what the words are. That was really important.

I definitely recommend people get a tandem partner. There’s a concept that’s really popular in Germany - I don’t know how that translates and how popular that is overseas as well. But it’s basically somebody who’s learning the language that you’d like to learn, or who’s native in that language - and who’d like to learn English, or another language that you can speak. We would meet maybe once a week, for a couple of hours, and we would speak an hour of German, and then we’d switch to an hour of English, so that we both had time to practice. It was really helpful, because the language school that I went to helped connect us around personal interests. We spent a lot of time visiting different areas of Berlin, going to different events. It was just a really great way of meeting a new friend, having an opportunity to practice and focus, and get better at that.

E: It sounds like a really interesting idea, also because usually the teacher-student relationship, especially with language, has this kind of dominance on one side, and humiliation on the other. So, actually combining two people who each know that the other one is fluent in the language that they’re trying to learn, really balances that out.

K: Yeah absolutely. That’s such a key thing, and I think you hit on a point which is - I think there is that different relationship with a teacher and the students.

I guess another tip that I would give people is: it’s really worthwhile, if you’re going to learn something, to learn from lots of different people. It’s interesting, because everyone has their own bias about preferred learning style. And I think teachers have their sort of bias about how they believe that people learn best. It doesn’t always work.

So, I think we went through about four different teachers, over the course of three months. Just because of the level shifts, and different timings of classes. It was interesting for me to watch how one style of teacher didn’t really work for me, but it worked for other people. And then, another teacher who worked for me, didn’t really work for other people in that class. That’s where I think it’s really useful, to get exposed to lots of different teachers.

It’s something that I picked up from software development as well. Which is, you have so many different people who you can learn from, and each one has something very different to teach you. I think that’s a really important thing - when you’re progressing in any skill development, is that you get exposed to lots of different ideas. You may not necessarily take away everything that that person has to offer, but it does give you a different perspective.

E: Yeah, that reminds me of a line from your website where you’re talking about programming, but obviously it can apply to other areas as well - where you say that you believe strongly in self-empowered teams and individuals, having seen many talented people beaten down by the systems that they work in. The idea of empowerment, but also the element of individuality that’s inevitable in empowered teams, is also very important.

I was wondering if that came from - that particular feeling - maybe came from a personal experience you had with being beaten down in a big system, or was it something that you were fortunate to avoid yourself and just saw in other people?

K: I guess I consider myself pretty lucky, because I haven’t worked in a - I mean, I’ve worked with Oracle, but not in a large system where I felt beaten down, at least for a long time. I think that’s maybe one of the benefits of a consultant, is that you see lots of different environments.

What I really love is actually helping people get over these systemic things that have beaten the motivation out of people, where they’re just getting on with their tasks that they’ve been told to do, and helping them connect with the things that they really like. I’m a big believer in sort of Dan Pink’s Drive book - autonomy, mastery, and purpose. In that, if you can give people a reason to engage with the work that they do, and they can develop themselves at the same time, and they have an ability to choose the things that they think will help get them to that purpose – everyone benefits. Like, the people who are working on that sort of tasks are a lot happier - I think the job will be done a lot better.

And so, whoever that is for - be it the end customers or the business, everyone wins. I just wish that more people had that approach of, how can everyone find the solutions that work well for everyone? It won’t always be optimal, but trying to at least have that conversation with people around - “What drives you? What are you interested in? And how can we make that work for you in this environment?” I guess that’s what led me to be a very independent person, which I think helped me when I was learning my German language skills, is that I was just doing things that I felt interested me, that helped me - and then I’d find people to help me keep engaged, so I still had that purpose.

E: Yeah, it’s really interesting that you brought up the idea of a system. I’ve noticed this in your writing in a couple of places where you talk about why expert developers can sometimes make the worst tech leads. You talk about how someone can be extremely talented at a certain kind of system, like programming, but then the system that sits on top of it, where, what are you doing, and how does it fit into the larger scope of things, and the other people that you’re working with? Those talents are not - it’s not that they’re necessarily incompatible, but they’re not the same. I was wondering if you could explain a little bit about that.

K: Yeah, it’s really funny actually, beause I’ve done a lot of reading around systems thinking. The Fifth Discipline is a really great book, as is - I think it’s Thinking in Systems, I forget which one it is. I think what’s really interesting is just trying to - I think we’re taught in a certain way - though the way our education system runs, about being very scientific about things, boiling things down to singular causes and effects.

I think systems thinking teaches you to see things in a different perspective. Depending on where you draw the boundaries of a system, there are different perspectives and therefore different motivators, and different characteristics. For me, I think, when we work in a software environment, you have the local system of either your software system that you’re building, or your team that’s working on that software system. But there’s the broader organizational system in which it’s working, and I think for me, one of the challenges working as consultant is, you’re often brought in to try to shake up a system. You want to create an empowered environment. So you want to carve out a safe space for people to experiment, to gain their autonomy and confidence - and also then, deliver.

There’s a bit of a challenge there, because what’s good for individuals doesn’t always work for the whole system. There’s a trick in synchronizing the rate of change. One interesting thing that I see a lot with teams that really adopt a fully extreme approach to agile development - and the organization is a very big, lumbering behemoth - is that people won’t necessarily change the system, or they won’t fight to get the surrounding system around them changed.

We have this saying which is, “Change the system or change the system.” What that means is that people will get frustrated without any change in their own system. So they’ll choose to move to another company. They change their environment, and that’s another way of them changing the system. Which I think definitely is a consequence for companies that are thinking about moving in a very different cultural way from what their current system is. But at the same time for me, it’s - you’ve helped people connect with purpose and something good for them as well. It’s quite hard, because we’re trying to also appease the people that we work with, as well as our customers who may be quite different - or in different circles.

E: That’s really interesting. I really like the observation about how we often try to take reductive causal frameworks, and then apply them to the complexities of systems, like human systems for example, that they don’t quite apply to.

I’ve got a joke which is, it was an apple that fell on Newton’s head, not a person. If an apple had fallen on his head, then he would have the insight that he did about how these simple formulas can explain the motion of the planets very far away. But if a person had fallen on his head - he would have freaked out, and jumped up and had all sorts of different thoughts - none of which had anything to do with this simple explanation of how things move in the universe. And that, actually since the Enlightenment, there’s been a problem where people have often tried to take the successes of the sciences, and then apply them to areas where the systems are actually different. There was actually a German philosopher, Husserl, who wrote a book about that - over 100 years ago [sic], so it’s a longstanding problem.

But I had a specific question. Your book, “The Retrospective Handbook,” is about retrospectives. This is in particular a way of managing people within these systems, and helping them to improve and maybe find their own place. I was wondering if you could maybe explain to people listening what a retrospective is, and why it’s so important?

K: Absolutely. What’s really interesting is that I think in most businesses, the pace of change is really rapid, and people expect things to happen. I think often there is the assumption that everyone is doing the best that they can, which I also believe. People are given goals, and they’re all working towards that.

But it’s hard to improve in that sort of work environment. And for me, the retrospective is sort of a time out from your normal day-to-day work environment of - all these things going on, all these priorities. All these things that are changing. And creating a bit of space to actually reflect. For me, the power of retrospective is this meeting where you bring people who are working perhaps on the same sort of goal together, where they can talk in a bit of a safe environment, to talk about what things that they could change or improve.

For me, the key outcome of a retrospective is really about the small actions that they might take. To slightly experiment or to improve something. I don’t think you necessarily need to change everything. But for me, the idea of a retrospective is about change, and that safe environment to talk about what’s gone less well in our environment, and what are the things that have gone well - and maybe can we amplify them? It creates that space for a whole team or a group of people to come together, which, a lot of businesses don’t really make time for. And so, they never really take the opportunity to understand what improvements they might have.

E: Is a retrospective something that happens continually throughout - let’s say a project? Or is it something you do at the end? You know there’s this terrible term “post-mortem”. It just sounds like it’s different from that, right?

K: Yeah absolutely, and you’re spot on - a post-mortem is after everything is dead. So you can’t really do anything to change it. The idea for a retrospective is to keep these short, to do them regularly. I encourage groups of people to do them maybe once a week or maybe once a fortnight, and to try to take small steps towards something.

For me, I’m a big believer that small steps can lead to huge change. Therefore, the small experiments that people can take give people an opportunity to review them the following week - and maybe change them back if they didn’t go so well. I think it’s a really easy way to introduce new things, because it’s low risk for people, right? It’s like, if they know that there’s a way back, people are more likely to sort of try something out. So yeah, you’re spot on in that it is a bit more of a regular sort of cadence of how you run retrospectives.

E: You write in your book about the retrospective prime directive. I was particularly interested in how important it was, in your experience, that actually this is read out explicitly at the beginning of a retrospective - or when people are being introduced to the retrospective process. And I’d like to actually read the sentence.

K: Sure.

E: And have you explain why in your experience it is so important that it’s read out. So here it goes.

K: Sure.

E: The retrospective prime directive: “Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.”

K: Yeah, so firstly, I won’t take credit for this, because I’m standing on the shoulder of giants. This actually comes from Norm Kerth’s original book about project retrospectives, which were also considered more at the end of a project, that you might do something. For me, I think this statement is a really good example of that difference between a retrospective and a postmortem.

For me, I think this statement is actually really important, particularly for people who’ve never done a retrospective before. I’ve worked with teams that have been working a couple of years, and they’ve been doing whatever they do. Nobody’s ever really asked them about what could they change? How could they improve things? And that ability to influence their working environment.

For me, this is a really great way of sort of introducing the concept of safety. Of, we aren’t here in a retrospective to point fingers and hang people up to dry. We are here to really believe that everyone was doing the best that they could, and to put our mind on the system that we can influence, rather than pointing fingers and blaming people, because that doesn’t really improve the system.

I think for people who’ve been part of retrospectives for a while, they understand this. But I think, particularly for new organizations, what I would say is - maybe more conservative sort of teams or cultures, where change doesn’t happen a lot, and they’re not used to it - I think it’s a really powerful statement to open a retrospective and create that safety. My rule of thumb is that people should try to use this the first time, if they’ve never run a retrospective with their team before.

E: It’s interesting, you talk about safety and in your book, you also talk about bias. I was wondering if that’s related to the importance that you place on independent facilitators for retrospectives?

K: Yeah absolutely. I have a very strong memory of going to a client where a retrospective was run by a very, I would probably describe, controlling project manager. I think it was my second week with the client, and so I sat in the retrospective - I didn’t have that much to offer, because it was the second week. I just watched how that project manager would take the white board marker, point at somebody and say, “Okay, what went well last week?” Point at another person and say, “What didn’t go so well?” And it was really interesting, because the responses from those people were pretty much one word answers. There was no elaboration about story. There was no context given to those points. For me, it was such a contrast when I’ve seen independent facilitators who don’t have any other agenda - who have no power relationship with the participants. It does really create a good, safe environment that people can talk a lot better in. So I think it’s a really powerful concept to have an independent facilitator. I think it really increases safety.

E: Yeah, it’s really interesting too how when you’re talking about, in Talking With Tech Leads - your second Leanpub book I think? - you write that the experience you gained as a developer does not prepare you for the responsibilities of a role of a tech lead. Even though it’s important that as a tech lead - which you define as someone who is actually still coding usually, right? And participating in the creation of the code for the project, but also now has been moved into a space in where they’re steering the ship, and all the skills that you’re talking about now - not pointing and kind of demanding one word answers. It’s effectively demanding one word answers.

I was wondering if you could explain a little bit about your experience interviewing all the people for Talking With Tech Leads - what insights you might have about people who’ve newly moved into that role, or might be a little bit worried about being pushed into that role, and how they can shift from being a developer to being a tech lead?

K: Absolutely. It was really interesting talking to so many different people, because when I set out to do the book, I didn’t really have an idea what responses I might get. The book was intentionally structured so that I posed the same sorts of questions to people. And what emerged was interesting things that people had different - I guess when they had different perspectives on or different times of their career. As they were maybe, earlier in their phase or later in their phase, about what areas that they focused on. So there were some natural themes that developed.

I think for people who are very new to it, who I call the sort of novices, there is a huge shift from what you do as a developer, to suddenly leading a team. As a developer, you’re normally very focused on how well your code is structured and how nicely everything runs. You don’t really need to worry too much about sort of the people in your team - that’s somebody else’s problems, and you don’t necessarily need to worry about where work comes from and managing business people. And then when you’re suddenly thrust into this role of being a tech lead, you’re trying to also write a little bit of code, but at the same time you’re pulled in lots of different directions.

That’s quite a natural state, and I think my first word of advice for people in that role is to not panic, because it can be really overwhelming. Time management skills are quite useful, trying to prioritize through some of this stuff. I think also the big difference, a big jump is - as a developer, you feel like you have a lot of control over the code that you’ll end up writing. And I think as a lead, it’s difficult to give up that control.

So, back to that project manager who’s really restricting what people say: letting go is really hard. As a developer, you’re really opinionated about how something might be written. And as a lead, you still have to have some guiding principles - you have some sort of say. But you have to be okay that the method or the structure won’t be written exactly how you would’ve done it. In fact, it may actually be better for it, because somebody has a different approach from you for actually solving things. So, there’s a big shift mentally I think, that developers have when they move into this role of suddenly realizing that it’s okay that problems get solved - but in a different way, and that’s okay.

E: I was just fascinated reading the stories from different people about their different experiences. It was really interesting how in the book, you ask people the same set of questions, right? But they came back with these unsolicited themes that grouped together.

K: Yeah, that was very fascinating.

E: I was wondering actually, on the subject of publishing - you actually turned Talking With Tech Leads into a print book.

K: Yeah.

E: And it’s for sale in 3 different regions on Amazon.

K: Yes.

E: I was wondering if you could explain a little bit about that experience, of turning it into a print book from an ebook.

K: Absolutely. I’ve been a fairly early adopter of Leanpub. I think it was actually with The Retrospective Handbook, that I was trying to turn into a printed book as well. I was asking after a print-ready, PDF version. I used the CreateSpace publishing platform, which is sort of a part of Amazon. And then, they self-publish on demand a printed book.

But they require a whole bunch of preparation, like a PDF version that is printable. And it’s quite an interesting process about moving from an ebook format to a PDF that is print ready. Because there’s lots of little formatting differences that make a big difference when you’re in a print version. A simple example is the alternating page numbers from left to right. You want them to be on the outside of the book, which, when you’re on a single screen, it doesn’t really matter. The same thing with margins is that, when it’s printed, you want the margins that are going to be bound together a little bit deeper, because you want it to look equal - so when somebody opens the book, it looks nice.

Leanpub has been really awesome at actually picking up feedback. I was generating lots of feature requests for understanding what a print-ready PDF could look like. And then I would do a test run with Amazon and give feedback, saying, “Okay, well the test copy, now that I see it in real life, needs some adjustment.” I’ve been a huge fan of Leanpub from the very beginning, because it was a really great example of lean flow in action. Which was - I was creating a demand, and your platform was responding to that as I was getting feedback from it. I wasn’t quite sure what I really wanted either. It was really useful to have those really fast feedback cycles.

E: Yeah I remember seeing all the interaction between you and Scott, one of Leanub’s co-founders. During that process, you really - one of the reasons I’m asking you is because you’ve really pulled a lot of that out of us, and we were so glad when someone arrived on the scene and was like, “I want to have good output to make a good print book.” Are you happy with where it is right now? The print output and everything kind of works more or less the way you need it to, to get it on Amazon and things like that?

K: Yeah absolutely. I mean, what was really interesting was that - I guess a comparison between the first draft of The Retrospective Handbook, and then preparing for the Talking With Tech Leads print version. I don’t think there was any feature request that I had to change at all. In fact, I think for me, the difficult part was actually the wraparound cover - which is something that you don’t necessarily need to worry about in an ebook world. It is something that is exclusively to do with print layout. You need to think about what goes on the back, what goes on the spine, and try to get the formatting right based on the thickness of the book - it’s kind of one of those tricky - you have to print it, really, to see what the end result is. But from a platform perspective, it was exactly what I needed - and I didn’t have to do any extra changes to it.

E: Oh that’s great to hear, I’m really glad. I’m really glad that it’s at that stage. I was wondering, I read that you used a copy editor, and it might have been the same person for both of your books. Can you say a little bit about what that experience was like, and how you found a copy editor?

K: Yeah absolutely. I found a copy editor through a colleague of mine actually. I think for one of the very early drafts of The Retrospective Handbook, I’d asked some people to give me some feedback on it. I think one of the early bits of feedback is that, “You’re really too close to your writing.” I think this is probably one of the dangers of self-publishing: you decide to go down the, “I can take care of everything” route. “I can do all the grammar and checking.” But actually that’s not my strength, and that’s - I would actually say that’s probably one of my weaknesses, is that, I tend to speed read, so I tend to skip over things that other people would notice.

I think there’s a lot of value in working with an editor. So I worked with Angela from Virtual Editor, Angela Potts. She was really - she’s based in Cambridge. I guess one of the really great things is that, we still physically haven’t actually met. We actually met over email, and then we did some Skype sessions - and so she works very virtually as well. I think the Leanpub process was actually really useful, because I could just share simple text files with her. With enough simple syntax, she understood how to sort of start editing some of those files and we could actually just simply trigger draft copies really rapidly. That was a really useful process, of actually sharing the book and getting fast iterations over the copy.

E: So did you actually share, like give her access to the Dropbox folder that you would have been working in and direct access to the files?

K: Yeah absolutely.

E: Okay.

K: Yeah, and that worked really well. For the first book, it was just a bit more copy editing. I already had the structure in place. And then our relationship evolved a little bit more, and she helped me with a little bit more of the structure for the second book - how to make it a bit more interesting, rather than just a whole series of interviews.

E: I noticed that both of your books have really good covers, and I was wondering if you made them yourself, or did you use an external service to do that? That’s one of the questions we get all the time from people, because a great cover really does make a big difference, particularly in confidence that people have in a book, especially if it’s self-published, or maybe even in-progress.

K: Yeah, it’s a great question. I designed them myself. I wasn’t sure about this actually to begin with. I was also thinking about going out to, I guess the market - what some other authors have done about trying to get somebody to pitch different ideas towards a cover. But for me, it was actually kind of like a fun, creative experiment. My goal was to create something that was a little bit eye-inducing. It could be a lot better, but it’s also the skills that I had.

I ended up studying actually, probably about - there’s a couple of websites that show really great book cover design. I looked around at I think a site that showed like 50 or 100 of them, and then I was looking at some of those things, thinking about what sort of themes and colors and - I guess - patterns that I might take, that I could reproduce in open source tools. So I used GIMP for the actual file creation.

E: Okay.

K: And then I just ended up coming up with a couple of different designs. I also did the whole sort of lean testing as well. I actually generated quite a lot of different variants, and then I tested it against some of my colleagues and close friends to see, “Do you like A or B better? What do you think about this color? How’s these patterns?” I ended up settling on the style that you see on The Retrospective Handbook.

Then I wanted to continue that theme with the second book. That was a little bit more interesting, because I was actually - it was really important for me in Talking With Tech Leads, to get a diverse sample of people in there. So what might be surprising, which I haven’t really written a lot about, is that, I’ve managed to probably get about a third of the people in the book - I think - to be female tech leads. It’s really hard to get female developers, let alone people in leadership roles. And so, when I designed the cover, I also was very conscious about making sure it wasn’t a male or a female looking tech lead. I’ve tried a sort of gender-neutral-looking icon, which is what my design intentions were. I don’t know if it’s come through, but yeah - I guess that was the sort of - So, have some sort of theme that comes along from the first book, but have something that’s representative about that sort of topic, yeah.

E: That’s really interesting. I mean, obviously you’re very hands on with the scope of the entire project now. I was wondering if you’d ever - for both books, I was wondering if you’d ever considered going with a conventional publishing process or conventional publisher to begin with? Or was that just something that never occurred to you, and publishing it yourself just seemed like the way to go?

K: I think for the first book, I had thought about going to a publisher. But I was just really surprised at how rapidly it had gone through. I mean there’s - I know a lot of people who’ve written books for the Prags and O’Reilly and things like that, and I think there’s trade-offs. I wanted to go down the whole self-publishing route to see how easy or hard it was going to be. And I’ve been really happy with the reach of the platform and the ease with which Leanpub makes it easy for people to buy and distribute the books all over the world.

I mean, I might go through that process, but for me I think the editor is probably the biggest value that one of those traditional platforms can bring - and that they have a strong network. And probably around the consistent theme. So if it fits in with an existing series like the Martin Fowler signature series, or something like that, that probably makes sense. But I’ve been very happy with the whole self-publishing route.

I guess the only thing that I’m thinking about, is how better to market the book. But I think that’s part of the self-publishing process, right? Which is, what can you do to get the book out there?

E: Yeah definitely, definitely. And that’s kind of the - writing’s the hard part, but so’s the marketing.

K: Absolutely.

E: I was wondering actually, I guess my last question would be - if there was one dream feature that you could have us build for you, what would it be? If there was one thing that was either missing or that you now - looking back, or even looking forward - which we could give to you as part of our process, what might that be?

K: It’s a really great question. And to be honest, I don’t have a good answer. I mean, one of the things I really like about you guys is that - if I want something, I feel that I can post something on the forums and get a response, and have somebody either say, “It’s on the road map,” or, “We’ll work on it.” I think that’s such an amazing opportunity of the platform. And so, I can’t really think of another feature that I’d really like - otherwise I would have asked for it by now.

E: Well thanks - if you ever do, please come back and ask again. A big part of our process is having people approach us and tell us what they need, and then us delivering it. I mean after - obviously with deliberation!

So anyway, Patrick, thank you very much for your time and for being on the Lean Publishing Podcast, and for being a Leanpub author.

K: Thank you for having me.

This interview has been edited for conciseness and clarity.

– Posted by Len Epp

blog comments powered by Disqus