A Leanpub Podcast Interview with Marcus Blankenship, Author of Habits That Ruin Your Technical Team: Pitfalls and Solutions for Technical Managers

Marcus Blankenship is the author of the Leanpub book Habits that Ruin your Technical Team: Pitfalls and Solutions for Technical Managers. In this interview, Leanpub co-founder Len Epp talks with Marcus about his career, some stories about bad job experiences with bad managers, some pitfalls to avoid when you’re leading a technical team, his book, and about his experience self-publishing as an author on Leanpub.

This interview was recorded on February 21, 2017.

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.

This interview has been edited for conciseness and clarity.

Len: Hi, I’m Len Epp from Leanpub, and in this Leanpub podcast, I’ll be interviewing Marcus Blankenship. In addition to being a leadership coach and speaker, Marcus is an author on the subject of technical leadership, whose goal is to help train great tech leaders. Based in Eastern Oregon, Marcus teaches people how to build high performing tech teams. You can sign up for his newsletter at marcusblankenship.com, and you can follow him on Twitter @justzeros.

Marcus is the author of the Leanpub book, Habits that Ruin your Technical Team: Pitfalls and Solutions for Technical Managers. [At the time of this interview, the title was 7 Habits That Ruin Your Technical Team, which is how the book is referred to in the audio recording — eds.] His book is focused on helping managers and technical leads from falling into traps that can harm their teams in various ways, including damage done to morale, productivity and trust.

In this interview we’re going to talk about Marcus’s professional interest, his book, and at the end, we’ll talk about his experience using Leanpub just a little bit. So thank you for being on the Leanpub Podcast, Marcus.

Marcus: Thank you for having me.

Len: I always start these interviews by asking people for their origin story. I was wondering if you could tell us a little bit about how you first became interested in programming, and then your progress through being a tech lead, to being a coaching consultant and speaker, like you are now?

Marcus: Well I’m afraid this may date me a little bit. But it was 1982, and my parents decided that our house needed a computer. And so we went to Kmart — back then, that’s where you went to go buy your computers, or Sears; both carried a fine set of computer models, known as the Commodore VIC 20, and the Commodore 64.

Of course, we were poor. So this was a big expense for us. And we could not afford any fancy stuff like a tape drive to hold programs. This meant that I was sitting in front of the family television, of which there was one. Lying on my stomach, typing in any program I wanted to run from a large, thick book that they rented from the public library that they checked out.

That program would run as long as there was power to the unit, and as long as no one else wanted to use the TV. And really that was my first exposure to writing software, was typing in 20 to 50 pages worth of basic text from a programming listing book, for people who were too poor to buy software.

Len: That’s a great story. On this podcast, we’ve interviewed people from a range of dates. And I was wondering — you studied computer science in university?

Marcus: I did go on to study software engineering. Eastern Oregon has a very good bachelors program in software engineering. And so I was lucky enough to go there. But by then, I’d been programming about six or eight years, and I already knew that’s what I wanted to do.

Len: So you eventually moved on from that first computer, to one that could store memory?

Marcus: I did. In fact I remember buying using my paper route money to buy 60 minute audio cassettes, because I had purchased an audio cassette data recorder. And basically, if you wanted to save something, you would press the record button and the play button together, and then issue a command, and it would save the program you’d typed in.

Eventually I did upgrade over time. I think it’s interesting. I tell my children these stories, and think that I’m a crazy person to have ever gone through so much effort, just to get something to run. But for me, software was a very magical thing. It really felt powerful at a time of life when I felt pretty powerless socially, amongst other kinds of pressures.

So feeling like a wizard in front of the computer? Yeah, that was worth sitting down and typing and figuring things out. It also became part of my identity. The thing I could do really well was figure out computers. And I went through my series of IBM and Amiga and Apple, that whole thing.

I guess that origin story really left me with a sense of curiosity, and a feeling that I could be empowered to learn how things worked. Because even though I was young — and frankly I was the only one in my family who could figure the darn thing out.

