In Leanpub's Frontmatter podcast, we interview authors and special guests about their lives & careers, their areas of expertise and the issues of the moment, and their experiences as writers. Every episode is deeply researched and covers areas that are equally of human interest, general interest, and professional interest.
- Episode 95
Ben Linders, Author of What Drives Quality
Watch on YouTube Listen on SpotifyIn this Episode
Ben Linders is the author of the Leanpub book What Drives Quality: A Deep Dive into Software Quality with Practical Solutions for Delivering High-Quality Products -- Second Edition. In this interview, Leanpub co-founder Len Epp talks with Ben about his background, Agile and building quality software, what it's like to write a book with someone you've never met in person, his books, and at the end, they talk a little bit about his experience as a self-published author.
This interview was recorded on February 26, 2018.
The full audio for the interview is here. You can subscribe to the Frontmatter podcast in iTunes or add the podcast URL directly.
This interview has been edited for conciseness and clarity.
Transcript
Len: Hi, I'm Len Epp from Leanpub, and in this Leanpub Frontmatter Podcast, I'll be interviewing Ben Linders.
Based in the city of Tilburg in the Netherlands, Ben is an independent consultant with experience in Agile, lean and continuous improvement practices. He's also a popular writer and speaker, and an editor for Culture and Methods at InfoQ.
You can read more about Ben on his website at benlinders.com, you can follow him on Twitter @BenLinders, and if in need of advice, consulting or training, you can contact him at info@benlinders.com.
Ben is the author and co-author of a number of Leanpub books, including What Drives Quality: A Deep Dive into Software Quality with Practical Solutions for Delivering High-Quality Products -- Second Edition, Getting Value out of Agile Retrospectives: A Toolbox of Retrospective Exercises, and most recently, The Agile Self-assessment Game, which sets out a game Ben created, that is now played by teams all over the world, to help them think about how they collaborate with others, and how they can proceed down an Agile path.
In this interview, we're going to talk about Ben's background and career, professional interests, his books, and at the end, we'll talk a little bit about his experience as a self-published book author.
So, thank you Ben for being on the Frontmatter Podcast.
Ben: Thank you very much for inviting me.
Len: I always like to start these interviews by asking people for their origin story. I was wondering if you could talk a little bit about where you grew up, and how you first became interested in computers and software?
Ben: Well that's a way back actually. I first became interested in computers when I was studying in high school, and I actually created my own computer. At that time, I didn't have much money, so I bought all the components. And I created my own Apple 2 derivate. Having a first computer, and just having a way to play around with it. And playing some games and doing some other stuff that I found it very interesting.
And actually also started to look at the BIOS which was in there. And what other computers were built off and how the software was functioning. I think that was my first time where I got interested into computer technology. Not that much into software, but much more in how computers were working and what they could do, and the stuff you can do with them.
Len: Did your parents help you out in this? Who got you into this? How did you find out about how to build an Apple 2 computer?
Ben: I got connected with some of the networks who were actually doing these computers. There was a group of people in Eindhoven who were also connected to Philips. And who had developed their own board, and had some instruction how to do that. So that stage where I got started, not that much my parents - they looked a bit like, "Okay, what is computers and why the hell are you doing this?" They weren't really that familiar with that kind of stuff. But well, they saw I was happy doing that, and that was okay for them. It was more - being in the area, I think - and seeing this kind of stuff developing around. I was also studying in Eindhoven so it was connect to that city. And then seeing this happening make me start doing this.
Len: And did you study computer science in university?
Ben: I studied electronics, and I graduated on computer technology in the electronic area. Which was mostly hardware related. There was some part in there on software but most of the stuff was hardware at the time.
Len: One of the questions I like to ask people who are in tech on this podcast is, if you were starting out again now, and you could give yourself advice, if you were looking for a career in software, would you advise yourself to go to university and do a formal degree? Or would you advise yourself to do something else?
Ben: No I think, I learned a lot at university. I learnt a way of thinking. You learn a way of approaching problems and looking for solutions to solve those problems. And I learned some stuff already at university initially, when I was doing my - my electronic study. But I also did some social studies later on. So I studied psychology, sociology to look at the soft side of software development. That was also when I was doing software development already and got interested into that. I think it's also good to do multiple studies. Not just focus on one big study, but try to combine it with another study that gives you a different way of thinking and looking at problems.
Len: From what I gather online looking at your LinkedIn profile, I figured out that you spent a great deal of your early career working for giant corporations, like Philips and Ericson, but like many people who show up on Leanpub writing books, you eventually made the decision to switch to independent consulting. I wanted to ask you what led you to make that leap?
Ben: I think the main reason to do this was that I wanted to have a little bit more challenging work at the time. At that time I was working for Ericson. And basically every year there was new stuff coming up, new ideas I could try out in the company. Agile was actually one of them. But I was doing a lot of stuff on Agile already before Agile really became popular. I started to do Agile Retrospective in 2001 after seeing Norm Kerth . at the conference talking about this. I was doing a lot of the stuff already earlier.
And every year working with Ericson, I more or less set myself some targets to explore, some new areas, and trials and stuff. And I was getting to a point where there wasn't really anything new ongoing anymore in Ericson that would give me that opportunity. So I started thinking about, "Okay what I'm going to do right now?" And I had a lot of freedom already within Ericson, working with multiple projects - and also working in the operational development department.
So I was used to basically working on my own, making agreements with the projects that I was working with. Making agreements with the managers I was working with. And that was something that felt good. So my decision was - I either wanted to go for another big company, and do a kind of similar job but then in a different technology area to further develop myself, or to become an independent consultant. And basically the question was - whatever would come up first, that will be the one to do.
As an other company didn't come up - except for a bigger assignment for a year at the police department, which was also very interesting. But not finding that other company, not finding those other jobs - I decided that I'm going to be an independent. Because I wanted to have interesting challenging work to do.
Len: I also saw from your profile that you've worked extensively with government, as well as with these giant companies in the private sector. I wanted to ask you, with respect to software development, how are the two different - the private sector and the government? I know this is going to be from your perspective, and your particular experience, but what would you say the difference is?
Ben: I think one of the major differences that I've seen - certainly the companies that I worked with - was the risk adverseness of the government, not taking on too many new things. And less resistant to change. So they didn't want to change too much. There were things that really made them feel uncomfortable in there.
And the other major difference I saw was that - actually at the governmental agencies that I worked at - a lot of people working there were coming from consultancy companies. And also for them, they wanted to maintain the status quo. They wanted to maintain the situation that they were in - do the work that they were doing for those governmental bodies.
And I think it's a kind of catch 22. It was more safe for them to not to change too much, and to stick to the contracts that they had and keep on doing the work and not become too innovative. While at the other end, they wanted to try some new stuff. And I think that also felt safe for the governmental bodies.
And I think that there was a lot of innovation that could have gone on in those organizations. Basically being resistant to change, and being resistant to changing the system in there. And having benefits from sticking to the system.
Len: And was there anything you could do, working for them, to prod them along? Or was it just a hopeless scenario?
Ben: Well I that there was some stuff that I could do, and some stuff that I actually did. I found out very quickly by jumping in with the change of process I was doing at the governmental body that I was working with that I needed a different approach.
They initially asked me for a project proposal. And writing that, I actually found out that - it didn't really make much sense to call it a project proposal. Because basically I didn't have any budget to do anything. I didn't have any people on my project. I was only me trying to influence a situation at that company. Working together with a couple of departments where I was involved with. So then I decided to take a different approach in there.
And instead of making an extensive project proposal, I just made a kind of backlog of things that I thought that made sense for them to start working on. And I used a kind of combined approach, where I said, "Okay, we're going to be working on these changes. And I don't want to do too many of them at the same time. So we're just going to take 2 or 3, maximum 4 changes at the time that we're going to be doing in this organization - focusing upon that.
The biggest benefit I actually saw was because I wasn't the project, and I wasn't attached to any of the major improvement programs that they were running in the organization I was able to continue the stuff that I was doing, because all of those programs, they were either stopped after 3 or 4 months when they had to change their strategy, and they had to go back to their desk, write a new project proposal, and get an agreement on that to start working on it.
Where I said, "Well look, hey I'm not attached to one of those programs, and I'm just doing stuff in the organization right now." Which I think made sense. And I got people involved in there. So I managed to continue some of the changes I was doing in there. Going actually up to the CEO level in the organization and looking at what quality really meant in that organization.
Len: One thing that I found you've written about is using positive psychology approaches. You've mentioned your education in areas outside electronics and hardware and computers, and I was wondering if you could talk a little bit about what positive psychology approaches are and where they come from?
Ben: I have to say, I'm not sure where it exactly come from. I got actually triggered on positive approaches by one of the managers I was working with at Ericson. They would do regular meetings with the employees to focus on developing their skills and then finding out the things that they can do and that you can do, to do your work better. And one of the managers actually called me in one day and said, "I don't want to hear any more stories about things that are going wrong. I want to hear stories about things that are going right. And I want to hear stories about stuff that is going well right now. Because I'd like people in my group to focus on improving their strong points, improving the strengths that they have in their organization. And then use those skills to solve the problems at hand."
That was a different approach that he's been reading about. And initially it felt kind of awkward to me, coming from a background of always being focused on issues and on problems and trying to solve those. It felt a bit strange to me like, "Okay, I'm going to ignore stuff that is going wrong and I'm only going to focus on stuff that's going right."
But there was one reason that really made sense to me where he said, "If you focus on improving things that are going wrong, you're going to be medium level at most. You're not going to get to the highest level in your organization. You're not going to get to your highest level of performance. But if you start focusing on your strengths - on the stuff that you are good at already, and you start improving that - that's where you really have the ability to go to really high performance in your organization."
"And I'd like people in my department to really be high performers in the things that they are doing in there. And then, okay, there will be stops. There will be things which will go wrong; there will be problems. But most of the time there will be other people who can deal with those kind of situations, who are better in the stuff that you're not good at. So if you start dividing the work up differently, work together as a team, and have everybody focus on the space and work together - there will always be somebody who can do the stuff that you're not good at. And then you can help each other to get to a higher level."
So that's basically where this started. I started doing some reading on that. I found out about some of the techniques like appreciative inquiry, where you would use interviews to really find the strong stuff and use that in a positive deviance. Like, "Okay, let's look for people who really stand out in the area and try to find out what's making the difference in there." And using that kind of stuff to improve organizations, I'm still focusing a lot of that.
Len: Oh, and so that's what positive deviance is - that's someone who stands out?
Ben: Basically it's somebody who stands out in the area. And then you're going to dive into to find out, "Okay, what is it that really makes a difference? What is it that makes these people stand out?" And is something in there that we can also use and that we can further develop in your organization that other people can pick up? What is the thing that's making the difference in there? That's the kind of stuff you're looking at.
So you could compare it to a kind of root cause analysis. But then not on a problem, but on the strength which are there. Diving deeper until you really know the root cause of why somebody is being a better performer in some area.
Len: One thing I wanted to ask you about - and I know this goes - this has a long history. But is CMM or the Capability Maturity Model. And I was wondering if you could talk a little bit about what that is and how its come up in your work with organizations?
Ben: Basically it came up, again in the large organizations I was working with. I think initially it came up when I was working at Philips, where they were looking at ways to improve their way of working. Which basically meant for them improving their processes.
And the CMM at that time, and the work for Watts Humphrey was really focusing on, "What is your way of work? What is process? And what can you do in there to reflect on that process and to find ways to improve?" That was something that really appealed to me. And I actually met Watts Humphreys later on and I had a talk with him and really understanding how this stuff is working, really confirmed that he was on the right track with that.
So the CMM at that time was actually 2 things. Initially it was a kind of maturity model that organizations are using to be assessed and to see how well they were performing in those areas, and then looking for ways to improve. And later on it became more and more focused on a kind of capabilities model, and that was actually what the CMMI, the successor of the CMM was promoting. Being focused on what are - again, the capabilities that you have in your organization, the capabilities that people have, and using those capabilities to do a better job.
Len: You wrote in a presentation on CMM that Agile assumes a mature workforce. I was wondering if you could talk a little bit about what that means? What is a mature workforce and why is that assumed in an Agile process?
Ben: Yeah, well actually this is still one of the things that surprises me. When I initially saw the stuff about Agile, I found it a very disciplined approach to software development work. And if the team would really want to work in an Agile way, they would need quite, some skills. Both being the technical skills to do the work and also the communication skills, the soft skills to work together as a team to communicate. And the skills to make their work transparent, to see how they were doing. The skills to reflect and to learn from the stuff that they were doing.
So if you would like to work in an Agile way, for me that meant that you would need quite some mature organization to be able to do this. And I think one of the statements that I initially made with people when we were discussing Agile was that I only expected about 10% or maybe 20% of the organizations would be capable of really working in an Agile way, and really using this kind of approach. Because it takes quite some discipline to do this, to really make this work. It takes a culture where people can be open and honest to each other. And that's not something that's a given in most of the organizations right now. Certainly not if you're in lower majority organizations.
So that was my initial expectation - and I think I made this statement in 2001, 2002 when Agile was actually just starting off and having the Agile Manifesto published. And looking back, I think this is still the case. I think if you look at the majority of the organizations that are trying Agile right now, they are not getting the benefits that you really want to get out of Agile. They don't have the right culture in their organization to really benefit from using Agile practices in there. And you would actually question whether they'd actually really should go this way.
Len: And what is it that they're missing? Is it giving workers kind of independence? Is it giving them that maturity?
Ben: It is giving them that maturity, but usually a lot of this independence has to do with your organizational structure, with the system, with things like the rewarding system which is there in the organization. What are the expectations from the managers in your organization?
So it's that kind of stuff. It's the whole culture surrounding the teams that is not giving them the possibility to really be self-organized. And to really self-organize their work, to reflect on the work, to take the decisions. Usually there's also a lack of information. In a lot of organizations, information is still something that is considered to be power. And if teams don't get the right information - if they don't know what your organization's heading for, then they can't take the right decisions. So that's also something that is strongly related again to the culture and the way that your organization is set up.
Len: You mentioned your experience going back to the beginning of Agile. You were talking about 2001, and I wanted to ask you, I know it's an overly broad question perhaps, but how have things changed? For example, when you engage with a company, are people more familiar with - I mean, certainly I assume they're more familiar with Agile than they would have been when it was new. But have things changed? Is it easier to get into the executive level to initiate changes along Agile or continuous improvement lines?
Ben: Yeah, I think it has changed. A lot of the executives now are getting familiar with Agile. Though, often getting familiar with Agile means that they've seen things like Scrum and they think that Scrum is the only way that Agile can be done in an organization. But there's more knowledge about Agile. I think also the term "Agile" and the idea why the system was created as being something about agility, making your organization more Agile. I think it is something that appeals to more organizations.
Getting to a level of business agility, this is still a challenge within a lot of organizations. They look at Agile as something, as the way that their IT department should be working. But it's not something that they really see in business agility. And that's actually where I think some of the big benefits are if you look at Agile. It's not about the IT. It's about IT, product development, business development working together to get real benefits.
Len: In the description of your book What Drives Quality, you mention that the book - quote - "Views software quality from an engineering, management, and social perspective." End quote. And I wanted to ask you about that last part. What does it mean to view software quality from a social perspective?
Len: In the description of your book What Drives Quality, you mention that the book "views software quality from an engineering, management, and social perspective." I wanted to ask you about that last part. What does it mean to view software equality from a social perspective?
Ben: I think from a social perspective, you're again looking at teamwork. You're looking at creating a product together and involving the right people in your organization, if you're looking at quality. Quality is not just the technical part of your software. Quality is also how your users are perceiving your product, what's important for them?
And again, this takes social skills to really understand your customers, to really understand your clients, and to understand what they do with the system, how they use it, and what their expectations are. And there can be situations actually that you can go low on tech.
I recall one situation, we were discussing a new feature. And we found out that we didn't know how to do this. It was something that was really new, was very complicated. And we didn't know how to do this. And we knew that we had a big chance that the first versions of the feature wouldn't be working properly.
And then actually our product manager said, "Don't worry about that, because I've got a couple of customers who are going to try out this stuff. And they're gonna give you feedback very quickly, so it's much more important right now that you're able to respond to this feedback. And if any problems pop up, to solve them instead of trying to make the right product the first time, because you're not going to be able to do it anyway." So the quality was much more in responding to the feedback and being able to solve problems, than it was in trying make the right product from the start. Because that wasn't a feasible goal anyway, we shouldn't strive for that.
Len: One of your other books you co-authored with Luis Gonçalves. The book is called Getting Value out of Agile Retrospectives. I found a video on YouTube where you and Luis talk about your experience with remote collaboration on the book at length, so I'll put a link to that in the transcription to this interview. But I wanted to ask you briefly here, could you talk a little bit about the approach you and Luis developed to remotely co-authoring a book?
Ben: Well there's a process we developed where we initially had a couple of Skype calls to see, "Okay, what's the kind of stuff that we would like to have in the book?" And we started from the idea which was actually stated in the discussion on one of Luis's blogs, that we wanted to have a book with retrospective exercises. There were a couple of books out there on retrospectives, there's the Agile Retrospectives book from Ester Derby and Diana Larsen which gives a solid foundation for how to do retrospectives. All the stuff is in there. Actually there are also a lot of exercises in there. To my surprise, I didn't even know that. Because there's so much good stuff upfront in the book, that you usually don't get to the exercises. All the stuff which is there before the exercise is so valid already that people are really working on that and using that in their retrospectives, before they really get to the exercises.
We wanted to create an exercise book. And having said that, we started collecting materials from our blogs. And we quickly decided on using LeanPub as a platform to do this. Because it was easy for us just to put in our blog posts into LeanPub. And then formatting them into chapters. And then see - okay, what's the kind of stuff that we have right now in the book, what's missing in there?
We found out we missed a couple of topics. And actually we took the same approach that I've also seen Jurgen Appelo doing. If you want to have some stuff in your book, start blogging about it. And then reuse your blog into the book, to turn it into a chapter. So the parts that were missing, we were writing a blog post on that. Posted it in our website. Got some feedback, go to refine that one. And then incorporate into the book.
Then again, we also found out that having a couple of blog posts together and putting them into the right order and doing some editing - doesn't make it a book. We've done some major rework on the blog post to really get it into the book format. To really get it into similar format everywhere. It's a different writing style when you're blogging or you're writing books. We did quite a work on that, to get it into the format, to get it into the right style we wanted to have into the book.
But using LeanPub as a writing platform, using occasionally a Skype call if you want to check something, and for the rest it was mostly emails just checking on what we were working on. And then coordinating our work, that was a way of working together. By the way, we did it full remote, and we never met in person when we were writing the book.
Len: That's really interesting.
Ben: Yeah, we never got a chance to meet each other. And then the book got published. And then I think it was three months later that Luis was in Amsterdam for a workshop over there. And then he called me a couple of days before and like, "Okay I'm going to be in Amsterdam." "Okay, so let's meet for dinner." So that was the first time that we actually met in person. The book was out already for three months.
Len: That's a great story, and congratulations on the success of that book. I have a question or two about that, that I'll be asking in a few minutes.
But first I wanted to ask you about your latest book that you wrote yourself, The Agile Self-assessment Game. I was wondering if you could talk a little bit about what that game is. I know it can be played a number of different ways. What is Agile self-assessment, and how would teams use your book to undertake a self-assessment?
Ben: Well, The Agile Self-Assessment Game, I called it a game, which is more tied to the playing format than it is to really being a game itself. It is a set of cards. Which you can use either as coaching cards, self-assessment cards - all in different playing formats. To get people to discuss on how you're doing right now as an Agile team. Or even if you look at an organization level or department level. How well are they performing right now?
And the idea for my Agile self-assessment, actually goes back to the way that I used the CMMI model to do assessments. Where initially, the CMM was meant as a model where assessors would come into an organization and see how well they were doing. With the CMMI they started introducing different assessment formats. They also wanted to provide organizations with the means to do a kind of self-assessment before they went into a formal assessment.
And I sort of explored this and used this, really together with teams and with projects, as a means to help them to really self-assess their performance. And instead of being an assessor, I was much more being there as a coach helping them on this assessment process. Helping them to self-reflect.
The main reason for that, is that I believe that if you help people - if you coach them to self-reflect, and they see how well they are doing - but they also see where the areas are where they want to improve. You're going to get much more energy out of the team to work on the things that they will find out for themselves. Instead of an external assessor or auditor coming in, and telling them, "Okay that's the stuff you're doing wrong, and that's the things you need to work on." You want people to find out for themselves. To see, "Okay well, what's the thing that we would need to improve?"
So the kind of self-assessments already started with using the CMMI and using it as a capability model, to help them to improve. And then with Agile, that was a new terminology coming in that was much more focused on team being self-organizing. This fits very well with the idea of doing the self-assessments in there.
And it was also the terminology of the new methods that became popular. Scrum being one of them. Kanban being another one. And DevOps being another one. That's why I developed specific cards for those practices. Using the terminology and using the frameworks as a reference, but still focused on making something the team can use themselves to improve.
Len: I mentioned that Getting Value out Of Agile Retrospectives was a pretty big hit. I believe it's been translated into about 13 languages. I wanted to ask you, for the benefit of any self-published authors listening, how did you and Luis pull it off? How did you get that book to be such a hit?
Ben: Yeah well, I think it's the practical format of the book that made it a hit. It's the exercises which are in there which people wanted to do in their retrospectives. And there's a lot of exercises available on the internet. There's several websites where exercises are published - this is not something new.
But the way that we collected them in the book, made it into something that was very, handy for Agile coaches and Scrum Masters to take along and to pull out exercises and to use them. So I think it's partly the packaging, the reformatting. It's also a couple of new exercises that we brought in there that made it easier for people to pick up stuff using this book that we wrote in there.
And then I got requests from people who said, "Okay, we've read the book and we played around with the exercises. But we would like to have them available in our local language for the teams over here in our countries." So can we translate the book? And actually all of these translations have been done by volunteer teams. Even the Dutch translation - I didn't translate the Dutch version. Although I'm Dutch, I was only one of the reviewers.
That was something I could do with a Dutch version, not for the Japanese one. But for the Dutch version, I could review it. But just as any other language, it was people coming up and said, "Okay we're interested in your book. We want to learn more about the topic." And one of the ways to learn about this topic, is to translate the book. Translate the chapters, and use those exercises in there. What I mostly did with the teams that I worked with. I said, "If you want to translate the book, I'm there to help you, I'm there to explain the exercise. But I'm also there to, to give you some kind of coaching. So if you want to try out these exercises with your team. If you want to find out how this stuff is really working, let me know. Let me know the questions that you have. Let me know the issue that you are facing, and I will help you to apply this stuff in your organization." It was a kind of two way learning for them.
Also for a lot of people, it was really fun to do this. They found it fun to translate the book, to work together on the chapters, and to learn more about this stuff. And actually one of the teams that did the translation of our Czech book, they're still together as a team - being based in different cities. And they picked up the Scrum guide to translate it. They picked up some other stuff. They also translated my Agile Self-assessment game.
They found out that the game was there, and they said, "Hey, we're still together as a translation team. Can we also translate your game?" So they're having fun on being together as a kind of translation team, picking up stuff which is there. Learning about the new things, and then translating it into their checked language, and making it available for the people.
Len: You've also made some print versions of your books that are available for sale on Amazon. For the benefit of any self-published authors listening, I was wondering if you could talk a little bit about what your process was for making print versions of your book available. What was that like?
Ben: Well it was a bit of a challenge. Again, your first assumption is - when you have the book in eBook format, and seeing all the self-publishing platforms - your assumption is that it shouldn't be so difficult to get it out as a printed version. But there are still some minor difference in there. One of them being - if you have a printed version, you also have a back cover so you need to do some work on that.
Also the different tools which are there. I used CreateSpace for the first book, to publish it. I used KDP for the second one, to find out that KDP doesn't support auto copies. I actually knew that from the start, but I still wanted to have a copy of the book for myself. So I found a little trick around that, but turned out to also be a challenge to do it that way. Getting stuff on the platform, getting it right - it usually takes you a couple of iterations before you get it out.
What I also found out is - the difference in - if people want to have an eBook version of your book, or if they want to have a printed edition. The printed edition of the Dutch version is very popular. Actually there are much more copies out there of the printed edition than from the eBook. Where for the English version - and most of the other languages, it's the other way round - most of the copies are eBooks. So for some reason, people in Netherlands prefer to have a paper copy book, instead of an eBook. Where on most of the platforms where I sell the book, both of them are available.
If you go on Amazon, if you go to bol.com or Managementboek.nl, as I mentioned - they sell both versions. And if you go to the book, you can see both versions next to each other. And then most of the people still prefer to have a paper copy of that. So I'm thinking for next paper copy edition, to also publish the Spanish book. Having the assumption that there is probably a market out there in the world, a lot of people speaking Spanish as a native language, and would be interested to have the paper copy version of that book. But that's the next one, which is lined up to go out as a paper copy.
And I'm also planning to do a paper copy for, for my second book, What Drives Quality.
Len: Thanks very much for the details. It's always nice to hear from people in the trenches - dealing with KDP, Kindle Direct Publishing and things like that. It seems like everybody's got their own little tricks they need to figure out when they're going through that process. And it does seem, at least in my sort of experience, to be a little bit random about where print takes precedence over ebook versions and things like that.
My last question that I always like to ask is - if there was one thing we could build for you on Leanpub, or if there was one problem we could fix for you - and you could snap your fingers and have us do it, what would you ask us to do?
Ben: Well that's good question. Because I'm actually very happy with LeanPub. I think the major issue that I had with LeanPub was when we were working together with the translation teams. Having multiple people working on the book, more than 2 - with 2 or 3 people it's still quite easy to synchronize. But if you have - like we had 5, 6 people on most of the books that were being translated. We were also dispersed around the world. We had quite some problems where people would change the book settings between writing in Dropbox, or writing on the LeanPub platform.
Len: Ah.
Ben: That gives you synchronizing problems in there.
Len: Yeah.
Ben: And what I basically did with the writing teams, is just to give them full access. So I actually made everybody in the translation team into an author, giving them full access to do everything on LeanPub. And you might want to have a way to limit that. Like giving them access to most of the stuff in there, but some of the settings - like the ones which are really crucial - like the writing mode. if you're gonna be writing in the dropbox or if you are going to be writing on the LeanPub platform? To limit that one to only have some kind of super author who's able to change that one. Just prevent people from going to do the wrong direction in there. I think that's one of things that I could think of. The one of the things that was a little bit challenging.
Len: Thanks very much for that feedback. Actually I was having a discussion just a couple of days ago with a colleague about permissions. And in a way I'm kind of surprised that it hasn't come up more. But when you make someone a co-author on a Leanpub book, as you're saying, they can change the writing mode from Dropbox to GitHub in the browser.
And it is a little bit surprising that people don't get up to more, more hijinks than they do. Because there are some things around royalties and stuff like that, where it's a little bit more constrained, and you have to contact us and things like that. But people really do have a great deal of freedom once they're in. Thanks very much for mentioning that - particularly around the area of translations, where it might be more appropriate to have kind of limited permissions for people with different types of status when they're working on a book.
Ben: Yeah. But I think only where it really makes sense to limit it, like the writing mode, because it gets quite tricky and people lose synchronization when you change that kind of stuff. Most of the other stuff, I prefer to have it as it is, give people maximum access in there, and just trust the team.
Len: Thanks very much for that. The best feedback is the most specific feedback, and that was very specific - and really good.
Well, thank you Ben for taking the time out of your evening over in the Netherlands to talk to me, and to be on the podcast. And thank you very much for being a Leanpub author.
Ben: Thank you very much.
Len: Thanks.