Michael Rice, Author of Professional Services: Day 1, Hour 1

Len: Hi I’m Len Epp from Leanpub, and in this Leanpub Frontmatter podcast I'll be interviewing Michael Rice.

Based in Los Angeles, Michael is manager, leader, consultant, software engineer and a lawyer, with over two decades of experience working in the industry for companies including Red Hat and Intel, Disney Studios and Accenture and many more, and most recently with VMware.

You can follow him on Twitter @michaelrice and check out his website at michaelrice.com, and sign up for his Tech Lead Coaching newsletter at michaelrice.substack.com, and you can check out his Tech Lead Coaching podcast on Apple Podcasts, Spotify, and elsewhere. Finally, if you're a tech lead yourself, you should also check out his other website, techleadcoaching.com.

Michael is the author of the Leanpub book Professional Services: Day 1, Hour 1: An Introduction to Professional Services in Software Companies. In the book, Michael offers a unique introduction to having a career in professional services for software companies, what it means to be a consultant, and how to plan and conduct your career.

In this interview, we’re going to talk about Michael's background and career, professional interests, his book, and at the end we'll talk about his experience using Leanpub to self-publish his book.

So, thank you Michael for being on the Leanpub Frontmatter Podcast.

Michael: Thank you for having me. This is great.

Len: I always like to start these interviews by asking people for their origin story. So, I was wondering if you could talk a little bit about how you first became interested in computers and technology?

Michael: I'm glad you asked that question, because talking about myself happens to be my favorite subject. I got started in software - I'm going to reveal my age by saying this, but I got involved probably in the 1980s.

I grew up in Phoenix. At the time it was very much construction-heavy. I guess you could almost call it a blue collar town, at the time. And I had this computer that I bought. It was actually called a Hyundai - it was a Hyundai computer. I don't even know if they make computers anymore.

I didn't tell anybody - at school, I never mentioned I would go home and play with computers and write code. It's funny how different things are now today. I just got back from Silicon Valley yesterday. I see all these people walking around, and I'm like, "Oh, they're so geeky." When I was a kid, that was not cool.

So, it's kind of nice to, to feel less geeky. Or, maybe it's good to feel geeky and not feel not cool, right?

Len: It's interesting you bring that up. I mean, I can date myself, I was born in the 70s and I remember the introduction of the personal computer to the home, and to school, and things like that. And for those not as old as us, back in the day - and there is actually a lot of residual elements of this to this day - but being into computers made you a nerd. And that was a bad thing, you would suffer sort of bullying and things like that, and just negative representation everywhere you looked actually, including in movies and stuff like that.

That has completely changed - or, that hasn't completely changed - but it has changed a great deal.

And so, when you got your first computer, did you start coding, or did you play games?

Michael: Well, I mean those were those old PCs, right? So there wasn't a whole heck of a lot you could do. You could write code, like BASIC. And you would get - I don't know if you remember, but they had these magazines you would buy. There was Computer Shopper - that really big, thick magazine. But there were other magazines too, and what they would have is code in them. And you had this special ruler with a magnifier, and you'd roll down line by line, and hand-transcribe the code. That's pretty much what I did.

There were a few games. You could go to Target, and you could buy floppy discs with some games on them. But they were all text-based, or had really lousy graphics. And then later, I got really into - I bought a modem, I talked my mom into buying me a modem.

And on the back of Computer Shopper, they would have all the phone numbers you could try to dial - and more often than not, you'd get a busy signal. But you'd try to get into some bulletin board system. I ended up running one of those for a while. I got into like FidoNet. And it was all stuff, like we talked about - I would come home from school and mess around with that, and that's what I would do for fun. But I certainly didn't go around telling people at school how cool it was that I started some bulletin board system. Very much like a secret thing.

Len: And you didn't study Computer Science at university, as I gather from your LinkedIn profile?

Michael: No, no. It's kind of funny - back in the 90s, right around the time that I started out in college - like I said, I didn't want to be a programmer. And honestly, most people didn't want to do that. If you were to ask like an academic adviser at the time, they would generally - at least in my school, they were trying to dissuade you from doing that. Because they were like, "There are so many computers in the world. There isn't that much demand for computer programmers." That's what they were called, right?

And so, I actually started out in accounting school. And in accounting - it was in Arizona State in Phoenix, Arizona State University. And the program was heavily sponsored by Andersen Consulting.

Andersen Consulting was a really big deal before - it was one of the big - I don't know if, I think they were part of like, kind of the big eight. I mean, there were the big eight accounting firms, and Andersen was a consulting firm that had grown quite a bit and, it was very successful.

And so they were all trying to use the accounting program to try to turn us into these consultants, around things like databases, like designing databases and designing SAP - the big enterprises, the ERP system - trying to turn us into SAP consultants. Which, I wasn't so much interested in the technology, but I was really interested in the business side of it. And I thought it was super exciting, for a nerd, right? It was like, hey, those skills I had - suddenly I'm like, "I could be cool and I can be relevant." And not only that - but I could work for a company like Andersen Consulting, and people would actually pay for what I know,. And pay a premium, and fly me around the country or the world, to do that kind of thing - that sounded super cool to me.

So, I got really excited about it, I got really engaged in the program. But back then, there was - I know the job market is extremely hot right now. I know because I hire software engineers and consultants. But back then it almost felt hotter, in the sense that you could just walk into a job. I remember, I would get jobs without even - like no coding exercises, no interviews. They would just hire you over the phone and say, "Come write code for us."

And that's what we did. It was so hot that I actually ended up basically not finishing my degree. We did the semester system at the time. I was a senior in my last semester, I didn't even finish. It was so good that I just went out and I ended up working for Intel at the time. And yeah, so I didn't finish. But then, ultimately - once the online school programs came on, I finally did finish. But it was quite a while later. And they didn't have a Computer Science program at the time.

Len: We're talking mid-90s here, right, I imagine?

Michael: Yeah.

Len: Right when the World Wide Web was kind of like exploding.

Michael: Yyeah.

Len: And so eventually you took some time off, not to travel but to go to law school. What was your reasoning behind that?

Michael: I know. That's another dirty little secret that I don't tell. This is kind of funny. It went full circle, right? I'll tell you how I ended up there.

In the 2000s, we had gone through the 90s, and then there was the dot com bust that happened. A lot of people - it's funny, the people I hire that are a generation or two behind me, don't know about this. But there was a time when all of sudden, there were no jobs for computer programmers - there was nothing going on. I managed to survive that, and I held onto my job.

But then the industry, it was kind of weird. Writing code and developing software - after that period, it was kind of like - I don't know know the right word to describe it, but it really wasn't that cool. It was like the processes we followed to develop software were what you'd call waterfall today. It was very like high pressure, very - almost an assembly line-like mentality. And it just wasn't fun at all.

And so by then - it's kind of funny, I thought - we did the World Wide Web, right? And we were building these applications that were web-based solutions. They were kind of cool, but after a while you start doing that over, and over, and over again. And it seemed like that was as great as it was going to get. And I'm like, "Well, I've done this. It's boring."

My stepdad in Arizona was a judge, a county judge. And so he had a huge network of lawyers and friends. I thought that was a pretty cool business, or industry. And so I just took a break.