Len: Since we’re going back to origins, I was wondering — what was your first experience with the internet that you remember?

Marcus: Well I was a big fan of BBSs. I don’t know if the age gap is too much here, but it used to be poor people didn’t have internet, in fact no one did. We plugged our telephones into modems. And we through various means found BBSs to communicate with.

But my first experience on the internet was — it happened to be that I was the first person at Oregon Tech to install a silly little program called Mosaic on the school network. And there were exactly five websites that you could go to by typing in these funny numbers with dots between them, which I later learned were IP addresses.

And the school actually — the school administrator, the server administrator said, “No, we’re not on any sort of internet.” And he was kind of shocked when all of a sudden I was pulling up other academic universities — Santa Fe. And he was like, “Well maybe we are on a larger network?” So that was my first experience. I went on to do such advanced kinds of things as, help professors understand Archie and Veronica. And by the way, if you’re not sure what those are — you should, you should Google them. Because they were how we retrieved and searched and sorted through information before web browsers.

Len: And what was your first job programming?

Marcus: My first job programming was — I worked in a wonderful language called FoxPro, which Microsoft still supports. But it was a database language. I was one of these sort of lone gunmen at a non-profit. Maybe you’ve seen these guys. They’re the guys who fix the printers, and they replace the mice — and sometimes they work on the network. And by the way they do a little programming when they’re not completely swamped with other things.

And that meant that any software development process that I’d learned in college, was thrown out the window. Because my boss would just come in and tell me, “We need that new report by Friday, and these are the fields I want it to have, and hurry up. And by the way, this computer needs a new mouse as well.” So the good news was — I felt sort of like the hero again. I could do it all. The bad news was — turned out it was really hard to get anything done in an environment like that.

Len: It sounds really tough. And to anyone listening who’s never been the computer guy — I know it’s a gendered phrase, but there it is in our culture — this is a figure we’ve all encountered, but we haven’t all been — and much respect to all those who filled that crucial and often neglected role.

Marcus: I still run into people today, Len, who tell me, “Well I’m the only guy at the manufacturing plant.” Or, “I’m one of 3 IS people, and jack of all trades.” So it happens. And then I think managers are really — especially non-technical managers — are really confused about what to do with these, these weird software people. Think they’re prima donnas, or they’re super picky. And they don’t want to talk to people, or they have all these strange sort of requirements. “They ask so many questions, why can’t they just get it done?”

Len: Leaping a little bit ahead in my plan, I was going to ask you about that question specifically. Because you have a great section, I’m forgetting if it’s in your book or a blog post, where you talk about how, even after a couple of years of being a team leader, rather than a programmer, you realized you’d already — this is one of the — one of the mistakes that you talk about in your book — you realized that you’d forgotten how hard it is to do.

Marcus: Right. And that was a real story. What was your question about it?

Len: If you want to tell the story, go ahead and I can ask the question after.

Marcus: Sure. I remember that when I became a team lead — I’d worked for a number of years, about seven or eight years as a developer, and senior developer and architect — and when I got promoted, it only took about a year or two, and I remember there was something that needed to be done quickly, and to me, it just seemed like it ought to be really easy.

I noticed that the developer just looked at me, like maybe I was a clueless boss — like that boss from Dilbert or something. Because I was using words like, “just,” and “simply.” So, I was saying phrases like, “We just need a Facebook login. And you’re simply going to write that to the database, and then it should do this other thing.” All this super ambiguous language, which he then, after a few minutes of listening, said, “You’ve really forgotten how complicated this is. You sure you used to do this job?” And I went off to my office feeling bad about that. Because I had forgotten that writing good software is actually really hard.

Len: That’s a great story. And the question I wanted to ask was, if even someone who’s gone thorough it themselves, learned how to program — self-taught, like you were in the beginning — and has worked in it for years, can so quickly lose touch, how do you recommend, or how do you communicate to someone who has never programmed and never will, how they ought to manage a software team, or even be an executive where — and this is true of basically every company in existence now — where software development is really important — how do you communicate to them how hard it is, and how they ought to relate to that part of their organization?

