In this Episode
Jim Holmes is the author of the Leanpub book The Leadership Journey: Practical tips on starting or changing your leadership journey. In this interview, Leanpub co-founder Len Epp talks with Jim about his background, Air Force boot camp and his experience in the military, his varied career in IT, his book, and at the end, they talk a little bit about Jim's experience as a self-published author.
This interview was recorded on December 21, 2017.
This interview has been edited for conciseness and clarity.
A Note About the Leanpub Frontmatter Podcast
This summer we split the old Leanpub podcast into two distinct podcasts:
Frontmatter, which is a general interest podcast where you can listen to Leanpub authors talk with Leanpub co-founder Len Epp about their books and their areas of expertise, from data science to molecular biology, to the history of labor and management. And for those interested in the nitty-gritty of what it takes to be a successful self-published author, at the end of each episode Len asks the author about how they made their book and how they are spreading the word, and other publishing shop talk.
Backmatter, a new podcast focused specifically on the publishing industry and its latest trends. In each episode Len interviews a professional from the publishing world about their background and their insider's perspective on what's happening in the huge and evolving world of book publishing.
A Leanpub Frontmatter Podcast Interview with Jim Holmes, Author of The Leadership Journey: Practical tips on starting or changing your leadership journey
Len: Hi, I'm Len Epp from Leanpub, and in this Leanpub Frontmatter Podcast, I'll be interviewing Jim Holmes.
Based in Oregon, Jim is an Executive Consultant with Pillar Technology, a high tech consulting company. He's also the owner and principal at Guidepost Systems. He has had many roles in IT over his career, including managing teams and working with organizations from start-ups to very large enterprises.
Jim's the author of the Leanpub book The Leadership Journey: Practical tips on starting or changing your leadership journey. The book contains practical tips, stories and exercises for developing your leadership skills, based on Jim's experience in a lot of different areas of work, from the military to the Cub Scouts. It also includes the Leadership 101 series from his blog.
In this interview, we're going to talk about Jim's background and career, professional interests, his book, and a little bit about his experience writing and self-publishing. So thank you Jim for being on the Frontmatter Podcast.
Jim: Thank for having me.
Len: I always like to start these interviews by asking people a little bit about their origin story in life. I was wondering if you could talk a little bit about where you grew up and how you made your way into the Air Force?
Jim: I grew up in rural California. I'm an old fart, I was born in '63. I am the living example that you can screw up a whole bunch and still come out pretty well. I went to bad California country schools. I liked 5th grade so much I did it twice. And I went into the Air Force because my junior and senior year in high school, I had friends that were years ahead of me - because of being held back one year.
And so I'm going to college. They were changing majors, they didn't know what they wanted to do. We were broke farmers, so I didn't have a free ride. I couldn't imagine going to school and incurring, at that time, an ungodly amount of debt, like - oh my God, $30,000 or something, with not really knowing what to do.
My dad was a private pilot, and he'd had me up flying since I was probably four years old. I loved airplanes. I wore glasses - my eyesight isn't great, so I couldn't become a pilot. Also, that required college.
So I went into the Air Force, and ended up, through a whole bunch of lucky circumstances, getting to fly on E-3 radar aircraft. I ran computer systems relating to the radar systems. And so here was this kind of ignorant California hillbilly kid getting to fly on big neat planes, and do a lot of really high-tech stuff. I got a whole bunch of really amazing leadership schooling through the service.
Eleven years after I was in, I met a woman who was amazing, and fell in love. She happened to be an officer. I was enlisted. That didn't work out so well, so I left the military, and then spent the next, I don't know, fifteen or so years following her around until she finished her career. I took pretty much whatever oddball IT jobs I could get, because we were living in places like backwoods Germany. We were in the DC area for a while, while she was at the Pentagon.
I hit a bunch of different IT jobs, from network management to help desk work. I did some software engineering. And then just gradually, over time, I evolved into doing much more of a consulting type role. So I've always been interested in testing and quality, even when I didn't really know what that was. I'm not the hard core software engineer, but rather I'm more interested in people, communication. Helping solve those difficulties.
Through that background, kind of by accident, not by purpose, I've done a lot of leadership roles. From high school sports - I played a lot of years of very serious competitive volleyball, coached some of those teams; I was a Cub Scout leader for a while. I helped run the CodeMash Conference, which some folks in IT may be familiar with? It started out with 220 attendees, it's now like 2,500 attendees with a million-dollar budget. I got all of these really interesting, hard knock experiences. A lot of really good insights and lessons learned on leading teams.
Len: On the subject of hard-knock experiences, one of the questions I was looking forward to asking you was about basic training. One of the reasons I'm so interested is that in film, basic training scenes are well known in the genre of war movies. But I don't think I've ever seen a movie with Air Force basic training. And so I don't have any stereotypes or images in my head about what Air Force basic training is like. I was wondering if you could talk a little bit about that?
Jim: Air Force training, at least in the US Air Force, is much different than what I've heard from friends that I've had who went through the Navy or the Army. Or the Marines, which is very extreme.
Basic training by it's very nature and it's need, is meant to really break you down and rebuild you, to fit a military mould. I don't mean this in a badly stereotypical way. Rather, they've got a very short time to impress upon you that things you do very well can lead to other people dying if you're not taking care of things in a good manner.
As with all basic training, this is not about making you a thoughtless android. Instead, it is getting you to understand, to work under pressure, to work a little bit under sleep deprivation, but think, and fall into a successful direction. You're under pressure, you have to make a snap decision. Part of what basic training starts, is getting you into a pattern of falling into success.
So yes, there was plenty of yelling and a lot of discipline. Nowhere near as harsh as what I've heard friends who were Marines talk about. Thinking, discipline and learning to deal with pressure.
Len: It's interesting, the part about thinking is, I think, something that a lot of people don't know is so important in military training. I'm not at all speaking from personal experience, but just from anecdotal experience, I once knew a guy who was going into training for the Australian SAS, and one of the challenges that was at least rumoured that you would have to face, was that you would have to walk across the desert for two days, and then sit down and write an essay. What they were testing was not mere endurance, but your ability to stay focused, even when your body is depleted of resources.
Jim: Particularly with Special Forces, and oh my God - the Australian SAS, the British SAS - I actually knew a fellow who's a trooper in the SAS, the Brits - the US Special Forces, they push your body beyond the breaking point. And yet you're still expected to- I mean this is the requirement, right? - you've got to be able to think in conditions that 99% of people don't understand.
I don't want to draw a close parallel, but in a similar bent, I was responsible for running radar on this surveillance plane. And we were in the Middle East during the first Iran/Iraq war. Not the Iraq war, but years and years ago when Iran and Iraq were fighting.
We'd be up for hours and hours and hours. Tremendously long missions. Tired, you're worn out, you've been away from home for 30, 60 days or whatever. Stuff breaks. And if you can't think in that stressful environment with everything else behind it, the likelihood is that good people can die because you couldn't see what the bad people were doing.
A lot of people just don't understand that. Sure there are spots in the military where they just want the mindless automaton. But that's a very, very rare thing. The military needs smart, capable people who can think in extraordinary situations. And that's every branch. And they're training, not just leadership training, but training for you as a soldier, you as a Marine, you as a sailor - whatever. It teally tries to hit that hard.
Keep in context that I've now been out of military since 1993. But there's some things that are timeless.
Len: I wanted to ask you about the specific job you had. I believe you were both operating radar, and one of the things, as you just invoked - you were responsible for fixing things if they broke while you're in the air on an operation. In particular you wrote about an example in your book where you were 20 years old, or something like that, and suddenly realised you were single point of failure for at-risk ships in the Persian Gulf.
Because in your giant radar plane - that's how technical I am in military matters - one thing you were looking for was these little attack boats, maybe even big attack boats or just any threats to shipping and other boats that were going through the Gulf.
Jim: Absolutely. 20 years old. I grew up working for my dad and my brother, working in tomato and rice fields. I worked in a hardware shop. And here I am in - let's say I graduated in '82 - in 1983, 18 months after graduation from high school, I'm the single point of failure on one of those aircraft. Maybe it was two years after graduation? Point being, when most kids are trying to figure out, "What am I doing for my next job? What am I? Oh my God, I missed yet another class at college," young kids in the military have huge responsibilities thrown on their shoulder. And they succeed. It's extraordinary.
Len: It's just amazing, the pressure, in so many ways, as I understand it, that you're asked to live up to. And you eventually went and got a computer science degree towards the end of your time in the Air Force, if I'm correct?
Jim: It wasn't computer science, I can't overplay it. I stayed away computer science, because it required math. And if you remember that thing about doing 5th grade twice, I've never been great with math. I've got a management information systems degree, and in no small part I did that because the school that offered that had night school classes, and they were eight week semesters. And with me being on the road all the time, the eight week terms actually worked really well. It also got me on the business side of things. So it wasn't hard-core computer science, I didn't learn any programming.
Len: In your work you've managed teams of programmers and testers many, many times I imagine. What proportion would you say of the people that you've worked with had formal four-year university computer science degrees? And has it changed over time?
Jim: So that's interesting. So let's see, I've been working on software teams since - I've never had anybody ask me this in this kind of context. So this is a good question. Let's see, I came back to the US in '98, and that's really when I started working with software teams. The first couple of places I worked at were very heavy R&D. There was one awesome lady with a math doctorate that was doing all of this tremendous stuff. So early on, it was very much skewed toward the CS side, but that was sort of the domain that I was in.
Also, one of the best guys that we had for solving problems actually had a master's in philosophy, and no software courses at all. You didn't want him anywhere near or around the release process, because he was horribly disciplined. But he was amazing at communication. He was amazing at problem solving.
Now let me think about for like the last 15 or so years. I want to say half to two-thirds. I do think it's changing a bit, because I think the industry is starting to realize that for the majority of software work, you don't need that hard-core CS degree. How many people work on compilers? How many people are working on spectrographs that go on a satellite? That hard core engineering is a significant but a small piece of pie. The majority is, can we write yet another business end-to-end solution? Can I stand up a shopping cart system?
And that's much more about communication with what the customer really needs, not rocket science. I think there's been a lot of realization in the industry that we can do things like get kids through some of the dev boot camps that are available. And so you go out, and the better ones - and honest to God, not this eight weeks or four weeks - throw you through something, and then you can't really do much. Good dev boot camps will be three to four months. They'll have internships. And those are skill based, versus that hard-core engineering knowledge base.
I think that's a terrific thing, because decades later, I still can't imagine going through college and coming out with an $80,000, $120,000 debt, and then having to go pay that off. So little of that's directly applicable to what the vast majority of people are doing.
I'm not saying the vast majority of people are doing uninteresting work that doesn't require technical smarts. Rather, I'm talking about that hard-core computer science of, "How are we going to optimize the byte code instruction set?" I don't know, I don't care, I haven't had to do something like that in 35 years. It's a long answer, but there you go.
Len: Because so many of the the authors that I interview, work and have had careers in the software industry, one of the things that I like to ask them about, is, if you were starting out now, would you do a computer science degree again, or would you recommend it to someone? Of the people I've interviewed who've done full computer science degrees, I would say about half say - and they qualified their statements, in many of the ways you did - they say, "It's less and less of a requirement for having a successful career."
One of the qualifications though, and you gestured in this direction, is, if there are certain areas you want to go into, then it actually still is pretty much mostly a requirement. As I've been told, if you want to work for giant corporations, like the Facebooks or the Googles or something like that, it often really helps you if you want to get into organizations like that, to have done a full degree.
Jim: I'd say yes and no. I know a number of folks that work for Facebook. I know some folks that work for Google. And I've got a lot of friends who are doing very deep technical things at Microsoft. I'd say it's less about the organization than the role or the team or the product line or whatever that you're looking to do at that organisation.
For example, I have a friend that I've known for years. He was one of the first people to deep-dive into the F# programming language. He knew the ins and outs of how F# worked, and had just extraordinary experience in the functional programming domain.
F# is a functional language which you may or may not know of, your listeners may not know of. Let's just say it's a very specialized language in a specialized domain. And this guy killed it. He was given amazing talks, he was solving problems. And the F# team at Microsoft wouldn't talk to him, because he didn't have a master's in computer science. He had a master's in music. And it just killed me when he told me he got rejected. Because if there was anybody that they should've had on their team, it was this guy. He was passionate, he'd been using it, right?
So there are still places where you do need those hard-core engineering degrees. And not just to check a box.
So, this is the second place we've lived in Ashland. The first house that I was in, we had amazing neighbours. One guy works with ion propulsion. He's a rocket scientist, he's even got a t-shirt. And there was another guy who was on the team that wrote the software that was on the Rosetta probe that hit that comet some years ago. I was like, "Holy crap, these are smart people."
If you're in something like that, yes you've got to have that hard core. Let's say you just go into something like I did - MIS. And then later on you decide, "You know what? I really want to get into NASA." Or I do want to be an honest to God, rocket scientist. Then you can go get a master's. Or you can get that critical engineering stuff later. And you may find out that your experience actually helps with that.
Len: I think a lot of people listening are sometimes looking to make career changes and trying to decide what the right thing is to do. And all this information is really useful - from the inside, because it's the kind of thing you can't get unless you hear from people who have a network and experience like you have.
I wanted to ask you - you worked for Northrop Grumman. We were talking about big organizations. I wanted to ask you, just what was it like working for a giant defence company? Did you feel like a cog in a wheel?
Jim: Very much so. I'll tell the bad stuff first, and then the good stuff.
They are the reason that I left the very lucrative defence industry. I spent more time getting chased down for tenths-of-an-hour discrepancies on my time card than I did actually talking to customers and solving problems. That's a bit of an exaggeration, but not all that much. I think at the time they were 80,000 or 100,000 people strong. Just in the US.
I was doing something at that time that I was actually very passionate about, because it tied directly back to the job I did when I was in the military, which was flying on radar aircraft. I had a stack literally feet high, maybe three feet high, of technical manuals. I was working on a project there that was going to digitize those and put them on laptops. And so this was 20 years ago, and that was cutting edge.
The work was really important, but the environment was just really tough. The way that the government works with defence contractors, I had an entire year where I didn't know if I was going to have a job, two weeks out. So for an entire year, every two weeks it was like, "Do I still have a job? I don't know? They haven't signed the contract yet. Oh they signed the contract, but only for a month." And then at the end of next month -
Those big faceless organisations in the DoD space get to be very tough. I have some friends at Google. That's another big organization. Facebook, I've got some pals that have worked there. There's aspects of that that do tend to be faceless, just because of the size. But the cultures are much different for both of those particular companies.
Len: Speaking of size, that reminds me, I heard a story from a former colleague about how in a previous career, he had been working on some kind of solution, and he had connections within a giant American defence company. I don't know which one it was. And he proved that his solution would save the company 60 million dollars a year, and somehow managed to get a meeting with the CEO, to tell him, "I've got a solution that'll save you 60 million dollars a year."
And the CEO realizes after about two minutes in that there's only 60 million dollars at stake, and he very politely says, "This sounds like a very good idea. I'm not sure how you got this meeting. I don't deal with anything that has less than 100 million dollars at stake." I've worked in areas where there's lots of money at stake, so I'm kind of familiar with that to some extent. But I think to a normal person, 60 million dollars just sounds like a lot. But in that world, it's not.
Jim: Yeah. And not only the size of money. My wife worked in the Pentagon and handled budgeting for huge programs, small programs. It's not just, "Oh it'll save us 60 million dollars, but, it's going to take us three years to get policies changed to be able to enact this. It was all of that sort of stuff that just, even though at the time I was working on a project that was going to benefit younger me, kids that were doing my job, that I'd suffered through. It ground me down so much.
Plus there some other life changes. I had kids, I needed to be home, because my wife was travelling a lot while she was in the military. It was just time for a change. It took me a lot of years to get back to the same salary level. And I've never regretted that. Never regretted it.
Len: You mentioned earlier, the CodeMash Conference. I learned about that when I interviewed Corey Haines a while ago, and I was wondering if you could talk a little bit about that experience? About starting a conference, and then running it? How did you come up with the idea?
Jim: I didn't come up with the idea. I was president of the Board for CodeMash for eight or nine years. The idea came from five or so guys who were having dinner in Seattle. I'm probably going to forget somebody here, but it was Brian Prince, Chris Judd, Jason Gilmore, Drew Robbins. Maybe it was just those four? And all of those guys were from different domains. Chris was Java. Jason Gilmore is PHP. Drew was a Microsoft guy. And Brian, at the time, was just kind of this polyglot person.
And the heartland of America - like Michigan, Ohio, little bit of Indiana, Kentucky, that belt there, had a tremendous, tight developer community. Literally in 2006, 2007, you could hit a community-organized conference - a code camp or day of .NET or something - you could hit one of those conferences in that corridor once a month, if not twice a month. It was extraordinary. And there was this pack of people that would just kind of go up and down, up and down, hitting all those conferences. Attending, speaking, hanging out. But they were all very segmented. Like it was a .NET conference, "Oh we've got a Ruby get out."
I helped put on a code camp in Cincinnati and Dayton, and we had like three Ruby sessions. And people freaked out.
So these guys are hanging out in Seattle. They're all good friends, and they say, "Why don't we just do a conference that starts from the beginning of bringing all of these disparate technologies together? Because we're all solving similar problems, but in different ways."
And that was the whole point, was to really try to get some of the sniping between Ruby and .NET and Python or whatever, "Just leave that baggage outside. Come, hang out, have a drink, have a glass of water, whatever, and talk about how you solve problems, because that's the harder point. Nobody's doing rocket science, they're all over at NASA."
So those folks, that core four grabbed me, grabbed another guy, Josh Holmes, grabbed a couple of other folks who'd been involved in organizing some of those smaller conferences. And they said, "Hey, we've got this idea." And so we kind of took off. I think I got nominated as president of the Board because I was the phone call meeting Nazi. We were having long meetings, and I finally said, "No, a half hour - here's this, I'm going to run it." And so we got this tiny group, fewer than ten, to organize this conference.
And the first year it was about 220, 240 people, including the speakers. And that core that I talked about, that would go up and down the heartland, that was probably 50% or 60% of the conference. It was this chance to come hang out with all your buddies, finally, and just not have to worry about running off to different sessions. Rather, it was more about the discussions with sessions. And CodeMash, I think, 12 years later now, still has this extraordinary culture that, frankly, I've yet to see duplicated at any conference I've been to.
I'm not trying to brag, but I've been around the globe, spoken at a bunch of different places, been in a bunch of different places. CodeMash's culture is by far unique. I firmly believe that it's because it started from that core of friends who were respectful - vehement about disagreeing, but wanting to discuss things, hug it out. That core set the tone for the first couple of years. Other people had come in, saw how that core was behaving. Then they became part of the core. And it just grew, kind of like the Andromeda Strain.
It also helped that we found this awesome venue in Sandusky, Ohio. Which is on the shore of a Great Lake. It's the first or second week in January. There's a lot of snow all over the place. But it's this indoor water park, it's this kind of Disney-Africa theme. The staff at the Kalahari Lodge, has been central to the success of CodeMash. They've built new facilities, we filled those up. They built newer facilities. We filled those up.
So that growth from year to year to year to year, was just really extraordinary. And totally due to that culture. "What can I go learn from somebody who doesn't do anything in the same editor that I do, or the same platform?" It's an extraordinary conference.
Len: Congratulations on the success of the conference. When you mentioned the facility, it reminded me that I interviewed Jason Gilmore like three years ago, and we talked about that. So that would've been when I would've first learned about CodeMash. I'll put a link in the transcription, so people can see that side of the story. It is really interesting how things that come from a core group of people who know each other, and have a sort of clear mission, how those things can grow over time.
You co-authored a book a few years ago called, Windows Developer Power Tools that was published by O'Reilly. I wanted to ask you about that process. What was it like working with a publisher?
Jim: That was a crazy book. So at the time, I had left Northrop Grumman so that I could be home with my daughter, who was two or three at the time. No wait a minute. We'd just had our son. So I had a five-year-old and a one-year-old. I was at home taking care of them until my wife retired. My co-author, James Avery, had already written one or two books for O'Reilly.
He and I were both tool nuts. We would ping each other on IM, "Hey, I found this awesome little utility that does like this one little thing." Or, "Hey, you're an idiot. Here's this much better thing that does this one thing way better." And he had this idea of doing a book around all of these tools that people use on the Windows platform when they're doing development. They'd been writing about Linux and UNIX tools, but there hadn't really been sort of anything similar on the Windows platform.
So I agreed to co-author. I was out of work at the time, so I took on the majority of the editing work, and knew that going in, because it just worked. James had the contacts, he had the history at O'Reilly. O'Reilly had a bunch of great people that were very engaging, very helpful.
I don't know if you looked much at the book at all. It is basically 140 or 150 articles on individual tools. The book turned out to be almost 15,000 pages in length, because James and I had a total lack of self-control.
Jim: When it came to whittling down to something manageable, we did it in a very lean program management fashion. Basically, the chapters were sort of thematic, like unit testing books, software books, tools, software quality tools, editors, frameworks, et. And we organized those in risk flow versus chapter one, chapter two, chapter three. The unit testing thing was going to be the biggest one. And there was a bunch of churn at that moment. So that's the one that we bit off first.
It was also very unique in that probably 70% of 70% of those 140, 150 tools - the articles were actually authored by the tools' creators. We didn't do any commercial tools. It was all free, public domain, open source. We reached out to the tool creators, the tool owners, and asked if they'd write five, ten pages on something. James and I saved some things that we were really passionate about, to write ourselves. And then it was this huge exercise of herding cats.
So we'd be working through those chapters, based on that risk flow. We'd be sending out all kinds of communications to people we're trying to get on tap. Getting their first drafts in. I ended up doing a whole lot of the editing. Again, because I had time. And James did a lot of work too, we'd partition things off. We had a great editor who was a very stoic guy who got the crazy flow that we were doing. We seemed disorganized from the outside, because things didn't make linear sense.
But we were great at doing almost like this Kanban workflow of, "Here's all the stuff that's got to happen." We'd throw it to this editor. And within the space of about a month, maybe even two weeks, he was like, "Okay, I thought you guys were crazy. You're still crazy, but this is working." And he just jumped all in, our senior editor - not the copy editor, the senior editor was providing great feedback. So we got really nice help on the process for production.
The thing with publishers is, they actually don't do a whole lot of marketing of the book. That was a surprise to me. They had some things, they had some articles and they put things out at sites. And then they'd have our books at various conferences that they'd go to. But I thought we'd be like on Oprah or something. "Here's Jim's and James." And it just didn't work out that way. I had no hard feelings about that. It was just, I hadn't thought any other way.
But we got tremendous support from them. Their tooling was a little tough. We had this really cranky template that plugged into Word. That was really frustrating to use. The style guide was a little difficult. So some of the mechanics were difficult. But again, this was 2006 ish, so a different landscape.
Having done my book through - well, now I'm on three books with Leanpub - I enjoy that process much more, because I control everything. The tool chain's really nice. Having somebody have an editor for me was really cool, especially when we got that guy who just jumped all in. He made the book so much better. But you can find other editors, right?
Len: I've always heard good things about the people at O'Reilly and authors who work with them.
Jim: I've still got good friends there.
Len: And often when people do get critical, it's pretty process-oriented stuff. It's the tools that we didn't like, or just something about the organization's way of doing things, rather than obviously any individuals, or anything like that.
Len: The marketing thing is very interesting. I was at a big publishers' conference in New York a few years ago, and there was a famous guy there who was giving a talk. It was like the one talk on self-publishing. He said he's got like a million followers on Twitter or something like that, and he says, "Look, so I had this idea for a book, and I took it to my publisher. And the publisher said, 'Great, how are you going to use your platform to market the book?'"
And he said, "What are you going to do?" And they said, "Well what are you going to do?" And then he said something along the lines of, "That's the last time I'm going to give a book to a publisher, because of course they can help you with production and stuff like that, but if they're not going to do any of the marketing, you're self-something anyway, in addition to the writing. Why give up all these rights and all these freedoms and literal money, when the money that's going to be made is going to come from the marketing effort that you're personally going to do?
Jim: You said you talked to Jason Gilmore. And he, at CodeMash, for probably four years, if not longer, we had him do a half-day workshop on self-publishing. He's just - he's brilliant at it. He's got this great formula, this process. And he's echoes exactly what you just said: "Why do I want to give all this up, when I end up doing all the work, and now I can do it better?"
Len: You're reminding me of that interview from a while ago. One thing too is that Jason had some insider's experience at publishing companies, and knew about the the dollars and cents that people are really making, and stuff like that. That was a very instructive talk for me.
Regarding your book, on the subject of leadership - I gathered from stuff I read that you're critical of the way you see corporations grooming future leaders? Is that true?
Jim: Let me slightly rephrase that. I'm critical of the way that they don't groom them. I don't think - and this isn't just the IT - I mean, this is epidemic in IT, in software, we just do this atrocious job of mentoring and growing people. But I've seen a moderate amount of different domains, defence, some exposure in retail, software and a bunch of different things. And software as being consultants to clients, in things from ag business to whatever.
I just don't see people being paid attention to, to show them how to become leaders. They'll just be thrown into a position, and then sink or swim. Some of it's neglect, some of it's fear, some of it's ignorance: not knowing how. Because that person who's asked somebody below them to step up a level, they themselves were never brought up well in the leadership role.
So that's my gripe. It's not just big, huge corporations. It's the culture across the board.
I'm not a huge fan of unions - I'll save that for a different rant - but one thing that well done unions have, is that whole guild thing. Apprentice, journeymen. So there's some notion at least of career progression. It may not be leadership. But at least it's a structure of - look, we're going to help you improve yourself. And then hopefully there might be a little leadership sprinkled in there. So my problem in general with business is that they just don't pay attention or care to take the time, or are too busy to improve.
Len: I'd like to ask you about your opinion about something that's come up on this podcast a bunch of times, which is: Is someone with zero domain expertise capable of being a great leader in IT specifically? The origin of this question for me came from an article about Brian Williams from NBC, and there was a story, I think NBC had been bought. I'm totally blanking on who bought it. [Note: It was Comcast - eds.] But some giant company bought NBC, and the way you got ahead was not by being good in the area that you were in charge of.
And there was actually even - there was an article in Vanity Fair about this, where someone was quoted saying that basically management had the view that you shouldn't have any domain specific expertise at all, in order to be a leader of a division. And while I can see see the reasoning behind it, at the same time, particularly with software and things like that, I've run into quite a few people who have said, "You do have to know quite a bit about how the things actually run, in order to be able to lead in that specific area." Jim: I'll say yes and no. Mostly no. I've been for the last 10 or 15 years pretty much specializing in test automation and testing. For example when I'm working with somebody to test a web service, I have no idea how to build the code that will actually invoke or call that web service. What I do know is I can go grab one of my teammates that knows that particular skill or technology very well. And then I will use my expertise in, "Well what happens if we send this malformed thing? What happens if we don't authenticate? Here's how it's supposed to behave; does it?"
Let's take that up a level then to leadership. I don't think that you need the specifics of the technology in depth. I think what you need to be able to do is understand who on your team should be the experts in the various bits and pieces. Who's the database person? Who's the web services person? I need them to work together with this third person who's going to grow to be the bridge of all of that.
Everybody should know a little bit about everything. Whether you want to call it T-shape, generalizing specialists, specializing generalists - whatever. You as a leader don't have to be an expert. What you have to be awesome at is getting roadblocks out of the way of the team. You have to be an expert getting those technical people, the software delivery people lose the grumpy, developer attitude, the grumpy tester attitude, and actually talk to the business people, the suits. Or whomever. And you have to get the suits to lose the attitude of, "Oh well, we're just going to throw pizza under the door of these people."
When leading a technical team, technical exposure always helps. Saying that someone shouldn't know the domain, I have a hard time understanding the mindset and the culture behind that. My initial reaction is, "That's bleeping stupid." But I don't know enough about that situation, or kind of the bigger context there. I think understanding the domain, be it technical or being it business, is really, really helpful, but is not critical.
When I've led teams of testers and developers and other folks, I'm viewing my role as, What's causing you problems today? Where do you need information? What conversations can I facilitate? Am I making sure that you've got enough time to do your job well, plus learn while we're trying to do everything?
Len: That leads me to my next question actually. I think it's related to what you say about imposter syndrome. Let's say you've been working in an area, and then you get elevated to a leadership or management position.
Two things happen. One is that you are in a new area, if you've never led anything before, you can feel like, How do I know how to do this leadership thing? And at the same time, you start losing that on-the-ground knowledge. Because you're not doing the coding every day anymore. So you can get in this double-imposter kind of thing.
I was wondering what you have to say to people who might have imposter syndrome themselves, or might be concerned about what they would experience if they were promoted?
Jim: I saw a tweet from somebody, and unfortunately I can't remember who it was. It pretty much sums up my feeling of my own imposter syndrome. "My imposter syndrome isn't as good as anybody else's."
Rhat fear is a very primal, instinctive thing. I mean that's core to who we are as humans. The vast majority, 99.99% of us all the way out as far as you want to go, want to do a good job. There are very few people that just don't want to work or are deeply angry and whatever. Most people want to do a good job.
So you get comfortable. You get a level of competence built up. That builds confidence. This is one of the things about the military. You start with small, and they get you in the habit of success. So that means knowing what to do, and learning to adapt. You get confidentabout your competence.
And then you're thrown into a new area, and all of your reference is gone. So if you're in an environment that's not supportive, meaning, "We know you're going to be over there, and it's going to take you a little while, but it's going to be okay, don't worry, you're smart" - valuing you as a person, rather than your resume checklist.
That's tough to deal with. All of your safety nets feel like they're gone. And if it's just you - if it's not a supportive culture, then you've really got to take a step back and you've got to find somebody to help you take that break and say, "It'll be okay. Look, remember where you were two years ago, you felt the same way until you learned X." Whatever X was. "But you learned it, and you killed it. You kicked arse on X. Now I need you to do orangutan. And you don't know orangutan. But look, you learned how to do X. So you learned to learn."
Tying back to that other question about organizations not doing well with grooming leaders - it's the same thing. "I need you to do something new, and I understand this is totally unknown. But look, you figured this out. I'm asking you to do this. I don't know how to do this, but I'll help you figure it out with what you need." That's not easy when it's you. Maybe you're at a new job? Maybe you got a new boss? And maybe you're not sure of all of this cultural stuff.
We don't do well at taking a step back and taking a breath, and saying, "I've been here before. I figured it out. It's going to suck. My stomach's going to hurt a while, but I'll get through it." That's hard stuff to do. If you don't have somebody, somewhere who just says, "I get it. You feel like you suck. You don't, but it'll be okay."
Len: Speaking of hard stuff to do, you write in your book about giving bad news. And your advice is that as a good leader, you should give bad news in person. I was struck by the particular examples you gave, where you and other people learned about staffing decisions from PowerPoint presentations. You have one example of someone who learned about their own demotion in a PowerPoint presentation that I imagine was probably being presented to a group.
Jim: Dilbert is a hit because Dilbert hits home to a lot of people. Sadly too many of us have been in those positions. I was aghast both times that happened.
The first time it happened, the guy who was getting demoted and saw it there. We weren't on great terms, but we weren't on bad terms. We just weren't all that close. But I'm turning in my chair and just looking at this concrete statue. Because he had no clue how to react. I cannot imagine ever sharing that kind of news any way but face to face.
That goes all the way back to how I was brought up as a kid, just about treating other people as humans. When I hear about that stuff, when I read it - dear God - when I have to be in the middle of it, it's just appalling.
Len: I've often wondered what people are thinking when they're doing things like that. Do they think that they're just being a hard ass and then this person is going to come back more motivated to try and work harder? Because I think that - at least it's my opinion that there's more to it than just being hard ass when you're shaming someone. If you've just shamed them, you've actually introduced a whole new element to their work and their relationship with you. And the only way anyone's going to stay in that situation, is if they don't have a choice.
And if you have a choice, you should be getting a new employee, rather than continuing to work with one who has to live with this shame that you've personally heaped on them.
Jim: So this is really interesting. You've made me realize that I haven't really tried - and this is probably ten years later from both of those incidents - both of those examples - I don't know how far I ever went to try to unpack the motivation behind why those two particular situations happened?
Sitting here, the second one that I know of - this guy was the vice president in a consulting company that I was at. And frankly, he was just a bully. He was a bully. He was well liked by a core of people who were on his good boy list. I didn't like the way he treated people, and I'd stand up to him because I was driving several hours a day to and from for a commute, and I didn't need it. So I was on neutral with him, but there were a lot of folks that that guy just flat bullied. I think this was part of it - one guy who saw his demotion on that particular example, was not on his Santa's good list.
The first one - I think that guy was just scared. He didn't know how to give hard news face to face. So it was a fear thing. It was avoidance. And both of those are very core things.
Bullying is kind of core and intrinsic to somebody. And fear - I mean that goes back to us as monkeys. "Okay, so I don't want to have to see this guy, and I'm just going to put this on the slide and he's going to be behind me, and I'm not going to have to look him in the eye. And that's how I'll break the news."
Len: When you're talking about bullying and motivation, that reminds me, I've got this sort of pub table conversation piece where I say, "One of the interesting things about the discourse around illegal drugs, is that you're not allowed to talk about the pleasure. That is the motivation, and what at least gets you going in the first place. There are some very deep cultural reasons why we're sort of not allowed to talk about the pleasure.
And when it comes to causing harm to other people, it's also against convention to talk about pleasure. So what we'll talk about is the bullying victim's suffering. But it's somehow impolite to talk about the bully himself doing it for pleasure.
Len: I really believe that with all the discourse around bullying that's developed in the last few years, unless and until we find an ability to talk about the fact that people who bully are sometimes - not all the time, and not all of them - are people who enjoy causing harm to other people; they anticipate it, and they go home, and they're like, "That kid's crying in his room right now, and I did that to them." And then they take a sip of their energy drink, and they just sit there contemplating and enjoying the thoughts that they're having about what that other person is experiencing after what they've done to them.
Jim: You run into this in everything you do. Why are people motivated to do things? That's part of being a leader too. You're going to run into spots where there are bullies on your team. So are they bullying out of fear, because they're worried about their position going away? Because the process is changing? Are they bullying because it fulfils a need for power? Because even behind that - you talk about that pleasure, you're spot on. People do that for a reason. "Oh well, it makes me feel good." "Why does it make you feel good?" "Oh well, because I'm scared, because I'm actually not very good at X, Y or Z. They're being good. And if I talk them down, I feel better - and then people aren't going to look at my own inadequacies."
You're right. We'll address the action, but not the cause. And as a leader, as someone who wants to learn to be a leader, you've got to learn to take those steps about, "Man, I'm pissed off because that person's a bully." Why are they -?
Len: You reminded me, another subtle challenge to leadership is what you might call passive aggressiveness, I suppose?
For example - and these things arelike inherently tricky, which is why they're worth discussing - but sometimes people can claim that they've been poorly treated when they haven't been poorly treated. This is another type of problem that's very hard to discuss, because if you're a manager and someone's claiming this, then you have to keep in mind what other people will perceive, based on your response. For example, you don't want people who are actually being poorly treated to be concerned that they won't be genuinely listened to. This is just a very hard problem.
Jim: I think it's exactly this kind of stuff that people who are great technical leaders - the go-to trouble shooter, the person who knows all of the frameworks, the person who pairs and who mentors people in the team room - does not want to step up to actually run the team. When you talk with those types of people that are brilliant, they are inspiring even, it's like, "Man, I'd love to have you take another step up and spread these beautiful hugs all over the place." They're like, "Man, I don't want to deal with the drama."
And what's that drama? That drama is, that crappy side of all of us as humans. Where, "I'm a snowflake, I'm special," right? "And you need to treat me this way." "No, I'll talk to you a certain way, but I need the same outcomes because we need to have fair and equal treatment across the whole team. I'll speak to you, and we'll have our communication that might be different. But the actions and results - I can't have you doing something else, when I have these other expectations of everybody else, because that's the norm. I value your diversity, I value your difference of opinion. You're contributing, but I'm sorry, you can't come in at three in the afternoon, go home at five."
Len: I know what you mean.
Jim: That's the stuff those brilliant, awesome technical people don't want to have to deal with. People will leave organizations to avoid being put into those kinds of roles that they don't want to.
Len: The last question that I always selfishly in these interviews of Leanpub authors is - and sometimes people don't have an answer right at the time and might email me later - but if there were one thing on Leanpub that we could build for you, or one thing that we could fix for you as an author, what would that one thing be?
Jim: I've done two books for myself on Leanpub, and have done the Markdown, Git-push flow. That's worked really well. I'm helping a fellow here in the Rogue Valley that's part of Oregon, who has an amazing life story. He was thrown in prison for a while on a false accusation. He lost his family, lost his job, lost his reputation, lost his life. He's got this amazing story that he started writing in prison.
This guy is challenged by trying to turn on a computer. I don't have a specific feature. But what is hard for him, and the reason that I'm doing stuff is, he wrote everything in Word. But the Word processing flow doesn't have as much flexibility or ease of use for somebody like him, like, how can a version -?
And there may be bits and pieces of that. Part of that is, I've been over in Git in the Markdown context, and I've had to do some other things over here. But outside of the hard core technical domain, there are people with extraordinary stories in the world. And it's the grandma and grandpa types who just don't - I mean this guy wasn't even sure how to send me the file as an attachment. So how can we serve? I mean this guy's story, if Oprah was still around, this would be the book of the month. How can we get those people with amazing stories, this easy flow that doesn't get them confused and scared?
Len: Thanks for that response. That's really good and gets to the heart of a lot of the problems that we do try to address. We do have something called a visual editor now. I don't know if you've come across that. It's writing in the browser.
You highlight some text and you can make it italic. You click a plus sign to make a new chapter. It really couldn't get a lot simpler. I mean how people are introduced to it and stuff like that, we can always work on that. But for someone like this, I think that would actually be very good.
The complication that we've run into with authors many times, is if they come to us with a big Word document - if they haven't done much formatting, like if all they've got is like chapters and then paragraphs with words in them, you could probably just more or less cut and paste that into our visual editor. Or even into a plain text document, and you'd be fine.
But if people have done a lot of formatting.... It's just so unfortunate that people think they have to use Word. Because one of the big problems is that, it's like you need to cross a river, and someone gives you an aircraft carrier.
And they're like, "Well before we get going, we've got a dedicated satellite that we need to make sure we uplink to." And it's like, "I just want to get across the river." I could probably do that in a canoe. But instead, everybody thinks they need this thing which has - I always bring up the example of mail merge.
Microsoft Word has built in there the idea that you're using this to create letters where you're going to print the address and the name on the letter. But you're going to have a set of names, and you're going to set up a template. And then they're using that same tool to write a novel.
I mean, it's 2017, and if you've got a Microsoft Word document that's just words that's more than 20 pages long, you're going to get that stupid beach ball all the time. And even if you're writing something that's very simple - just words, that's hundreds of pages long - you have to split it up into multiple files. It's weird, because there's this paradox, where people think they're not technical, but they can write in Word. If you can do that, oh my God.
I think about people who are like, "Oh no, computers." And it's like, "Well, you have no problem getting into a car and turning it on and then driving like 60 miles an hour, as the pilot of this machine.
But anyway, that's just a long way around of saying to anyone listening who's using Word, you're already a technical person. And if you are thinking of using Leanpub, if you've got a long book in Word, you can try various approaches.
But probably what you're going to want to do is find some tool - if you want to use Leanpub, you're going to probably want to find a tool to turn your book into a PDF in EPUB and MOBI, and then upload those to Leanpub. That way you can use all of our lean publishing features, and get our 90% minus 50 cent royalty rate per sale, and that kind of goodness.
Again, if you've already got a long, heavily formatted Word document, you probably don't want to try converting it to Markdown.
Jim: Right, which is what I did. The guy had a modest amount. I'm moderately technical myself. So I wrote some macros, put it over in text, edited some regex-fu.
But as big of a problem as Word can be, it's on almost everybody's computer. And man, when somebody wants to tell a story and they finally get motivated - if they're getting going in Word, at least they're getting their story down.
Len: I was going to say, I would be remiss if I didn't mention, we actually do have a Word workflow where you can use Dropbox and you can write just like you [are used to] - wherever you save Word files now, when you're writing, you would just save them in the shared Dropbox folder, and you can actually write a Leanpub book that way.
But you would probably want to do that when you're starting a new book or story, rather than when you've already written a ton.
Jim: Yeah, because like you said, the formatting is a big challenge. Because all of Word's for adding stuff. Especially when you get into anything past just very basic. It's just complex and it's specific to Word.
Len: This is very in the weeds, but one time we had an author come to us with a book. And there was this one problem that I just fixated on, because I wanted to know what was wrong. And what had happened was, when you create a table of contents in Word, using their table of contents feature, whoever did it was under pressure or lazy, but they got away with hacking the bookmarks feature in Word, to make the table of contents work.
Len: What happened was, a person would create a table of contents, and then that would create all kinds of gobbledygook when you tried to run it through Leanpub's book generators. Because what we do is, if you have a chapter heading formatted as Heading 1 from our template, then we just automatically create a table of contents for you in your book in all these different formats.
So this guy, I took his manuscript and I deleted the table of contents. But there were all these ghosts showing up after our book generators had gone through it. And what had happened was, these bookmarks were there even if you deleted the table of contents.
The hack was they hid the bookmark. There's such a thing as hidden bookmarks in Word. And so whoever built the table of contents feature in Word, did this ridiculous short cut that then sort of infects the Word file with something - you might not even know about bookmarks, let alone hidden bookmarks, and then to delete them, you have to delete them all one by one. Anyway, this is just an example of how Word has a lot of pitfalls and minefields in it.
Jim: Right. It's great for basic stuff. It's great for a starting point, like you mentioned. But you guys have such great tool flow in Leanpub that it's worth moving over to something else very shortly.
Len: Thanks. On that positive note, thanks for the kind words, Jim. I really enjoyed our conversation. Thanks for telling us about your experience. And yeah, thanks for being a Leanpub author.
Jim: Thank you very much for having me, and thanks for such great service. It's been great.