I went up to Seattle, went to law school. I really loved it. Like I told you - I was a college dropout in a way. I didn't get into a great law school, but I got into a school I really liked - and I really loved it. I really engaged in it. I tried really, really hard. It's a really intensive experience, for people that are listening to the podcast, will know. At least if you want to do well.

I actually did great. I graduated toward the top of my class. I ended up getting a clerkship in the federal court system, which I did. I tell people, it's similar to getting a job in Congress. Like a clerk job or a - I don't know what the word is? But, it's a big deal. Because you get to work right there with the Judge, and see how law actually happens.

I loved the experience, but the only problem was - when I came out of that clerkship, it was like the height of the recession still. And so there weren't a lot of options, even for somebody who had done pretty well. But I think it was kind of a good thing. Because, honestly, I don't know that I would have been happy just working as a lawyer. And because while I was in law school, all of a sudden, software became super cool - like really cool.

There were all these startups, and I was in Seattle, and I got really engaged in the startup ecosystem. I was doing software patents - I was more technical than I had ever been while I was in law school. It was the strangest experience.

And so after law school, I ended up working for Accenture, which was a company I'd always wanted to work for. They're a massive consultancy. At the time, I think they were just short of 300,000 people. I heard they just crossed over 500,000 people worldwide. So it was a great opportunity - and that's how I ended up working at Disney.

Len: And Accenture was formerly Andersen Consulting.

Michael: Well, actually I think it was not. That's kind of the line, right? But it was - what I think happened is a number of the partners from Andersen went off and created their own thing.