Marcus: I think that’s a great question. When it happened to me, I remember that I started getting so overwhelmed with my management duties that I didn’t really care how hard it was. And I stopped asking if it was hard. I just started assuming that because I used to do it — and I could remember I did it once — it must not have been that hard. And that memory was really like a false memory, right? It fooled me.

And so I would think to myself, “Oh I could’ve done that in a day.” Well that was never true, but with all these pressures from above, and from all sides — I just had to get some software produced. It was such a high pressure environment. So one thing I would say is, if you’re finding that you’re using these kinds of terminology — really vague terms — and I think the word “just,” and “simply,” are borderline dismissive — I just wrote a blog post about this actually. About how they’re almost offensive. Because they minimize the amount of work that something really will be. And they’re arrogant. So if you’re finding you’re doing this, take a step back and start to ask more questions than you are just giving commands.

Like, “Just put a login there.” Instead, ask them, “What kind of login should we use?” And, “How long do you think that will take?” Or even better, “What options do we have that might give me a range to choose from — of how long something might take?” I’m always shocked when I have specified something really clearly with a developer, and they work all week to get it done. I think the first time this happened, when I owned my company — I was just — I felt like such an idiot. I was like, “We have to use Twitter logins, that’s the coolest thing.”

And this poor guy worked all week. He got it done, it was great. And at the end of the week, he said, “Facebook would have taken me 20 minutes.” And I was like, “Really?” “Yeah. Oh yeah, Facebook’s easy. You had to pick the hard one.” And I thought, “Why didn’t you tell me?” Well you didn’t tell me, because I’d simply issued a command, right? I’d just said, “We need Twitter login.” If I’d said, “What are the options that we could use for social logins — and in your experience, which one’s going to get me something in a day or two?” I would’ve gotten a totally different answer. Because I would’ve engaged in a conversation.

Len: It’s interesting, that’s related to one of the issues you talk about in your book as well, where people wait too long to give feedback. I mean this is a version of that, but you talk about the concept of a feedback ceremony, and how people will — like I said, from the flip side — a manager might actually discover that there’s something wrong with some code, but wait for the scheduled meeting a week later — or 18 days later — as you used as an example in your book. And one of the interesting things about it is, first of all, that programmer doesn’t get that feedback about mistakes that they’re making for all that time in between you noticing it and the feedback ceremony. But also people can sense body language and other ways of relating, and then if you’re a manager and you’re mad at one of your team members, they’ll notice. And so you really shouldn’t wait for the next feedback ceremony. You should get it done as soon as you can — communicating.

Marcus: Ken Blanchard’s The One Minute Manager is a great little book for giving us some scripts and examples of how to give a one minute correction, a one minute praise. Things like that. Things that are to be done in the moment. I can’t tell you how many managers I start coaching and working with — and I always ask them this.

I say, with every new one, “Who on your team would you get rid of if you could?” They name somebody. They always have somebody that is in their mind. And I say, “Does that person know that? Have you spoken candidly and clearly?” And about 99% of the time, they say, “Well they ought to.” Like, “I don’t know how they couldn’t know it.” That’s another way of saying, “No, I didn’t give them any feedback. I’m just walking around appearing pissed.” Or, “A lot of resentment has built up in my heart.” I think of resentment as almost like cholesterol. It like clogs the good feelings from getting through, if that makes any sense?

So when a manager starts to build up resentment, what actually happens is, not only is the manager making a bad mistake, but the employee is actually in danger. This is what I find. Because the manager is thinking to themself, “That guy,” or gal, then he starts to use phrases like, “They don’t get it.” Or, “They’re not cut out for it.” And I think that’s a very static mindset. It causes managers to try and hire what I call unicorns.

It’s like the hiring process isn’t about getting raw talent and building up someone through feedback and through training, it’s about finding the absolute perfect person that you need, who can be a star player on day one. And I just think that not only is completely unrealistic for anybody who joins an organization, but frankly it makes hiring a whole lot harder. So yeah, I’m a big fan of [the idea that] a lot of feedback creates an environment where people trust each other.

In fact, programmers who tell me they have a really good boss — almost universally, they’ll say this: “I know where I stand with her.” And what that means is, we’ve got a feedback loop that I can trust. I’m not secretly worried that she’s mad at me, or that she’s holding something back from my review. I know where I stand with her. So I think feedback’s really, really important.

Len: It’s interesting, I’m going to ask you in a minute about leader-member exchange theory, which you write about. But you have this great blog post where you write about your journey through various interests and management philosophies as a journey through the sections of a book store. So that at a certain time in your life, you find — when you were younger, you found yourself I think in the science fiction section.

And then you sort of woke up one day, and realized you’d drifted over to the programming book section. And then eventually you found yourself drifting over to the management section. And you write about your intellectual journey through different management philosophy approaches. I was wondering if you could tell a little bit about that story, and moving on past great man theory to leader-member exchange theory?

Marcus: All the books I remember seeing in the bookstore, even today, have pictures of guys in suits in the business section, in the leadership section. Sometimes they’re wearing maybe military outfits, they’re generals. But most of the time, they’re wearing a dark suit, and they look like they’re someone who makes a lot of money — and they look very powerful. And frankly they look like they’ve got it all together.

And when I looked at that — here I am — I’m 5" 5", I’m chubby. I like to wear flannel — they don’t really look anything like me, at the front of these books. And so I just remember being in that section, and thinking, “Man, I don’t use hair gel, I don’t wear Argyle socks — and yet I have to figure out how to manage.” And I never liked those kind of smarmy people. I’m an engineer. So clearly I made fun of them a lot. And I can be sorry for that another time.

But what I realized was I came upon this idea — as I started searching, I realized that my management style didn’t attribute the team’s success to great attributes about myself. And as I started to study leadership theory, this “great man” leadership theory — which has been really popular for about 150 years; it’s pervasive, and it’s the reason we get so many famous people on the front of books telling you how to lead.

They’re saying, “This is the way I did it. It’s the way you should do it. It’s a proven system that works.” Yet frankly, we don’t need more systems. We need more relationships. And leader-member exchange theory — that was a sociology theory that started in the 70s. These sociologists wondered — can we and should we attribute team success, and in fact organizational success, just to the leader? Does he deserve all the credit and all the blame? Or is it something about the relationship that an employee has with their manager that matters?

So they started to measure the strength of that relationship. And what they found was naturally — completely without knowing it — that two groups of people would always emerge. Sociologists call this the “in group” — those are the people closest to the manager. And the “out group”. And my guess is — right now Len, you probably can think back to times maybe when you were in the in group, and had a really good relationship with your manager. You trusted each other, you could talk about things. Maybe other times you’ve been in the out group, and it seemed like you were maybe a little bit more at a distance. And you maybe were even jealous of people that were in the in group.

So leader-member exchange theory helps managers to see that there are these two groups. And yet it’s the relationship that each employee has with their manager, that really matters. In fact, in group members — people who have good relationships — sociologists found that they enjoyed a whole lot of other soft benefits. They get better projects. They get better pay. They get promoted more. They get brought into the fun projects. And people who are in the out group — well they’re treated like, just punch a clock, do the grunt work. We just expect nine-to-five from you, we’re not going to promote you — you just do your job, and you’re a cog — if something doesn’t work out, we’ll just replace you.

So everything I teach now is about building relationships through things like one-on-one meetings, zero surprise evaluations, and constant feedback cycles, that help you as a manager put practices in place that intentionally move people toward you, into your in group. Because leader-member exchange theory says that — and I really believe this — that managers can emphasize the relational aspect of their work. And they can invite people, essentially, to have a closer relationship with them.