So Andersen, I think, went bankrupt - it was done. But there were a number of partners that left and then formed Accenture. [Here's the story - eds.]

Len: What was that experience like? So there you are, finally working for this big global consultancy?

Michael: Yeah. Accenture is a really interesting place. I mean, it's so big that I can hardly speak for the entire company. Because they're so - they're just engaged in so many different businesses, and industries, and verticals. Mine was the media and entertainment vertical, here in Los Angeles, which makes sense.

It's a really interesting place, because it's a fairly aggressive environment. So the consultants are all - well not all. Like I said, I can't speak categorically about such a big company. But many of the consultants are very aggressive, they want to get promoted. And at the time, they had kind of a - I don't know if a stack ranking is quite the way to describe it, but basically they'd say, "Hey, look. In this group of - this pool of people," they'll put numbers on people. And you're number one, you're number two, you're number three, you're number four, right? And so the goal was to be in the top list.

I think having just left law school, I felt pretty competitive in that world. But then again, I was writing code for the first time, after a few years of being out. So it was a great experience. I really, really loved Accenture. I always tell people that are just coming out of college or just getting into programming, or software - working for a consulting firm is a really great opportunity. Just because - like I said, I worked for companies like Intel, I worked in a cubicle year, after year, after year.

And it was kind of the same - I hate to describe it like this, but it felt a lot like the same year of experience repeated over and over again. Or, maybe it was like, one year of experience spread over six years, right? But, in consulting, it's real rapid fire. So, you're constantly going from one project to another, the players that are involved are different. The pressure - there's usually a lot more pressure - not always, but a lot more pressure to get things done. So it forces you to grow in ways, that if you're just orking in an individual contributor role in a big company, you just - I think you just generally don't get those kind of opportunities to grow.

Len: I think I know what you're talking about. I spent a few years as an investment banker working in mergers and acquisitions in London in the European utilities sector, which sounds boring. But it's like - all of a sudden someone taps you on the shoulder, and the next day you're in Paris for six months, working on a company that you knew nothing about the day before.

And then you have to get really into the weeds. It can be really exciting, and it can be thi - there can be this incredible - it's a lot of hard work and it's a lot of hours in jobs like that. But if you like what you're doing - if you like change and pressure, and to some extent - competition, those worlds can be a very good - and even if you don't want to do it forever, having a couple of years of experience in an industry like that - and in consulting - can actually really, really change you. And change the way you approach challenges in whatever you go on to do afterwards.

Just to digress for a moment - we'll come back to your career as a tech lead and a consultant and the things you write about in your books. But, so, you're a lawyer, and you know software. What are one or two of the things that software engineers should know about the law in the United States, that they typically don't know?

Michael: That's a great question. There's a lot of different bodies of law. And I think the one that I would recommend - so, intellectual property obviously comes up a lot. I think people get a little wrapped around the axles in terms of how intellectual property works. And I think in a lot of ways, I would say it's probably the least important area to focus on, when you're writing code. I think some of the more interesting areas are what's happening now with - if you think about a lot of the technology that we're building today, that touches lives in ways that when you and I were kids it didn't.

Back in the early days, we would just write a game, or build some little thing. But now, the applications that we're building obviously collect a lot of data, they connect people, they do things that intersect with people's daily lives in ways that never have before. And so I think having a good understanding of - not just the law, but why the laws are there - I think it would be a very interesting area for software engineers or product managers or people that are building software, to think about.

Because I think they're often seen as a stumbling block, or something that gets in the way of getting things done. But, I think if you were to step back and think about all these different countries that your software might run in - they've written laws - you may or may not like the way the law was created or what the law says. But the law is supposed to express that society's needs and their desires.

Things like privacy. Privacy's obviously become a huge issue here in California. I think rather than trying to work against the law, or push up against its boundaries - just kind of think of, what is society trying to tell you - into doing this thing? That privacy actually matters, that there's some value. There's some human, societal value behind the law that's there. I think if you can work within the spirit of the law, I think in most cases, you're going to be in good shape. And I think you're on the right side of history if you do those things, honestly.

Len: It's a really interesting thing, especially if you are part of a small startup. I'm Leanpub's resident non-technical person, even though I do do some coding and have to know how to look at code. But given my background in investment banking and stuff like that - I'm the Chief Compliance Officer, and the Data Protection Officer. And it's my job to read the GDPR, like actually read the legislation.

And you just mentioned privacy in California - and something that recently came into being was the CCPA, or California Consumer Privacy Act. Which, like - we're based in Canada, but we have to know about this. We're based in Canada, but we have to know about the GDPR as well. It's a really interesting thing about the law now - where a region, or a country - or even a state, can impose rules that then apply to people doing stuff that are far away, and have nothing to do with it.

And so you actually have to - in the same way that California's automotive regulation can end up setting the stage for the whole country, or like Texas's textbooks decisions can set the stage for textbooks around the country - one small part of the world can affect the rest of it, when it comes to what you're doing - if you're a company operating, or even an individual operating online.

So, I was wondering if you could talk a little bit about the CCPA, if you happen to be up on it? I don't want to put you in a position where you don't want to talk about it.

Michael: Yeah, I probably can't go into it.

Len: Okay, okay.

Michael: I mean, probably, I can't - I mean, it sounds - that would be something we could do a whole thing about someday.

Len: Okay, I thought I'd try and take advantage of having you here as a lawyer, because I've been reading about it, and we've been adjusting our Terms of Service and things like that in order to adapt to it. So, my loss.

Michael: Yeah, so you're like, "Hey, let's schedule a podcast, get free legal advice." It sounds -

Len: Yeah, that's exactly what this was all about.

But anyway, in any case - it really is an interesting thing that - even being a software engineer, you have to know the law.

Michael: Yeah, but like I said, I think - I don't know? I just don't want people that are hearing this or that - I don't want you to get wrapped around the axles with what the law is so much, you know what I mean? I think it can feel antagonizing otherwise. And I think it's actually - there are the quirky laws and the ones that cause you frustration in its own. It can feel annoying.

But it's also part of being in society, right? Like, we don't drive our car at 100 miles an hour - well, I mean not usually - 100 miles an hour down the 405 here in LA, because we're putting people at risk, right? And it's dangerous and I think the law is there to protect against those kind of harms, just like it's there to protect people's privacy and their rights and what they value. I think if you change your relationship with the way you look at the law, as a software engineer, you can find a little more happiness and a little less frustration, hopefully.

Len: I couldn't agree more. I mean, there are sometimes bad laws with bad lobbies behind them. But typically, a law is there because a lot of people were concerned about something, and they want to - a lot of people think it's all about protecting the consumer or the citizen from some negative corporate sort of activity. But actually, a lot of laws exist to provide clarity for you as a business, for what the ground rules are, on which you can build what you do - and being a good member of society.

So although when something new comes out and you're like, "Damn it, now I've got to read this long legal document" - and it's often legislators and even lawyers who draft stuff, who don't really understand the industries that they're touching on - that can be very frustrating to see. But when you understand that the intentions behind it are usually good - and as you say, like, wondering at a high level, "What is the law there for?" It's in order to enable to us to all do stuff, and get along safely and productively.

And when you view it that way when a new law comes out, it's like, "Okay, well now there's some new ground rules." Pretend it's like a board game and there's a new iteration of it or something like that, and you've just got to read the fucking manual.

So, moving on. Part of your career has been being a tech lead, and I was wondering if you could talk a little bit about, what - for those who might not know - everyone knows what coding is, and stuff - and that a lot of our software products are built up by coders. But, what's a tech lead?

Michael: That's a great question, because there isn't really a good answer. But I'll set the context a little bit.

In most companies, as a programmer, or as a software engineer, you could theoretically build an app. And there's lots of stories about people who build a cool app, and they put it on the app stor,e and they make a ton of money, but they do it on their own.

The reality is, in most organizations, it's a group of people building software together. And so there are managers - typically in an organization, you'll have a team of software engineers - which might be more than just software engineers. They could be quality assurance, QA people, there could be product managers.

Speaking of law, there's a new thing now that you see sometimes - legal counsel will show up in your team - or product counsel, they call it.

So you've got this assembly of people. But then in the organizational chart, you often have a manager. So the typical role in a software company would be an engineering manager that's theoretically managing this team - whether it's a software company, or a financial services industry - or whatever it is.

You'll have an engineering manager who's ostensibly there to make sure the team's getting all the things done, and getting the features developed and shipped, and all these things that we do in software engineering. Which is a lot more involved than just programming, right? Programming is writing code. The vast majority of software engineers spend 90% of the time reading code, or talking about code, or thinking about code - and very little time actually writing code.

So anyway, a tech lead is often this kind of amorphous role that you'll see show up from time to time - depending on the organization. So if an engineering manager has - let's say there's, in his or her world - let's say they've got five or ten software engineers. But they've got a number of projects coming in, or a number of products they're working on, or features, or whatever. It's usually more than just one thing, it's usually lots of things at once.

So an engineering manager - if you think about who they are, they're often software engineers who got promoted into this role. And so they've got this big field of stuff they have to work on. They've got all these people they've got to manage, they've got all these projects. They've got things in terms of projects - they've got people, and they've got time - and they have to manage all this stuff. It's pretty chaotic.

So most engineering managers are people - in that, at that first-level people management layer - they rarely are able to actually keep track of all the stuff. And so what they'll do, is if you've got a team - let's say you have a team of like four or five people. The engineering manager will often just go and tap one of those individuals, for any number of reasons - to say, "Look, I'm going to delegate some of the stuff that I'm supposed to be doing," in terms of making sure all the right products, all the right features are being built, they're being built the right way, on time, on schedule, etc. "I'm going to give that to you, tech lead," right?

And so if you Google out there for a "tech lead," you'll find - basically for every tech lead that writes an article on what a tech lead is, they've had their own experience. And they'll write it, and they'll say, "This is what a tech lead does." And then you go find another article that says, "This is what a tech lead does." And it's hard to triangulate, because of the way that the tech lead role shows up.

It just varies depending on who the engineering manager is, what the team is and what they need. So the answer to the question "What is a tech lead?" - let me give you a consultant answer, it depends. It depends a lot on the circumstances on the ground, what the needs are, so -

Len: But some of the skills do kind of cross boundaries. I think you've written about the importance of listening, which sounds quite abstract, but it's actually a pretty important thing. I was wondering if you could talk a little bit about the importance of listening and why it's sometimes challenging for a tech lead to do that?

Michael: I think listening is challenging for everybody, right? Don't you?

Len: Yes.

Michael: In the book I wrote, it's called How To Be A Tech Lead, it does need a new revision, and I'm so grateful that Leanpub lets me revise books, because it definitely needs a refresh. But the idea is, because the tech lead role is really varied - in terms of like what the needs are in the moment, what the role is for you at that time - I try to focus on just a number of capabilities, that I think will get you - I call them Pareto capabilities, so you're familiar with the term "Pareto", right?

Len: I saw it in your book, but I actually didn't look it up yet. So if you could share what that is, that would be great.

Michael: Yeah, I think it would be helpful for people that aren't familiar with the term. It's a term in you hear a lot, at least in my industry. And so the idea was, Pareto was - I'm going to bungle this. Somebody's going to correct me on this, which I hope they will. But Pareto was - what was he? Was he a mathematician or a researcher of some sort?

And the kind of this idea that, like, 20% of the activities usually result in 80% - or 20% of something results in 80% of the impact. It's this kind of weird principle that seems to hold true in a lot of different situations. The real common one is organizationally. You'll have maybe 20% of the people that have 80% of the impact. It's kind of true in sales, it's true in all kinds of places. And so I was thinking - in all the time that I've been seeing tech leads, one thing that would be interesting to talk about is how lousy a tech lead I was.

But I noticed the very successful tech leads later in my career - once I had evolved a little bit on my own - but also seeing other people in a tech lead role. And I've seen hundreds of them by now. It's kind of the - the patterns that I've seen, this is by no means some kind of exhaustive Google type research, which I wish I could do -

But I've noticed that - I think that listening, and the reason I draw it out as one of the first four of the most important capabilities - is because I think it's the foundation of everything. And if you think about what's so wrong organizationally - you've probably seen this in your world. You probably see it at the coffee shop in the morning. It's like - so much of what's going wrong in projects, is that nobody's heard each other.

So if you're a tech lead - if you haven't really heard what your team is telling you, then you can't really lead them. And vice-versa, if you haven't heard what the project manager really said, or what the engineering manager really said - if you haven't been able to hear what they're telling you - then you're just gonna fail. You're just going to make mistakes. The term you hear sometimes is "motherhood and apple pie," which is not - it's kind of getting to be an old term. But as simple as listening is, I think it's really important - and I think we overlook it. So I wanted to call it out first.

Len: That's a great explanation. And yes, it is definitely a universal challenge. I just had an experience with this yesterday where someone I was working with was proposing something that was just so - that turned out to be probably the right thing to do, but to me was just so profoundly mistaken - that I completely misheard what was said, and did something completely different.

And it was just like I was in an alternate universe, and it was me that I had to get over it. And that didn't mean agreeing - but it meant just being outside of myself enough that I could actually hear what this other person was saying - was something I failed at, because I was so preoccupied with my own sense of what was the right thing to do. So yeah, that can definitely be really hard.

And you mentioned that your - you write about this in your book, that in your first experience as a tech lead, everything sort of was finished, but you would have given yourself a grade of a B or even a C if you'd had to do that. Can you talk a little bit about that? What that was like, and what you learned?

Michael: And to pick up on that last point about listening. I think - really, it's kind of funny with that. It's amazing how much we block our own listening. It's like we want to blame other people for not saying things correctly, or making you angry or making you mad or irritating you or whatever. But usually it's just like - if you just can get out of your own head for a minute, you can actually hear. And it's hard, it's very, very hard. It's not a normal human thing to do, to put your own needs aside for a second.

That's kind of the thing I had, my first time really getting a project. This was a semi-conductor company in Phoenix - not Intel, but a different one - and we were going to rebuild a - it was like an Excel-based process for - It was like, people are going to - your podcast listeners are going to fall asleep when they hear this. But it's a very typical kind of enterprise software type thing to do.

But there was an Excel process where they'd generate quotes for people that want to buy the company’s products. And strangely, that's actually really complicated. Because you've got all these channel partners and discounting and all the stuff. So it's actually really complicated to generate a price, for most companies that have any size.

This process was to try to like automate that. So if you rewind to the early 2000s, enterprise Java was a big deal. There was all this really hot architecture about enterprise Java and Java Beans and all this cool stuff, and multi-tier architectures. The reason I'm kind of diving into this, is because everybody's ears and eyes are glossing over as I describe this.

But I thought that was the hottest technology around, and I thought that was so cool. There was this problem they presented to me of, "Hey let's like improve this process." All I heard is, "I want to build an enterprise Java - and I want to improve my career, my resumée - and this going to make me another 20% on my next gig," or whatever. Building the software was more about, what did Michael want to build? Less about, what did the company actually need, and what did they want?

That wasn't my biggest problem of course. So the biggest problem was - it was actually a fairly cool design, people were game for it. So I got a team of - one person - this is starting to get to be old history now, so I don't remember all the details. But there was one person on shore and two people offshore. I think it was that configuration. Kind of a mix of senior and junior people.

And I remember, I was just like, "Oh my God, I'm in this position where I have these great ideas and I want to tell people to do them, right? If they would just do what I told them to do, they would understand how awesome this is, right?" But actually like, being in that position where - all of a sudden, I'm like, "Hey, I want X, Y and Z to happen." And then people look at you.

First of all, it's like this public speaking moment that you're not used to - especially as a really nerdy software person - remember I was a nerd, but trying to hide it. And then you're in this moment where you're like - you've got these people looking at you. Whether it's on screen like this, or in a room. And you're like, "Hey, I want to do X, Y and Z. And the minute you step into that moment, I call these like "leadership moments" - you're actually stepping into this weird new version of yourself. And it can make you very nervous. All of a sudden, it's almost like out-of-body, right? It's almost like you're watching yourself talk to these other people. Once you get used to it, you stop feeling like that. But in the very early days, suddenly you're very self-conscious.

You're like, "What am I saying? Am I saying the right thing?" It's all about you, you, you - right? And so you're not really listening when people - if somebody says, "Well, but, what about this problem? Your design, you said you want to do this design - but what about this, what about that?" And they have their own vested interest, right? And they're trying to - they want to do things their way also. And trying to get that alignment and trying to get people all together, that's what leadership is.

It's crazy, because - to your question earlier about "What is a tech lead?" The tech lead is basically somebody that's been tapped, who was an individual contributor - who has no authority. I couldn't actually make these people do anything. They didn't report to me. And I had to lead through influence, which is actually - if you really read a lot of leadership stuff - influence is the hardest type of leadership. It's an advanced level of leadership.

So we take people with no experience, who probably aren't really used to like getting humans to be aligned and get on track. And then we put them in the spot where they have to actually get everybody to produce a result through - whereas I used to write my own code - now I have to get other people to write code the way I want them to, or the way I think is the right way. It's incredibly hard. And so - yeah, I was terrible. I did all the things you're not supposed to do. I didn't create a safe environment. No one used the word "safe environment" back in those days.

I would just be like, "Do what I tell you to." And if people pushed back, I was like - I would either just badl,y or go and hide and pretend they didn't say that - all these terrible behaviors that are like - I shouldn't say "terrible," but they're just kind of immature. And I was just immature in the role. It got done, ultimately - I think mostly through my own heroics.

I think a lot of tech leads will relate to this point. I'd be like, "Okay, fine - just you build this module, you over here build this module - and then I'll just stitch them together." Which - in other words, I'm up until three in the morning trying to get these things to work together. Even though, had I got the team engaged in the right way, they would've built the right module together and I wouldn't have had to do that. But often, tech leads will take on this heroics role and try to get it done. And that's pretty much what I did. It's a little clunky, a little buggy - but it worked.

Len: And in this context, what is a safe environment, and how did this change come about, where safe environments were something people were self-aware about and talking about?

Michael: That's a really great question. I don't know the answer to it, but I know - I'm glad we're talking about safety. Because, I mean, the short answer is - I think the term really came up from Google. I could be totally wrong about this. But Google did this big organizational study about, "Hey, some of our team's very high-performing, why is that?" And one of the reasons they found was that the teams were safe. So people were free to talk about issues.

I have this alternative view on safety, or where it came from and why it's important. So if you think about, like - what does it mean to feel safe? It means that I have something I want to express. Like I'm an individual contributor, and I want something to happen. And I want to express an idea, but I'm afraid there will be some backlash from that.

I think the idea is to enable people to feel like they can be included in the team. It's an inclusive concept, too. I think the reason why it's particularly hard in software or in technology, is - there's some new work that's really interesting around like emotions, and different - so, you can think about emotions. I can't think of the author's name right now, but it's really good.

But the idea is, you can categorize emotions by blue zone, red zone, yellow zone and green zone. In the blue zone, it's a little bit depressive - that's where things like empathy come from. And it's a little bit sad, but it's also where all your intellectual capabilities come from, too. A lot of software folks or technical folks spend a lot of time in this, what I call "blue zone."

So they're actually a little sad all day. They're a little melancholy, but that's because that's where a lot of their intellectual horsepower's coming from. It's like you need to be able to be pulled out of that mode from time to time, and feel safe. Because, you're a little bit - this is just my theory. But you're a little bit sad as you're writing code all day long. You might get that little, what I call like a dopamine hit, when you solve the problem. And that's what you're working for, all the time. Because you're like, "I got the code to compile." Or, "The test passed." Or, "I shook the feature." And you get those little hits.

But generally, if you walk around the halls of Silicon Valley, you don't see a lot of people smiling or giggling and running around, like you might like on a sales floor. This is a very low-energy environment. I think when you spend a lot of time in that mode, all day long, you can be a little reticent to come up with ideas or talk. I think as a tech lead, or anybody in a leadership role - no matter - even if you're not - even if you're just informally trying to get the team to gel, and be cohesive and successful - you have to make it safe for them. And be like, "Okay let's come out of that mode. Let's have fun. Everybody lighten up a little bit," and then you can go back, so -

Len: And safety can be really hard to achieve in corporate environments particularly. You mentioned waterfall before and bricklaying. This is something that's come up on this podcast many times.

My first introduction to the world of programmers was a conference, actually in Seattle, and it was really - one of the things that I found most striking was how actually really sad and unhappy so many people were. And it was because they were in an environment where they were - their managers were not technical people. But they had been trained in managerial practices, and maybe had a certificate or two. I'm not saying this negatively. That was their career, that was how it was structured, and that was fair and everything. But they treated the programmers as bricklayers, whose work could presumably be measured in some very sort of precise way. And they probably had some arbitrary metrics that they were imposing, on how they were measuring how these programmers were doing.

They were just the most unhappy professionals I've ever met in my life. And what they were doing was extensively creative, and problem solving - but nonetheless the sort of like - to be sort of, to put it in a tacky sense, the sort of corporate gaze didn't see that. Instead it saw just interchangeable hands.

Have you seen that attitude change over the course of your career? Has it gone from being more prevalent to being less prevalent?

Michael: For sure. I mean, for sure. I think, for the most part,it's really good. There was a time in the like late 1990s where there was a company in Phoenix that was hiring really big, because they wanted to build some app. And this is pre- some desktop software or website, I think it was?

And so they just recruited a whole bunch of people, a whole bunch of software developers. I think they paid a premium, because nobody - there wasn't a very good reputation for this company. But they very much treated them - I mean the company was fundamentally a manufacturing company. As a developer, you had to show up at 7:00am. I didn't go work for this company when I heard about it.

You couldn't leave your desk, and you can only take certain breaks. It was like very oppressive like that. And yeah, I mean, there's a big fundamental difference between being able to measure what was like clockwork or piecemeal work, that you might do on a manufacturing floor - and I think even in that world, they're discovering that that's not the right approach.

But, yeah absolutely. I think we're starting to figure it out. But I don't think that it's right to say that a non-technical manager can't manage software engineers. I think it's more about - I think if a truly good manager - and I always complain that we call managers leaders, as if it's interchangeable. I don't think it's interchangeable. I think you can be a really good manager of anything.

If you're a good manager, you could literally manage anything. But you have to be able to invest the time to understand what the people on the ground are doing. So if I were to go work for - manage an In-N-Out Burger - I might be able to do it, but I'd have to spend quite a bit of time understanding how the people on the grill line, or whatever it is, do their work - and what motivates them, and what makes them excited.

And I think - to your point - software engineers, it's a big industry now, so I can't speak for all of them. But a lot of them really get that - what really gets them animated, gets them excited - is solving a problem. Or just fundamentally - you get the code to run, or you ship a feature, or, some of them really enjoy just spending that time on the whiteboard and thinking about, "Hey, what's the best approach here?" I think if you take that away from them, you're just not going to have a very high performing team.

Len: It's interesting. Reading your book was my first introduction to this idea of a blue zone, and then these other colored zones. I'm just imagining probably the red zone is danger. Is that correct?

Michael: So, I mean it's red in the sense that - this is like something, and a lot of this isn't in the book, I want to do it in the next revision of the book. But the idea is, what's really interesting to me lately, or really has my attention right now, is, writing code is a very cortex-heavy activity.

My oldest kid right now is doing math. So I help her with her homework. She's in fourth grade, so they're doing fractions. And to her, it's just this painful exercise in figuring out the right way to do the number. And the reason it's not fun for her, or it doesn't really animate her - is because it's all this activity that’s happening in her cortex, her logical brain. But she hasn't made an emotional connection to it.

I think the reason a lot of software engineers who are really - we use the word, "passion," right? Which is, we'd spend all day talking about - whether that's the right word to use or not - but the idea is, by writing code, you actually have an emotional connection to what that code is. And so when you have oppressive managers who will sever that connection, it messes with you and it takes away the joy in what you're doing.

And then it becomes a strictly logical exercise like, "I don't know, should the button be on the left or right or should we have a -? Should the function look like this, or not look like this?" Pretty soon you just become disengaged and like, "I don't care." Whatever will satisfy the boss is good, and it takes that emotional love out of it. And so to your question about the red zone or blue zone or yellow zone - they're just -

It's fair to have all those emotions, but - and the red zone would be things like your anger, your rage, or you're irritated - or any of those things. Actually, that may be okay, right? Because it means you're engaged. And if you're writing code and somebody is writing code a different way, and it puts you into the red zone, and you're enraged because this person's writing code in a way you disagree with - how you act on that could create a real problem for other people.

But if you just recognize that, "Oh, this is my emotion, right? I'm really mad, because I really love this code." Then that protects your relationship to that code. Now what you have to do is step out and think about, "What's the right way to express that feeling?" Because you don't want to just let your rage loose on somebody, just because they didn't do things the way they did. Because they probably have their own emotional connection, right? And they found a lot of satisfaction, or there's some reason why they did it that way.

I think that's how we create our safe environments, is - first of all, you have to listen to your own emotional feeling about how something feels to you - protect that for yourself, right? Make sure you keep that emotional connection, because that's what's going to keep you excited about your day job. But then on the flip side, understand that that other human is having a similar emotional connection to whatever's happening. I think we just need to do this.

Len: Thank you very much for sharing all that, by the way - it's just fascinating. And so, is creating a safe environment partly involved -? You mentioned - work is a multi-dimensional thing. And so I'm sitting there trying to code something. There might be a very specific logical problem that I need to go through the steps of. But at the same time, I have to have some part of me that's integrated with the system of pleasing my boss.

And so I imagine - I guess part of the thing that I was trying to get at earlier was - if that system of pleasing your boss is not somehow formally linked to the system of producing good code, then you end up with this misalignment. And it can break that connection, between the different dimensions of what I'm doing, if I'm saying that.

Michael: Yeah, that's an interesting thought. I mean it's true. Honestly that's why we talk a lot about pushing leadership down to the people that are closest to the information. And so you can often have a manager - maybe like, more typically - like a couple of layers above, who is like, "Code's got to go out. We've got to ship this product. Got a marketing campaign launching. In 28 days, this thing has to go live - do or die." Because the senior manager is getting comped or paid on the thing being successful, right? And so there's this downward pressure.

But the people on the ground may know this is not do-able. And so - like I said, when - if that management pressure just rolls downhill, then that team feels like they just have to do whatever they have to do to collect a pay check. And if you think about what leadership is - people will do that, and they'll follow you - because they have to, to get the pay check. But it takes all - you're just not going to have a high-performing team. They're just going to do the minimum they need to do to get their pay check and go home.

Len: Speaking of getting your pay check, I'd like to move onto the next part of the interview, where we talk about your latest book. Which is, Professional Services: Day 1, Hour 1: An Introduction to Professional Services in Software Companies. And you write very well, I think, about the role of a consultant, and I think, very effectively go into some of the details of it.

One of the things you talk about is utilization. It's a tough concept to face, and a tough situation to be in - but I was wondering if you could talk a little bit about what utilization means, in the context of being and working in professional services?

Michael: Thank you for that question. Consultants to me are very - it's a very similar - you'll start to notice a theme with the stuff I do. I'm more interested - as I've grown in my career, I'm a little less interested in the technology piece of it, and more interested in the humans that bring it to life. Tech leads are in a very interesting spot, in the sense that they have to do something that's maybe a little unnatural for them - and consultants also.

Consultants often will get into the business because they're very technical, they're very effective. Typically they won't get hired in a consulting role, unless they have some social skill, or you feel comfortable putting them in front of a customer or client. That's not always true, depending on how big it is.

Consultants have a really interesting career arc. Typically consultants - we wouldn't hire consultants in the industry for routine stuff. People usually bring in consultants because of their very unique expertise. Or they can do something that a company can't do on its own. Because - especially here in California, most companies don't want to hire consultants. They want people that are invested in the company, that are doing things.

So if you're coming in as a consultant, you've really got some skill that most people don't have. On top of which - you have some ability to execute and to drive the company in a different way, or get them where they want to be. Now, the reason I say all that, is because utilization is often used as a proxy to understand how effective you've been.

Let me explain what utilization is. So, for people that aren't in the industry - utilization is measured in different ways in different companies, but the most simple way that they typically do it is just to say, "Look, you work here, let's say 2,000 hours. We pay you a salary for 2,000 hours a year," which is - I mean, roughly - let's just say it's 40 hours a week, 50 weeks a year. How many of those 2,000 hours could we actually bill you out for?

So by "bill you out," I mean you're on a customer, you're selling an hour for X number of dollars. How many of those 2,000 hours, your inventory of 2,000 hours, did you actually deliver? You could theoretically be over 100%. You could be like overutilized. And if you think about the economics of how consulting firms work - that's how they make money, is by you billing time.

And so, it can be very much a proxy for saying, "This one consultant is getting used a lot. So that person must have really special expertise, a special ability to execute or impact the customer - that utilization's really awesome. And so we want to use that person a lot more." Whereas if somebody else's utilization is lower, it's a shorthand way of saying, "Well, they only billed 1,000 hours, so maybe they're not the right person for this industry."

But that creates a huge amount of stress as a consultant, right? Because if you think about - it's the crux of where - the book I have is called Day 1, Hour 1. But executing well in that first hour of the first engagement, is when you're thinking, "Am I going to be able to stick around on this project?" So you've got the pressure of the project, the client, the people on the ground, your managers. You have to know all about the technology, you've got to be on the bleeding edge - and then you're worrying about whether you have enough hours to bill.

That makes it sound really dismal. I hope in the book I paint a picture of why it's actually a really great career. But it's this pressure of like, "Oh my God, I have to make myself useful." But if you think about it, if you really step back and think about what that means - in some ways, it's harsh, but it's also how economics works too. And so you want to be relevant and valuable - I think when consultants spend a lot of time thinking about their utilization, it's a proxy for how your career goes.

Like I said - I just returned from Silicon Valley yesterday - and that's a pretty tough environment. If you want to be a software engineer there, this isn't the 1990s anymore - you'd better be really sharp, on your game all the time. And that's how consulting is, so -

Len: And one thing one has to be aware of throughout one's career is - I mentioned the word "gaze" before. But the gaze of your manager upon you, is actually pretty specific in some cases. Where they're like, "This is exactly how many hours this consultant billed. TThis is exactly how much we paid them, and what's the difference between the two?"

But at the same time of course, as you write - even though you can't bill out anybody for speaking at a conference, that increases the value that you can bill yourself out at going forward, and things like that. So it's never like really - or it ought not to be treated as being something as precise as just the simplest way of formulating the metric. But it is something that as a consultant you have to keep in mind - what other people's view is of your utility generally, and that's both your managers and your clients.

One thing I really liked about your book, and you're sort of getting into this a little bit - is that the focus you have on mindsets. This is something that's very important to me, in the way I try and think about the world.

We often try and formulate things in terms of forces, and things like that. But actually every situation a human being is involved in, involves the mindset that they're in, and the mindset that other people are in. Although it seems a bit abstract, it's actually a very powerful way of thinking through situations.

And your book is all about "day one, hour one," and I found it just so fascinating. Like the drama of it is something that might not be apparent to people who are outside it. But the work of a consultant is - Sunday night, you say goodbye to your family and you fly off to another city. It could be many hours away. An example that you give, I think, is - there you are, you suddenly find yourself lying in bed at two in the morning, but it's actually midnight your time. And then you do the work. I've been in this situation myself, where it's like, "Oh wait, hold on. So my first meeting's going to be at this time, at this place." And then you have to back out when you have to get up.

And then you realize, "Oh, that's in like three hours or four hours." And then you're like, "Should I use that time to sleep, or how much of that time should I use to prepare myself for this "day one, hour one" situation - where it's not just about first impressions, it's like - there's going to be a sort of knock-on effect of everything that happens from that first moment. And then you're, "Oh no, am I really up to date on my company's technology, that I'm trying to teach these people about? Oh no, qho's my real point of contact? How am I going to get through security? Is my team going to be all there on time?" And stuff like that.

So, I was wondering if you could just talk a little bit about your approach to preparing for "day one, hour one"? Assuming you've had at least a few hours to get ready before you hop on that plane.

Michael: So "day one, hour one", for people that aren't in the industry, you often have - I highlight that moment, just because it's where everything comes together. So usually before "Day One, Hour One," there's been a lot - especially in professional services for software companies, for consulting firms it can be a little different - but typically it's like a short engagement. Anywhere from like one week to maybe twelve weeks. But there's been a long sales process that led up to it. And then the consultant's done a lot of enablement. Maybe he's rolling off another project? Whatever it is - all your knowledge and all the hopes of the customer, and then really the company you work for - all come to life on that one moment. So it's a ton of pressure to put on any one person.

And to your point, it can color the entire - we call them "engagements" or "projects." It can color the entire engagement. Because if it's a bad first hour, it's going to take a lot of hours after that to recover from it. And so the reason I talk about mindsets, I think it's useful, because there's so much to know - there's so many details to try to keep track of. And your brain, you've already got it crammed full of all this technical stuff. You've tried to cram on the customer to understand what they're trying to do.

And then you've got to - like I said, you've got to worry about logistics, and you've got to get your coffee in the morning on the way. There's so much to have to do, that there's no way you can actually go in there and be like, "Okay, I need to hold my body position the right way." Or, "I need to do this." You can't really focus on tactical things. Because in that moment, you don't know what's going to happen.

Like when you're interviewing. I think for a lot of people, they understand the experience of going to an interview. "Day one, hour one" is very much like an interview, but with like real money behind it. And you're like, "I know I want to see this, and what if this question comes up? This is how I'm going to answer it." You're trying to hold all that stuff in your brain.

But I think really if you just focus on mindsets and like, "What do I want to be?", "Who do I want to be? Who am I?" I think it works better.

The first one I always highlight is service. Coming in with a service mentality. Like, "Look, I'm just here to make you successful." You know what I mean? "I'll do whatever it takes to get you successful. I may not have all the knowledge," and that takes a little pressure off you - "I've got a whole team behind me, I can reach back to help figure out the problems if I can't solve them on the spot. Even if the customers are being difficult, I'm just there to serve them. I'm just there to make them successful." I think if you focus on that mentality, then all the things will come out of it - like listening well, sharing well, getting out of your own head for a while, getting in their head for a bit. I think you're going to do great.

Len: And the second mindset you talk about is focus. I'm wondering if you could talk a little bit about that. What do you mean when you talk about focus?

Michael: I mean a few different things, but I think it's like what I described. So, you've got so much swirling in your head, as you're going through the project. Things like utilization. You're like, "Are they going to keep me on the project? Do they like me or not like me?" I think just focusing on what that customer needs - I think it's probably very similar to how I think about listening for tech leads. Just really get out of my own head - get into their world and focus on what their needs are, and leave all the other stuff behind for a while.

Len: Typically there's a statement of work, or a scope of work as well, that you'll have, that I think you can - you write about how you can use that to - if you're suddenly feeling a little bit at sea, you're like, "Wait a minute - how does this relate to the actual work that was defined and agreed upon at the beginning?" You ask the question, in this "day one, hour one" situation - "What does success from this engagement look like to you?" And you can use these things to bring your focus back.

Michael: Yeah. So for people that haven't seen this, what happens is, typically there's a contract between the customer and the vendor. The contract will have all kinds of terms in it. But most importantly, they'll have a list of things that are going to be done. Sometimes the list is long and detailed, sometimes it's just short and loose. But usually that list has been negotiated for days or weeks before you show up on "day one, hour one".

But what's interesting is, there can often be a big delta in time between the time that the list was written, and the time you show up. So the list that you wrote may be obsolete by the time you show up. So really, in that first hour, just really focusing on the idea of, "Hey folks, I'm here. I've got my service mentality. I'm here to make you successful. What does that mean? I've got this list. Is this list still good? Are we still going to do these things? When I get on the last flight out of here, how are we going to know that I've done a good job, and that you're successful?" I think focusing on those things is the focus I'm talking about.

Len: And the stakes can be really high, specifically with respect to the scope of work or statement of work, where people have negotiated a price, which could be in the millions, for the engagement. And there can - I've been on the other side of it - engaging with consultants, or contacting consultants to get bids on contracts for things like due diligence in a big merger, and stuff like that. And there's legal implications, very significant legal implications. Because if there's a dispute, you go back to that scope about timing or price or something like that. You go back to that scope of work. And so if it's out of alignment when you get started, you have to be able to communicate that misalignment in both directions, both towards your client and towards your management.

Michael: Yeah. I mean, it is a legal contract, right? And that's what the list says. Usually - typically the contracts will have a little - there are different types of contracts. But usually just a straight time and materials contract will often say, "Here's the list of things we'll do, but really, what you're buying is time. And so if we don't get to all those items on the list, then time's out." There are other kinds of contracts that are fixed price. Where it's like, "We're going to accomplish X number of things." So instead of buying time, you're buying scope.

But either way - typically once you get toward the end of the contract, somebody will say, "Oh, I guess we're running out of time. What did that contract say? Did I get all the things that I wanted on here?" So, notwithstanding whatever the contract says, they're going to suddenly pull out those task lists, more often than not. And say, "Oh, we forgot to do a couple of items here." And you may only have a few days or hours left. So always coming back to that task list.

If the task list is wrong, there's processes usually, called a "change request" or something. You can put in something to change the legal terminology, or at least get some writing that says - depending on your company and policies - "What are we -? I know this is what we said we were going to do, but I'm here now - what are we actually going to do?"

Just making sure - usually there's a project manager involved in the project, who can help you with that, but if not, then it's on you to say, "Let's make the list, and let's always keep coming back to that list every day," with the idea that the list is supposed to contribute to an end state, at the end, that made you successful.

Len: Before we go on to talking about your experience as a writer, and I know you blog and you create podcasts as well, and you've written a couple of books. I wanted to talk to you about something that's hopefully a little bit fun.

We often see articles, "Top 10 trips for the busy traveller," or something like that. And I had a period of time in my career when I travelled a great deal. I had to come up with some routines and things like that, to optimize things and to minimize mistakes and things like that. I was wondering if you could talk about, what are some of your tips for the busy traveller? What are the little tricks you have for travelling, and making sure everything goes smoothly?

Michael: It's funny, now that the work has become more and more remote - early in my consulting career, it was like every week. It was like travel, travel, travel. But now, less and less so.

But that said, I mean, it's still enough. One of the things for people that are brand new to it - make sure you get your loyalty program. This is obvious for people who travel a lot, but try to pick an airline and try to stick with it. Because you can get points, right? And they start to give you status. I travelled so little last year, I lost my status. And it's just completely changed the experience of travelling. I just flew into LAX last night.

but definitely, one of the simplest things I do is I actually try to travel - this will not work for a lot of consultants, but I try to travel like really light. I don't even bring a laptop with me anymore - which is like a really crazy thought for a lot of folks. I'll just bring like a Bluetooth keyboard and my phone, and I can get almost everything done that I need to get done. But I know for people who write code for a living, it's not going to work.

The other thing I do is, stuff like toiletries, like deodorant and that stuff, I just always have that packed, and it's ready to go. I have a little travel-sized pack. I think that's super useful.

And then finally, I have a list of all the things I want to make sure I bring. Because invariably, I'll forget something, like a brush. Just have this list that you copy and paste every single time you're going to fly and that you can just eyeball. You're like, "Yep, yep, yep, yep." Because you do it enough, and you develop this memory.

You lay everything out on your bed, and the night before, you're like, "Okay - socks, underwear, undershirt." And you mentally count how many you need for how many days. "I need two undershirts, I need two dress shirts. Got my running shoes." You mentally do it.

But if you have it written down, then you don't have to remember anything. And the less cognitive load you can put on your brain before you're going into "day one, hour one," the better. The last thing you want to be doing is trying to remember what you need to pack.

Len: That's really good, that's really cool. Actually, I use the list method myself, and one of the reasons it was so - again, it's a mindset, and your emotions, that you're actually partially managing with this thing.

I'm a single guy, so that means there's certain risks involved in leaving all of a sudden for a few days. My joke is leaving a banana on the table - and you're like, "Oh dammit." But if you have a list, it's not just the things that you get done. It's being able to - like when you're panicking, when you get into that taxi and you're like, "Wait a minute, I went through the list. I know I did - I don't remember all the things I did, but I know I went through the list. So just calm down."

And actually one of the things about managing mood, just to share - one of the things that I came up with was - for any particular airport, I had a routine that I did at that airport. Like, if I'm in Dulles, I'm going to go to Five Guys. And then I'm going to do this and then I'm going to do that." And like picking a restaurant, and even a specific dish that I would get - and then you could anticipate, "Oh yeah, I'm going to be going there. So I'm going to be having a club sandwich and I'm going to be getting," I don't know? "a mojito," or whatever it was. But having these set things that you do in various places can make you feel more comfortable - and even anticipate something, rather than be nervous or worry about it.

Michael: Yeah. Once you travel enough, you get used to the different airports, and you get your routine right. And depending on how "day one, hour one" went, you may be getting something stronger than a mojito, right? You learn all the little quirks of all the little restaurants, and which ones you like, and what time you need to get there, how long - if you fly through Denver International - anybody who flys through there would be like, "Oh my God, just getting through security is a huge ordeal." Versus Burbank, which is this little tiny regional airport - which is just a breeze. Once you learn all that stuff, then it makes life a lot easier, for sure.

Len: It's funny - you can even get to know people personally, like a maître d' or even a waitress, or something like that. You can be, "Oh great, that one. They're fast and they bring the bill right away," and stuff like that. It's really interesting the things you -

Michael: You could do a whole podcast. Somebody should write a book about travelling and - there was that movie, Up in the Air. So much of that is just so true.

Len: I know, actually I remember I saw that before I travelled a lot. But when I started travelling a lot, I was like, "Oh man, totally. These are the things you think about."

Len: Moving onto the last part of the interview. Tou've written a couple of books on Leanpub, and I know you blog - and I just wanted to ask you a little bit about your writing process. Qhat attracted -? You actually mentioned something previously, but what attracted you to Leanpub, and do you recall how you learned about us?

Michael: Oh gee, I think I knew about Leanpub from - and first of all, I mean it's an amazing service, right? I love it.

Len: Thanks.

Michael: Yeah, it's great. And I think the whole idea of lik -- I think I heard about it, probably when I was just leaving Seattle, and the whole lean movement. And the idea of, "Hey, let's just get something out the door fast." I think it is so useful for writing. Because I think there are a lot of people who would like to write. And they've got some idea about something they want to write. And then - you probably already know what I'm going to say, because you've probably heard the story a million times. But to write is just, you've just got to write and get something out the door.

Legal writing is like a thing, it's like a course. But you can actually go to really advanced levels with it, which I did. Because they say that lawyers are actually the highest-paid professional writers, actually - which is something to think about.

There was this course that was taught by a guy who - qhat he did is, there's a book called, Style. It's like, I think, Style: Lessons in Clarity and Grace. It's not the Strunk and White book, it's a different book, called Style. And I just absolutely love that book.

The idea behind it is that the best writers - and I'm by no means putting myself in the category of best writers, when I say "best writers", because definitely I need a lot of work on those two books - but the best writers are just really good editors.

So the idea is, I think sometimes when you go to write, you read what other people have written, and you're like, "Oh my God, I want to write like that." But what you find out when you really dig under the hood is - they don't write like that. Their first stuff is terrible, right? And so then they go through and they edit it and edit it and edit it. And that's where things really get good.

I love blogging for that reason. Because I can just slam something out there, and then go and revise it over and over again, and Leanpub's just perfect for that. So the idea that I can like - I'd probably be immobilized, I wouldn't even have these two books done, if I had to do it through a traditional service. It just wouldn't even happen, because I would just be paralyzed.

It would be sitting on my computer hard drive somewhere - where I'm like, "Oh yeah, I'll get around to editing it." But once it's out the door, I'm like, "Oh my God, I'm committed, and people are downloading this stuff, and I owe them something good. Now I've got real people reading." I'm like, "I've got to, I want to really improve it for them." Versus having it just sit on my hard drive, and it's only me that cares.

Len: Thanks for sharing that. You honed in right on one of the big motivations behind Leanpub, which is to get your work out there early, and get an audience.

And the excitement and the, I would say, positive pressure of having an audience out there. People are like, "When's the next chapter coming out?" That's the greatest thing - and they're the best - early readers are the best editors. Well, I shouldn't maybe say "the best," but early readers are great editors. Because they'll be like, "I found a typo on page four." And one of the things we enable, is for you to update your manuscript and make that change available within minutes. Which - people love that. They absolutely love seeing a change that, like a typo they've found, be fixed in a book. It establishes this really great connection between the reader and the writer, which is relatively unique to the way we do things.

Rhe last question I always like to ask on this podcast, is: if there was one thing that really bugs you about Leanpub that we could fix for you, or one wish list feature we could build for you, is there anything you can think of, that you would have us do for you?

Michael: I have one little thing, which you may or may not want to keep on the podcast. But I noticed it doesn't work very well on Safari, the editor. It seems to blank out. On Chrome it seems to work really well, but on Safari, it's a little less stable.

Len: Thank you very much for sharing that. We actually haven't had anyone report that. But that's probably because - I mean, one of our internal weaknesses is that we all use Chrome all the time. Tech companies have their little biases like that. We all work on Macs, and things like that. So problems particularly with Safari - and for anyone listening, we actually like to hear about problems with Leanpub, it helps us improve it. Same way that authors like to hear about problems with their books.

This is the first report we've had of it not working so well in Safari. And so we'll definitely set aside a little bit of time for someone to go through it. Because we made a big overhaul of our in-browser editor a while ago, and people are actually like - we're open about the fact that it sucked in the past. But now we've got people writing books that are hundreds of pages long - like actually academic-type books, with lots of footnotes and things like that, and it seems to work really well.

But anywhere that you see Leanpub not working, we want to hear about that. And you can email us at hello@leanpub.com with any problems that you find.

Michael: The other one I would say, before you move on, is, and maybe you've heard this before? I didn't hear it on any of the other podcasts, but - so, I come from an open source background. My prior company was Red Hat. And one of the things that I think would be super interesting, but I don't know - you'd have to make it pretty lightweight - is the idea of - what if, as a writer - I write something - like this, like professional services or tech lead? A lot of people have their own point of view on this.

And so, it would be cool for me to open it up to say, "Hey, if other people have contributions they want to send into me - besides just like, 'Hey, here's an email, here's an idea,'" But actually make a change - like on GitHub. The whole world's getting used to this collaborative development cycle. It'd be cool if you could have some way of doing that. Or if nothing else, some GitHub hook or something. I think a lot of your technical writers would really appreciate that.

Len: Thanks for that, yeah we have heard that from authors before, I think. And like we've actually - because so many of our authors are programmers and creative people, we've actually had one or two people build their own little systems like that. And I don't say "little" to be demeaning or anything like that - just simple things that you can do in a night.

We do have a GitHub writing mode, I should mention. So if you're writing your book in GitHub writing mode, then anybody can do a PR, and contribute to your book, and then you can sort of approve or reject that, and add it to your book.

And we have a Bitbucket writing mode as well. We also have a Dropbox writing mode, and Dropbox has variouscollaboration features as well.

We even had a Google Docs writing mode for a while, but it proved too difficult to be reliant on a third party like that, in order to troubleshoot problems that people would have.

But collaboration is very important to us, and yes it is completely missing - well, almost completely missing from our in-browser editor. In order to collaborate with someone using our in-browser editor, you would actually need to invite them to be a co-author on your book.

And that's not something that even the contributor would necessarily want, if they're just like, "Here's a paragraph," or, "Here's some typo corrections," or something like that.

We also do have - I should mention, we also have forums. So, once your book's been published, you can create a forum and people can - it's based on the platform Discourse, and people can contribute that way.

But that is definitely something that we should think about. Because we do know know how important collaboration is. And making that interaction between authors and readers as friction-free and effective as possible is really important. So that's definitely something that we'll think about going forward.

Michael: Or maybe GitHub Issues, right? You know the Issue thing? That might be good for non-technical readers, right? Like, "Oh yeah, there's an issue with your book. Here it is."

Len: Yeah, we've actually - I was interviewing someone recently who, that's the way - even though their book wasn't in GitHub mode, they actually set up a GitHub repository in order to use GitHub Issues - in order to log issues with their book.

We've got some pretty creative, tech savvy authors, nd they're finding their own solutions in the background, to this very problem. And it is definitely something that we could do them a service with, by building something ourselves.

Well, thank you very much, Michael, for taking the time to do this podcast. I really enjoyed it, and I really enjoyed reading your books - and I would definitely recommend them to anyone. Even if you're not a consultant, if you want to understand - if you're on the other side of things, if you want to understand the challenges that consultants face, reading Michael's book, Professional Services: Day 1, Hour 1 that would be a really, really good thing to do. I would highly recommend it.

Michael: Great, thank you for having me. It's great, it's been fun.

Len: Thanks.

And as always, thanks to you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review it wherever you found it, and if you'd like to be a Leanpub author, please visit our website at leanpub.com.