Len: It’s interesting. I remember reading you talking about the out group and the in group, and it reminded me of my first real job, which was a summer job after my first year of university, where I was treeplanting in the mountains in British Columbia. For those unfamiliar with that job, you’re not planting a few trees a day — you can plant literally thousands yourself. You’ve got boxes of trees that are placed in an area for you, next to a clear cut piece of land.

And you have these bags on your back that you stuff the trees into. And then you pull a tree out and you make a hole with a shovel, put the tree in the hole, and close the hole with your foot or your boot, as you then take your next couple of steps — and then plant a new tree. And I was definitely in the out group. Although it was partly based on my personality, it was because the foreman came in with a group of buddies. And then there was everybody else.

Us — everybody else, we sort of formed our own group in a way. But what the foreman would do is, he would give the cream, as we called it, or the best land — because you were paid per tree, so the better the land, the more money you made — and he would give the cream to his friends.

And one day he came up to me, and I knew that there was a piece of creamy land coming up. And so I worked extra hard to finish my current piece of land that I was working on, so that I would be in line for that piece of land. And I did that, and the foreman came up to me and said I needed to replant, because he’d looked and seen the quality of my planting was low. I knew that he was lying, and that he was just doing this to make sure that his buddy, who was next in the queue, would get the creamy piece of land.

So he left, and I just walked around swearing and muttering, and not touching a single tree for about half an hour. By which time, the in group guy had been given the next piece of creamy land. And my foreman came over and said, “Okay, I’ve looked and everything’s fine now.” And then he put me onto another piece of land.

I saw this later in a very different job, investment banking, where a boss chose a favorite. There’s the in-the-moment experience of being cheated like that, but what happens is, what’s really pernicious about in group-ness, to those who are not in it — is that the favorite gets put on the best projects.

And then that favorite is then associated with the best outcomes. And then they get all the benefits of ego and reputation — and just the positive experience of being at work. So that, over time, it can become a really punishing experience for someone in the out group to be watching someone on the in group advance.

Marcus: It’s brutal. The story you tell — it’s just upsetting. I wish I could just throttle those managers. I’ll just ask you. Like clearly you walked around cursing, but did you have any investment in the quality of that job, that tree planting job?

Len: Oh yeah, I wanted to do a good job. I mean, I loved the adventure of it, and I loved working in the mountains.

Marcus: Well, you’re a nice person then…

Len: But I also cared about — when you see a clear cut, you want to — I mean at least when I saw clear cuts, I wanted to fill them back up with trees.

Marcus: I think that’s great. I can tell you though that just having a boss like that, it must’ve been — good for you for not letting it impact the quality of the work that you did. But I have to tell you, I’ve been on the out group a few times. And for me it actually did impact the quality.

In my case, I was repairing old pay phones. Not even old ones, just pay phones. I say “old,” because it was 22 years ago or something. I stopped really caring about the job as much, when I realized that I was never going to be in the favorite group. And I just got a bitter, resentful, angry heart. I didn’t like my boss, and I didn’t do a great job, and I was just there for the pay check.

Len: It’s interesting. I was the highest earner of the rookies on that crew, in spite of not getting the creamy land — looking back on it, that probably helped me weather the storm, because I knew that there was an objective measure that was always there before me that I could take, I guess, some sort of pride in.

Marcus: So at least you had both money and — my guess is you felt that sense of accomplishment in doing the job. Looking back, and seeing your land was well-planted. As you might guess, with software — between the fact that it’s very abstract — and oftentimes there’s no financial difference between writing good code, and writing poor quality code, because it’s so abstract.

Not only do we see that these poor people who are left out in the dark, are feeling bad — they’re getting passed over, they’re not doing as good a job. And frankly, they’re the ones who are going to leave. They’re going to leave as soon as possible. And they’re the ones who are polishing up their resumes. And walking around essentially stomping and cursing behind the building.

Len: Personally I believe that if you wake up one day, and find yourself in the out group, you should set a deadline for yourself, and say, “If things don’t turn around by then, I’m out of here.” I guess my ego is strong enough that I was never hurt or jealous, I just sort of felt like an observer the couple of times that I’d been in the out group like that. But definitely, if you’re an ambitious person and you have career goals and you find yourself in that situation — you have to change it, or you have to leave. That’s a bit harsh, but -

Marcus: No, you’re exactly right, and let me just speak to that. I think a lot of people — for example, imagine that we have these bosses working. Especially tech bosses, technical leaders. We might think that they should be really good leaders. That they should know how to manage people. But like — Johanna Rothman and I did a survey last year…

Len: Oh, you know Johanna?

Marcus: Yeah, she’s great. And, her and I did this joint survey on how much training technical leaders get. And the result was overwhelming. Zero to three hours is how much training people got for their first leadership job. And I say that, just because a lot of programmers imagine that the person — the guy or gal above them ought to be good at their job. But half the time, or 90% of the time, they used to be a coder, they’d rather be coding. They’re sort of doing this leadership management thing, because they need more money, and it’s the next logical step. And we imagine that the person at a higher power, higher status than us — like our boss — should be the one to initiate the relationship.

I found that I’ve been able to initiate relationships with my boss, and actually move from the out group to the in group, by asking for one-on-one meetings. By starting to ask for honest feedback. And giving honest feedback. And while that is a little bit risky at times, because it feels like we’re in the lower position, why shouldn’t they do it, and what if they fire us? The reality is, if it didn’t work, I was going to leave anyway. Just like you.

So I figured I’d take a chance, and I’d taken a relational risk. I would say to my boss, “I really want to have a better relationship, where we communicate more often, and I’m aligned with what you expect more often. So even though you don’t do one-on-one’s with anybody else, because that’s not the way we do things, I want us to have a weekly one-on-one. And I’ll even set the agenda.”

I never had a boss who said, “No, I won’t meet with you once a week.” Because oftentimes they’re not sort of trained managers — with a capital M. They’re oftentimes just trying to tread water. So your initiative really means a lot to them. And, frankly, they need all the help they can get.

Len: You mention in your introduction to your book, about how you were not prepared the first time you moved from being a programmer to a team leader. And I was wondering if you could tell us a little bit about that experience?

Marcus: It was the year 2000. So we’d just gotten over the big Y2K debacle. And the world hadn’t ended.

Len: For those listening who might not remember, when the year 2000 was approaching, there was a huge, huge worry on the part of many people that became expressed as “Y2K,” which was that — basically the clocks in computers, and programs basically, wouldn’t be able to handle this switch. And planes would come crashing down, and electricity grids would stop working and things like that.

Marcus: Fortunately it wasn’t that bad. But honestly we had a lot of work to do in the manufacturing system I worked on, to make sure we kept things running. But it’s funny you ask about that. Because I’ll tell you the story completely honestly.

So I’m in the rest room, and I’m reading Java World — which was an industry magazine — and frankly I’m in the big stall, sort of taking my break.

And this person bursts in, I have no idea — didn’t know who it was. And they yell, “Marcus, you just got promoted. You’re a manager.” And they ran out. That was it. That’s how I heard that I was going to be promoted. I left, and I went to my boss’s office, and I said, “Did you just — was that you?” And he goes, “Yeah, I just found out. Now you’re a manager. You’ve been promoted to lead your team. I’ll let everybody know tomorrow, and you can move into the office.” And I was like, “Okay, that was pretty memorable.” I’ll never forget how I heard that I was going to be a manager.

Len: That’s fascinating. And what was your experience like when you suddenly had this thrust upon you? I mean, did you go read management books right then?

Marcus: I didn’t. I thought, “How hard can this be?” I’d had a good manager — other than maybe the way it was announced, he was a very good manager. But the reality was — is — I just tried to be everybody’s friend. I thought, “Managers are nice, and I really want everybody to like me. So I’ll still get to do all the fun coding parts. Maybe I can even just pick the best coding projects. I’ll pick the cherry projects for me.”

And that quickly turned into me spending evenings and weekends trying to get the coding work done that I’d committed to, because it actually takes a lot of time to manage eight developers during the day. They want to meet with you, they want to talk with you. The customers want to talk with you. My approach upfront was definitely the idea to try and be their friend.

And I’ll be honest, they thought it was kind of weird. They were expecting somebody who would understand that they were in a new position, that they had a little bit more formal power — and that they were ready to try using it. But I was pretty scared of that. So I just tried to be everybody’s friend, and they thought it was weird. It was a really uncomfortable bi-directional relationship.

It wasn’t until somebody said, “Hey man, you’re kinda acting like a buddy. Why don’t you just be the boss — we need a boss, could you be that person?” And I was like, “Oh, yeah I guess I could try that. Although it seems a little scary.” Because I didn’t always know exactly what that meant. So it was a lot of trial and error.

Len: One of the interesting, very sort of human mistakes that you talk about in your book is, the mistake of fixing other people’s mistakes. And how, especially if you’ve done their job in the past, how tempting it is to just fix it, now. I was wondering if you could talk a little bit about why — why that’s wrong?

Marcus: That’s a great question. It’s wrong because it robs the other person of an opportunity to get feedback. And it limits how good your team is going to be. Because they never get to experience the feedback, the criticism or the praise of them doing something well. Instead, you’re going in and cleaning up after them. It also sends the signal to them that, “We don’t really have to do a great job because Marcus will fix it.” Or, “If it gets into production, probably Marcus will swoop in, and just handle the data corruption or whatever.”

So they felt pretty safe about moving a little more fast and loose, and that wasn’t really the message I wanted to send either. So it was kind of lose-lose. Plus the reality was that I shouldn’t have been — they also got offended, and I don’t blame them. If somebody takes work from you, you infer that you did such a bad job that they’ve actually lost confidence in your ability to fix it, right? It sends this terribly negative — almost a shaming message. And so yeah, I think it’s bad for all those reasons.

Len: When you decided to write this book, I’m curious why you chose Leanpub as the platform?

Marcus: Well, I’d looked around — and I’ve shopped it around, and I’ve talked with the Prags and a few other really great publishing houses, and I just was really nervous, frankly, about how this was going to come out. And I wanted to kind test and see if there was anybody interested. The last thing I wanted to do was write a book and find that five of them sold, or, it was just way to low. I would feel like that would’ve been a big hit to my ego.

Leanpub basically allowed me to throw up a test page, and pretty quickly start to find out — by people voting with their pocketbook — is this something they were interested in? And my mailing list was the first group to get a coupon. And I’ve gotta tell you — selling like 100 the first day, was validation at least that there was some people interested in the topic and the chapters. And as I went on, I fleshed things out — and I’m continuing to do that with the book. But I just really like the iterative style that you guys allow me to adopt.

Len: Like a lot of other Leanpub authors, you give out your email address, and invite feedback in the introduction to your book. And I was wondering if you’ve had feedback?

Marcus: I have had a little bit of feedback. It’s been great. I really appreciate when people tell me what worked for them. I’ve had people in completely non-technical industries — or at least non-software — like I had a gentleman in materials engineering write me and say, “Everything here applies to what I’m doing.” And his comment was, “Why don’t you make your stories a little more generalized,” or, I had somebody who runs creative agencies, and they said, “Why can’t you bring out a version for art directors and creative leads? Because all these habits still apply.” I’d never really thought about that. But that gives me ideas for either, other books, or variations on the same theme.

Len: One of the bad habits you also talk about in your book is not expressing gratitude. And so I wanted to end our podcast by saying, thank you for taking the time to do this. And taking the time to write the book, which does have a lot of really helpful stories and ideas for anybody who’s moving on to a team lead role — from one where they’re a member of the team.

So thanks very much Marcus for taking the time to do this interview, and thanks for being a Leanpub author.

Marcus: Thank you for having me, and for selecting me for the podcast.

Originally published at gist.github.com.

Like what you read? Give Leanpub a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.