SE-Radio Episode 306: Ron Lichty on Managing Programmers

Filed in Episodes by on October 17, 2017 2 Comments

ron-licht-100x125Ron Lichty talks with SE-Radio’s Nate Black about managing programmers. Topics include: why programming management is hard, what makes a good programming manager, the costs of micromanagement, self-organizing teams, team dynamics and motivation, and product team performance.


Related links


 View Transcript

Transcript brought to you by IEEE Software


Recording: This is Software Engineering Radio, the podcast for professional developers on the Web at SE Radio is brought to you by the IEEE Computer Society and by IEEE Software Magazine, online at

Recording: DigitalOcean recently launched Spaces, a beautifully simple object storage service designed for developers who want a simple way to store and serve a vast amount of data such as images and large media files, user-generated content, backups and logs. Spaces is available for a simple $5.00 per month price that includes 250 gigabytes of storage and 1 terabyte of outbound bandwidth. Additional storage is priced at the lowest rate available, $0.01 per gigabyte transferred and $0.02 per gigabytes stored. This provides cost savings of up to ten times along with predictable pricing and no surprises on your monthly bill. Try it for free with a two-month trial by going to DO.CO/SERadio.


Nate Black: This is Nate Black for Software Engineering Radio. I’m very pleased to welcome Ron Lichty, co-author of Managing the Unmanageable to the show. Recruited to Apple in 1988, Ron product managed Apple’s development tools then led to Finder and applications groups for the Apple II and Macintosh product lines, managing delivery of Apple’s user interface. Ron went on to direct development of entertainment products at Berkeley Systems and Fujitsu, specializing in making development predictable and repeatable.

Ron then led software development of’s first online investment tools. Since Schwab, he has had vice president roles in engineering and products, both as an employee and as a consultant. Ron has given conference and professional group talks on implementing Agile and Scrum and transforming software development from chaos to clarity. Ron, welcome to Software Engineering Radio.

Ron Lichty: Thanks, Nate.


Nate Black: Your book, Managing the Unmanageable talks about programming managers in contrast to other kinds of managers. Could you define what is a programming manager?

Ron Lichty: Well, a programming manager is a manager who manages programmers. The challenge is that my co-author, Mickey Mantle, and I think that programmers – that we who are or have been programmers are a pretty unique bunch. We tend to refer to ourselves as software engineers, but while there’s some engineering aspects to what we do, there’s also art to what we do. There’s no weird thing that there’s a huge crossover between software developers and musicians. The number of programmers who also do music is really huge. Interestingly, music has both a left-brain and a right-brain kind of aspect to it. It has a very analytical way that it’s put together and a very artful way to deliver it to delight customers.


When we’re in the software business, our goal is to delight customers but we have to be very analytical about it as well as artful. That combination of engineering and artfulness or engineering and craft is pretty unusual. Electronics engineering is very cut and dried. Mechanical engineering is very cut and dried. Aeronautical is very cut and dried. Civil engineering is very cut and dried. Software engineering, not so much. We start with thought stuff. We conjure up – I have friends who are novelists who say, “Writing software is a lot like writing a novel.” You start with a blank page and craft it from there.

Nate Black: Part of the challenge of being a programming manager is the nature of the work itself, but also the fact that programmers, themselves, are different. Could you talk a little bit more about that?


Ron Lichty: So, the challenge in managing us, in managing programmers is that not only are we different from everyone else, but we’re different from each other. So, programmers are different from everyone else in the sense of being both left-brained and right-brained and being both engineers and craftspeople. We have to motivate and to enable both parts of brains, both parts of who programmers are. We also have to think about how programmers differ from each other, not just how they differ from other groups of people but how they differ from each other.

In our book, we slice and dice us into – in various ways to try to be helpful in understanding who we are. So, Web developers are different from database developers are different from systems developers are different from business logic developers are different from scripters.


There are morning people and night people. There are farmers and cowboys. There are so many ways to think about it. Ultimately, every programmer is unique. The challenge for us as managers is to figure out that uniqueness of each of the people who work for us and to truly connect with and support and enable each of those qualities in each of those people.

Nate Black: Is it correct to say that the manager is responsible for managing people and their careers or are there other responsibilities? For instance, do managers write code?

Ron Lichty: So, do managers write code? That’s a great question. The answer is that there are plenty of managers who do write code. What Mickey and I would say about that is that if you’re managing and you’re writing code and that code is critical path code, you are likely to focus on one of those things or –


the other and you’re likely to do, at most, one of them well and possibly neither of them well. They’re very different qualities. The transition from programming – actually, the transition through a career path, one of the rules of thumb is that the very thing that makes you successful at one level gets in your way at the next. So, think about what does it take to be a great programmer.

One of the characteristics that makes you great at being a programmer is the ability to shut out the world, to climb into the microprocessor and listen to the gates open and close, to truly become one with the computer. That’s just exactly the opposite of what you need to do as a manager. As a manager, you need to not only put a Welcome mat out in front of your door but to proactively welcome interruptions from the people who –


work for you, from your peers, and from your boss because all of that stuff is what you’re managing and trying to create with the people who work with you, teamwork and motivation and/or to get out of the way of their own motivation. It’s really a people kind of job with a technical kind of background.

Nate Black: You’ve talked before about the need for programmers to focus on their work and focus the important, but you just mentioned that managers are taking interruptions all the time. So, it seems that their priorities are, in a way, flipped from what a programmer’s priorities are. Is that right?

Ron Lichty: Yeah. So, a manager’s priorities are their programmers. I, as a manager, need to be aware of and available to my team pretty much all the time.

Nate Black: Why is programming management hard?


Ron Lichty: Well, to start with, to be a good programming manager, you almost have to have been a programmer before that, much as football coaches and basketball coaches and tennis coaches played the game, with very rare exceptions before becoming that coach. We as managers are essentially coaches of our teams. Knowing what it is that our teams face, what it is that the people who are on our teams face and what it is that bring them together to cause great stuff to happen is a real challenge. One of the things that I just cited is that change from climbing – from shutting out the world to inviting the world to interrupt us, one of the things that makes that hard is that some very large percentage of us who are programmers are introverts. What we need to do is learn extroversion skills.


What we need to learn is people relationship skills. What we need to learn is empathy skills, that soft stuff, that emotional intelligence stuff that makes people comfortable talking to us, because, fundamentally, that’s what we want is our teams to talk to us and to tell us what’s important and what’s getting in their way and how we can help.

Nate Black: How much training do managers usually have before they’re thrown into the fire, so to speak?

Ron Lichty: Great question. I have talked to audience of, now, probably thousands of managers. It’s a question that I ask to find out exactly how much management training I’m seeing in my audience. I’ll have everybody in the audience who’s a manager stand up. I will ask those who have had at least one day of training in management, just one, to stay standing.


Half my audience will sit down. Almost universally, half my audience sits down. Then I’ll ask, “Those of you – all of you standing have had at least one day of training in management. This is not managing programmers. This is just something related to management. If you had a day of that training before you became a manager, stay standing.” We’re looking at five percent of less of managers who have had a day of training. It’s really ironic the amount of training we expect programmers to have in programming and the lack of training that we expect of managers.

Nate Black: You also pointed out that many programming managers fall into the job almost without any planning, almost as if it happens by accident.

Ron Lichty: So, becoming a manager is not something we get to decide. We can train for it.


We can plan for it. We can prepare for it. We can think, “This is my career path.” But it’s somebody else who decides whether we get an offer to be a manager. That managerhood offer could come because our manager quits and his manager says, “Ron, you’ve got some people skills. You manage the team.” That happens more often than not in talking with a lot of managers. You were just tapped to become the manager and you’re stepping into a role that you haven’t – you may have given it some thought, but you certainly haven’t given it the kind of thought that it deserves.

Nate Black: What should you think about before you accept that role and step into this new role?

Ron Lichty: You want to think about what it is that you want to do and what you like to do. I would suggest think about trying it out.


We do – in modern management, in modern project management, we talk about process experiments. This is, without given lack of manager candidates, you may be the best shot your team’s got at having a good manager. So, that might be one thing to think about is, “Am I the best shot my team’s got for having a manager,” because that could make a really big difference. Then think about, “Let me try this out and think about it.”

So, my own transition to being a manager was – well, I was intrigued by it. I was interested in becoming a manager. I was a programmer. I had what I thought was the best job in the whole world. I was in a two-person programming shop. We were doing everything from embedded microcontrollers to compiler code generators to multimedia entertainment applications and early word processing software.


I was really intrigued by, “Gee, I wonder what managing a group of people like me would be like?” I was thinking about that. It was really the only reason that I wanted to leave this two-person shop was I couldn’t become a manager in a two-person shop. There was one other company I was interested in working for, really interested in working for, and that was Apple Computer. Apple made me an offer to come be a manager. I said, “Sure. Yes, I’ll come do that.”

In fact, I was not managing developers. I was asked to come create a product management group in a technical sense, a product management group of development tools inside of Apple Computer. I spent about a year and a half being a manager in that product management organization before Apple, in those days and probably still reorgs pretty incessantly and about a year and a half in, they re-orged my job out of existence and said, “Go looking for another job inside of Apple.”


I thought about it and thought, “This has been interesting. I’m going to be a programmer again.” I went back to being a programmer. It was – I don’t think I was a programmer for more than a month or two before they made me the manager. Six months later, they blew up that group. I went looking for another programming job.

About a month or two later, they made me the manager. It was only that third time being a manager that I truly felt like this was what I wanted to do. It’s a very different role, programming and managing programmers. I think you really have to think about, the tradeoffs are that, as a programmer, you’re working on code. You’re working on making thought stuff work. You’re working on hard, technical challenges and when you succeed, it’s so ecstatically wonderful that you jump out of your chair and scream with delight, at least I have.


You don’t get that as a manager. You don’t get the same ecstatic excitement and joy coming from achieving. You also don’t get quite the same level of despair right before you hit that level of joy. But as a manager, you’ve got much more breadth. You’ve got more say in the game. You’ve got less say about any particular thing. You’ve got less ability to dive deep, but you’ve got way more ability to dive broad. It’s just a fundamental decision of where you want to spend your time and how do you want to spend your time. Do you want to spend your time helping a whole group of people to get that ecstatic joy or do you want to be the one getting the joy?

Nate Black: For a programmer, that joy comes from, as you said, putting code out that works, but what does success look like for a manager? How do you judge yourself on, “Have I been successful?”

Ron Lichty: It’s a much less measurable kind of result, but it’s –


a feeling that, “I’ve got a team that’s really on the same wavelength, a team that’s really gelling, a team that’s really becoming a high-performance team. I’ve helped to enable that. I’ve helped people to see what their connection is to the bigger picture. I’ve helped people to see what they’re doing is delighting customers. I’ve helped people to see how working together, we can get more synergy and more power and more success than we can just working as individuals. I’ve helped people to see how to have each other’s backs and to respect and trust and really come together as a team, not just a group of individuals.” There’s a huge amount of gratification that comes from looking at your team and realizing that you’ve done that.


Nate Black: So, you talked about what success looks like as a manager, but in your book, you also described the pointy-haired boss. That’s kind of an architype for what a bad manager looks like. What is a pointy-haired boss?

Ron Lichty: Yeah, a pointy-haired boss comes out of Dilbert and it’s the boss none of us – hopefully, no one listening to this show wants to be the pointy-haired boss. We’re all trying to be the opposite of that architype. We’re trying to be the boss who truly – who programmers come away and say, “It was great working for Ron. If he ever calls me again to work on one of his teams, I’m going to go do that because it was a peak experience for me.”

Nate Black: Is it a matter of avoiding doing certain bad things or is it something positive you have to go after or a combination?

Ron Lichty: Oh, absolutely a combination. We managers need to figure out how to set boundaries without –


micromanaging, how to set goals without telling people what to do and how to do it. How to enable them to own pieces of the code that they’re working on and bring their best selves to that code and bring all of their thinking and their options and possibilities to that code and to create something better and to delight customers in ways that they didn’t expect to be delighted.

Nate Black: Can you describe what happens when a manager tells a programmer what to do and also how to do it?

Ron Lichty: One of the examples that I give of what we have to avoid in Agile, Agile asks everybody on a team to step up. It asks teams to come together as teams. What micromanagement does is it causes people to step back.


If I’m a programmer and I’ve got somebody telling me what to do and how to do it, I’m going to step back and say, “Okay, I’ve got that done. What do you want me to do next? What do you want me to do next? What do you want me to do next?” I’m going to become an order taker instead of bringing my whole self to both the product and to my team. It’s really counterproductive. It’s really counterproductive on the part of managers.

Nate Black: Part of bringing your whole self is also bringing that right-brained aspect that you were talking about, the creativity. Do you have an example of something that a programmer contributed that just was out of left field, that you weren’t expecting that made a positive impact?

Ron Lichty: I’ll bring an example of my own. When I was a programmer, we were doing a brand-new device that didn’t exist yet. The inventor of that device – this was both electronics and software and I was working on the software part of it that was going to be embedded in this device.


The inventor of the device came to us with a manual for his device. “This is what I’m going to give to users. This is how the thing works. You guys figure out how to create the guts, how to make this thing deliver what it is that I’m asking for.” It was possibly the only project I ever worked on as a programmer and possibly the only one I’ve seen since that there were no ambiguities in what he wanted.

It was really clear – the what was really clear. But he wasn’t giving us any of the how. He was saying, “Bring yourselves to this and give me the best that you can give me.” The what was so clear that it was like rolling down a hill delivering what he wanted. I had time left over to bring that right-brain/left-brain stuff you were just talking about. I invented a way of storing that – this was very early on when there was very little memory and the kind of storage spaces that we were doing.


I invented a new way of doing that and he got a patent on the encryption method that I invented for doing that. It’s because he didn’t tell me how to do it. It was because he only said, “Here’s what I imagine I want to deliver for my customers.”

Nate Black: Do you think that most of the time that information or those requirements or goals or even values aren’t communicated down clearly enough to the developers? Is that the cause of a lot of problems that we see?

Ron Lichty: Communication in every way is one of the big problems that I run into just over and over and over again. Fundamentally, software development – fundamentally, product development is a team sport. We need to talk to each other. So, we – one of the big chasms is between the people who wear the title product manager and the people who wear the title developers and testers.


What we need is to understand the what without being told the how, but we need to understand as much of the what as possible. We need to understand really what it is that – what problem it is that our customers are trying to solve and how they’re struggling with it and what that really represents. Then we need to apply our brains to it as developers and testers to come up with options that our product managers can look at and say, “That one will blow our customers away.” Fundamentally, there’s – so we’ve got a rule – Mickey and I came up with a rule of thumb that you can’t overcommunicate in product teams. Now, it’s possible that on the sale side they can overcommunicate. It’s possible that on the marketing side they can overcommunicate, but I’m pretty sure that in product development, we can’t overcommunicate.

Nate Black: Many organizations use the Scrum or Agile process for communication between the team and the product managers.


You pointed out in one of your talks that in the Agile diagram, the manager isn’t even depicted. So, that brings up the question, “If we’re Agile, why do we need managers?”

Ron Lichty: Coach in Scandinavia, name of Henrich Neeberg who has done some work in Scrum with Spotify, actually, and has written about that and he’s got some diagrams that basically show teams being self-organizing and self-sufficient in a lot of ways. What are not self-sufficient are the groups of people within them. So, we create these cross-functional teams that have Web developers and business logic developers and database developers and product managers and Scrum masters and testers and sometimes DBAs and other functions in them.


There’s a team, and that team can deliver business value to customers, but what it can’t do is the care and feeding of the function, of the kind of work doesn’t happen inside of that team. The database developers need best practices. The database developers need to grow their careers and if within their teams they continue to be focused on delivering stuff to customers, they won’t be focused on growing their careers, on growing their ability in their field on communicating across teams with the other people that do what they do and to best practices and how we use best practices and how we leverage standards and how we do stuff in an effective way within our particular specialty. What managers do is to feed all of that and support all of that.


Think of it as – we talked about matrixed organizations and I’m not sure if this is exactly a matrixed organization in the classic sense, but it’s definitely a matrixed organization from the standpoint that teams are self-organizing but the Web developers report to somebody who did Web development whose job it is not to tell them what to do but to enable them and support them in their growth and in their best practices and in their communications across their specialty to doing their best work.

Nate Black: That goes back to your coach analogy where the manager is like a coach and making sure that the team is structured the right way, maybe that they have individuals that fill all the different skill and various roles and also that they’re progressing in the way they need to progress in order to get better at their game.

Ron Lichty: Yeah, yeah. I’m not a sports guy. I’m really not a sports guy.


But when I was at Schwab in 1999 or 2000, I had a management coach who thrust a sports guy book into my hands. So, the book was Sacred Hoops by Phil Jackson. Phil Jackson, I had no idea who Phil Jackson was but it turns out Phil Jackson was the coach of the Chicago Bulls at the time, since then been the coach of the L.A. Lakers, at that time had won a number of NBA records with the Chicago Bulls and since then, between the Bulls and the Lakers has won 11 rings on his hand. His goal was to create a self-organizing basketball team.

So, this is a guy who inherited Michael Jordan. He inherited a number of other players, too, but I hadn’t heard of them. All of you probably had, but I hadn’t heard of them. But I had heard of Michael Jordan. He inherited Michael Jordan. Michael Jordan had set every shooting record that existed, it seemed like, and the Chicago Bulls were not winning.


His goal was to create a team in which Michael Jordan was part of the team and everyone else didn’t just stand back and look at Michael Jordan in awe, but they actually played together and they worked together and they passed the ball together. Phil Jackson – so I played a little bit of basketball when I was in middle school, which is why I really don’t think about basketball because I swore it off after middle school. But I remember thinking, “Gee, the – we get in trouble out there in the court, what we do is turn and look at the coach.”

Phil Jackson’s method was, “I want you guys to look at each other. My goal in practice is to guide your work so that when you get into trouble you look at each other, you look to each other.” He says in one of those two books, he says, “When my team is firing, not only does the other team not know what my team is going to do next, my team doesn’t know what it’s going to do next.


They watch each other and they play off of each other.” If you think about that, that’s like improv in acting or it’s like free jazz in music where every single member of an improv team and every single member of a free jazz group is a soloist from time to time, but they play off of each other and no one knows when their solo is going to come up for sure.

Nate Black: I love that analogy with the Chicago Bulls and Michael Jordan, because it touches on what you said in your book about the distribution of skills in a team and how there are certain programmers that make outsized contributions, but that may not be enough in order to have a successful team and to launch a successful product. But I would like you to talk a little bit about that as we dive into teams and building a team.


Can a good manager take any group of individuals and turn it into a successful team?

Ron Lichty: Well, so one of the – we were talking earlier about categories of programmers. There is a category that Mickey and I labeled jerks and bozos. There is a category of that probably in every category of work. When we’re building teams, and software development is fundamentally a team sport – I’m going to come back to that – bozos and jerks do not fit on teams.

So, can I take any group of people and make them into a team? Probably not. Can I take someone who’s acting like a jerk or a bozo and have a conversation with them about the fact that we’re not going to have that on our team and do they want to not be that and be on a team or do they want to leave? Yes, I can do that and I will do that and I have done that, because the team needs me to do that.


Every team knows who those people are and cringes when they evoke that kind of behavior.

Nate Black: How do you build a successful team?

Ron Lichty: Mickey and I started writing our book because we had been having breakfast with each other. We had been mentoring each other over breakfast every couple of months for years and had been sharing rules of thumb over the breakfast table with each other thought, “These are really valuable to us. Maybe we ought to collect them and share them with other managers.” Then it occurred to us, “Maybe we ought to use the 60 years or so of experience we had in software development and share a little bit of that, too.” So, that took us another eight years to write. Those rules of thumb, one of those is from a guy named David Vidra who is –


a bit of guru in test-driven development and testing and Agile. David’s got a rule of thumb that peer programming for half an hour with a candidate during an interview will save everyone a huge amount of time. What happens during peer programming with a candidate is that we learn how the candidate programs, but we also learn how they collaborate and we also learn whether this is someone we want to work with. I think that’s a really valuable way of recruiting and interviewing and identifying people who will work and become part of our team. Rick Sheridan who runs Menlo Innovations, an Agile-based consulting company out of Ann Arbor, Michigan, uses that to the max.


He talks about how Menlo Innovations will bring in 50 programming candidates at a time. They will pair them up with each other and have, as a third person, a watcher essentially, a fly on the wall watching these two people pair with each other. The goal of pairing for each of those 50 people is to get their pair hired, not to get themselves hired, to get their pair hired. If you can make your pair look so good that we want to hire him or her, we’re likely to want to hire you, too. I think that’s what we have to think about as managers, as hiring managers, as people recruiting developers are, “Who can work with the people on our team effectively and really team up?”

Nate Black: Is that also a measure of a good, successful employee, that they’re making their peers look good, not just making themselves look good?


Ron Lichty: Yeah, absolutely. Another measure of that would be, “How am I ensuring that my peers know what I know?” So, every, single member of a team, even those just hired out of college, have unique expertise and unique experience. Our goal as managers is to foment the cross-pollination of that expertise and that experience. Every member of that team should be thinking about, “What do I know that would be useful to my teammates to know and how do I share it,” and leveraging their manager to make sure that they are.

Nate Black: Is it something that they’re reluctant to do or developers just aren’t in the habit of doing?

Ron Lichty: I’d say yes and yes. We are introverts and we tend to dismiss our skill sets either dismiss them or think they’re better than they are.


So, it can go both ways. But our tendency then is to be quiet rather than communicative. One of the responsibilities of a manager is to grow programmers into communicating with the rest of the team and communicating what they know and communicating their expertise and experience.

Nate Black: How can the manager surface those unique skills and capabilities and get the programmer to come out of their shell and even progress further and blossom into the best programmer they can be?

Ron Lichty: Yeah, so that’s a really broad-ranging question. The first thing is to form the relationship with the programmer, between the manager and the programmer. In order for us, who are managers to know who programmers are, we really have to connect with them. We have to connect with who they are and what they care about.


Out of that, comes understanding of what they know and what they can share. Some of that, maybe even a lot of that is going to come out in code. It’s going to come out in conversation. It’s going to come out – well, it may come out. It depends on how introverted people are. So, it will come out in code.

The question is, “Will we recognize it when it comes out in code from a programmer who’s just so introverted that they sit in the corner instead of engaging in conversation?” Our challenge is to find ways to get that introverted programmer into the mix and sharing. Part of it is simply acknowledging the value that that person has. They may be sitting in the corner because they don’t feel they have value or they may be sitting in the corner because they feel like they’ve got value but they don’t know how to communicate it.


Helping them to make that and sometimes it’s helping them to make that communication just one on one first before they make it with two other people and then with four other people and then with eight other people. So, we don’t necessarily put them up at the white board in front of the organization on day one. That’s a transition.

Nate Black: I’ve heard some managers say that their biggest challenge is sourcing the right candidates. Not every team is in a position that the Bulls or the Lakers are in to have the best players knocking on their door. How can you overcome that challenge if you’re not finding the right candidates or you find that you’re not getting enough applicants?

Ron Lichty: Yeah, so I’m going to step back to a rule of thumb which is – this is an interesting one because Mickey and I both identified this as the most important rule of thumb that we think applies to programming managers. That is, we need to always be recruiting.


So, one of the things is we come out of being introverts, too, but we have to network. We have to go to meet-ups. We have to be out there talking to people. We need to be collecting business cards. We need to be collecting Linked In connections. We need to be connecting with interviewees. We may interview a bunch of people at one company and select only one, but realize that there are two or three others who are interesting. Our responsibility as managers for the future is to stay in touch with those other two or three people who are also good programmers, to make them part of our network, to build what is, in some ways, a hiring network but is certainly our personal network and it’s a network that we need to be able to leverage as hiring managers in recruiting. So, that’s one part, or maybe it’s two parts.


The third one is that we need to not only always be recruiting, but we need to be thinking about what our core value is, what our mission is, what our company is contributing to the world. So, as an engineer, I’ve looked at my own and I’ve looked at an awful lot of engineers and an awful lot of us are motivated by making a difference in the world, possibly more motivated by that than almost anything else. If we’re being paid enough, what motivates us to do great work? It’s making a difference in the world. It’s getting the light to come on in people’s eyes.

Its delighting customers. It’s making a big difference. We, as managers, need to think about, “What’s the difference that our company is making? What’s the difference that our products are making? What’s the difference that my team is making? What’s the difference that the person that I’m hiring into this role can make for our team and our customers and our company and the world?” Be able to communicate that.


I think that’s a really powerful, motivating, recruiting message.

Nate Black: I’d like to try to summarize. The most important rule of thumb, you said, was always be recruiting. This is the secret to hiring the right people, even if you otherwise would have challenges in sourcing talent, for whatever reason. Part of that, too, is finding out what’s motivating for you and for your company, their values that a candidate might share that would motivate them to take the job and also motivate them in the job. In fact, you gave a whole chapter on the topic of motivation. I’d love to talk about that later. First, I want to dive into the day to day of what a manager’s job looks like. Could you talk a little bit about maybe hour by hour or as a slice of the pie, where does a manager spend their time?

Ron Lichty: In meetings [laughs].


There’s no question that where a manager spends their time is in meetings. Because of that, we need to set aside thinking time, strategizing time, and to ensure that we’ve got innovative thinking time and to think about where that is. Where does a manager spend their day? Well, I can tell you where I spend the beginning of my day, and that’s in the shower.

Taking a shower in the morning is where I think through my day and think about what difference I’m going to make today and what impact I can make and about the big challenges I’m facing and what I’m going to do about them today. That conversation with myself happens in the shower in the morning before I even get going. Then I need to be in touch with the people who work for me, people who are in my group during the day. I need to be in touch with my peers and I need to be in touch with my boss. Those are all meetings.


Then I am quite possibly going to be involved in fomenting teamwork somewhere or another and making sure that the right people are talking to each other about the right issues. There’s a huge element of what’s called socialization of ideas where I realize that the possible answer is to this problem and that means I need to talk to a whole bunch of people along the way and begin socializing that solution, get people on board with that solution and begin to build a consensus around making that solution happen.

Nate Black: It sounds like you’re keeping tabs on the big picture situation of what people are thinking about, what people are talking about, and trying to make sure that the big, important ideas are shared across a bunch of various groups. Is that the right way to interpret what you said?


Ron Lichty: So, I’d say that’s, if not it, that’s definitely part of it. I think the challenge is to make sure that we’re working on the most important stuff. It’s one of the things I love about Agile is that Agile, for project teams, one of the basic practices is having a backlog that’s ordered by the things that are the most important to do, that will deliver the most value to customers, that will delight our customers most. We need to think of our own work in the same way, creating that backlog that’s – that we know that the thing I’m going to work on next is the thing that’s going to deliver the most value.

Nate Black: Let’s say, as an example, the thing at the top of your backlog is there’s an idea that you need to socialize amongst your team or teams. Could you give an example of the way that that socialization process would work?

Ron Lichty: Yeah. I will give you an example.


So, a company I was at, we had a whole lot of teams across the company and we were doing very early work with Java. In order to do very early work with Java, application servers did not yet exist or they did not exist in a robust kind of way, which meant that we basically had to engineer those ourselves. So, we were in the financial services business. A financial services applications development team engineering what is essentially system software is not exactly how I would like application developers to spend their time, but it was what we had to do at the time, because application servers didn’t exist.

So, we would build them out of CORBA which was hard and deep. We had a number of failures for that reason and we had a number of successes that were based on CORBA. But application servers did come along. We did decide – we did pick a couple that we wanted to base that on.


We realized that we were moving forward into the future in this application server, Java-based direction but we had some older code based around this CORBA stuff and we needed to solve this. One, we needed to stop building CORBA-based applications and we needed to just stop having application developers building CORBA infrastructure. Two, we needed to think about as those systems aged and needed to be maintained or updated or especially when they needed major improvements what we were going to do about that and how we were going to move into the future. This is not exactly an easy problem because you’ve got a whole bunch of people who are tied to having done CORBA work and having done good CORBA work. The ones that are in production are the ones that are working. They’ve got a vested interest in what it is they know and what it is they were able to achieve.


I made it a point to – we had a cafeteria that was on the center floor of the building. So, 14 floors; on the 7th floor is the cafeteria. Everybody comes down to the cafeteria somewhere between 11:30 and 1:00. I made it a point to run into the people who were connected to CORBA and to say, “I think we need to work through how we’re going to move forward relative to this issue of CORBA and of application servers and what we’ve got and what we need to have.”

Just having that conversation of not a solution, really just presenting the fact that we needed a solution, we needed to come together as a group. There were a lot of stakeholders. I think I did that for about six months, probably longer than my management was happy about my doing that. But at the point at which we came together, we were all ready to have that conversation.


We walked into the room on a Friday afternoon. I had a room reserved for three hours. We did a go-around. Everybody talked with each other. We shared what it was – how we were connected into the CORBA universe and into the Java universe and into the future universe. In two hours, we had said, “Here’s what we’re going to do in this case and this case and this case. Here’s how we can move forward.” We had unanimity in two hours. It’s the kind of unanimity that for a socializing manager makes shivers run up and down your back because it doesn’t happen very often.

Nate Black: You were able to achieve consensus in that two-hour meeting, but it sounds like a situation where you could have made a decision and imposed it from the top down. What would have been the outcome had you done that?

Ron Lichty: Well, people would have probably left. They would have quit. They would have argued. They would have fought. There would have been all kinds of angst and conflict.


People would have escalated to SVPs and EVPs and there would have been a senior level executive meetings and it would have gone on and on and on.

Nate Black: The people who stayed behind, do you think they would be motivated?

Ron Lichty: Not so much.

Nate Black: Is it the manager’s job to keep the team motivated?

Ron Lichty: So, the answer is absolutely yes. Is the manager the only person whose job it is to keep the team motivated? Probably not. But it’s certainly my job as a manager to make sure that the people who work for me have a clue, have an insight into the impact that their work can make and can do. Making an impact in the world, I cited earlier as, I think, one of the most motivating – for those of us in engineering, for those of us in programming, for those of us working this craft of code, I think making a difference is a huge piece.


Then, we need to look at making sure we don’t demotivate people and making sure that we’ve got the other piece of motivation in place. So, it’s a place that people want to work. So, that it’s a place that people have fun working. So, that it’s a place where people come together and feel like they’re in a second family. So, it’s that kind of place.

Nate Black: You talked about two broad categories of motivating factors, the kind that can demotivate and the kind that can elevate people. Could you describe that a little bit right now?

Ron Lichty: In the chapter on motivation, we introduce three theories and we give them only a page or two a piece. But they’re sort of fundamental to understanding how people – how our brains work, how we’re motivated as people. This particular one is a guy named Hertzberg who – actually, all three of them are the 1940s and 1950s.


The first one, everyone will recognize, which is Maslow and Maslow’s Hierarchy of Needs. The second two are MacGregor and Hertzberg. Hertzberg posited that there aren’t as many things that motivate people as we think. One of those things we think that motivates people is money. His contention was that there are two kinds of motivators.

One set that are foundational, that if you don’t have them you can’t truly motivate people. The other – so we call those demotivators. When they’re lacking, they’re demotivators. The other set are truly motivators. So, think about company policies or respect for your supervisor. Most people don’t join companies because they respect the person that they’re hiring into report to. Now, I don’t know anyone who’s ever joined a company because of its administrative policies, but administrative policies can sure make you leave a company.


There’s an HR rule of thumb that says people don’t leave companies, they leave managers. If you don’t have respect for your manager, you are very highly likely to leave. So, those are demotivators which we tend to think, “Oh, let’s put some money in front of somebody.” This guy, Daniel Pink, has written a whole book about how – Drive is the name of his book on – well, one of the big themes of it is that putting money in front of people, in fact, is counterproductive as a motivator.

The things that motivate programmers, and I’m going to turn to the example, the things that motivate programmers tend to be making a difference in the world. So, he said achievement, but we said making a difference in the world. Learning and growing, toys and technology, having fun, recognition and praise.


Those are all things that motivate programmers and making sure that we’re recognizing the people on our teams, that we’re praising the people that are on our teams, that they’re connected with the message of the company and understand how they’re going to make a difference in the world, that they continue learning and growing as programmers, this is really fundamental to who we are as programmers. We want to continue learning and growing in technology and we get to play with technology and have fun with technology. Those are really significant motivators.

Nate Black: That one’s interesting. I’m looking at the chart you’re showing from your book that ranks the motivators and demotivators. The learning and growing is unique because it’s both a strong motivator and a strong demotivator.

Ron Lichty: That’s right. Having fun is as well. If you’re not having fun, you’re likely to leave. If you’re having fun, you’re likely to stay. More fun is likely to be a motivator. More learning and growing is likely to be a motivator.


No learning and growing is likely to be a demotivator. So, there are things that are both motivators and demotivators. Then there are things like administrative policies that are just demotivators.

Nate Black: We covered a lot of interesting, important material from your book. I want to start wrapping up. Ultimately, who should and should not become a manager?

Ron Lichty: Fundamentally, you want to think about whether your career is about the people who build technology or whether you want your career to be about the building of technology itself. I think each of us has to choose at that inflection point where we have an opportunity to become a manager, whether we want to continue going up a technical ladder and stay technical and – for many of us, it’s a choice of, “I want to stay introverted. I don’t want to learn those extroversion skills. I don’t want to learn how to motivate people. This is not who I am. I am about technology.”


I certainly understand that, especially going back and forth as a programmer and a manager three times at Apple. It was a question I continued to ask there for a while. It was a wonderful back and forth for me, because I was able to go back to being a programmer and look at my manager and how he was doing it with really new eyes for having tried to be that manager just a few weeks before. To think about what he’s doing can I leverage and what are the pressures on him that I saw myself once I became a manager that I had no idea of, and what are all of the things that he has to do behind the scenes that I don’t see. I just look at him as, “Oh, he’s my manager. He’s responsible for my care and feeding.” But there’s this whole other set of things where managers are actually working to help their managers succeed –


who are working with their peers to figure out stuff and to make the organization succeed and who are doing a whole lot of other things besides just my care and feeding.

Nate Black: Could you give an example of one of those things or one of the things your manager was doing that you didn’t appreciate before that you recognized later?

Ron Lichty: Yeah, I think once you get into the area of helping other people succeed, you realize that your job is not just to help the people that work for you succeed, your job is to help your boss succeed. There’s a rule of thumb that says the most important person in the organization is your boss. This is a significant realization. A second one of those is that – one of the uncomfortable things you realize is that whereas as a programmer, you were pretty much judged on what you did.


As a manager, you’re judged on how what you do is perceived. It is perception, not what you’re doing. Perception means that you have to communicate what you’re doing to up and out so that people realize the impact of what it is you’re doing. You have to communicate that. Your job becomes one of communicate way, way, way more than it ever was when you were a programmer. You could just rely on, “Well, here’s what I did. Here’s my code. Here are the lines of code. It’s working.”

Nate Black: So, it’s about how what you’re doing is perceived by those above you? That’s the up. Your peers, that’s the out?

Ron Lichty: And by the people who work for you.

Nate Black: And by the people below you.

Ron Lichty: Yep. Yes.

Nate Black: Some organizations only provide management as a track towards promotion. If, as an engineer, I want to grow my career or get a raise, I might feel like I’m forced into going into management.


Is that something that you’ve found and what’s the impact of that?

Ron Lichty: Good organizations, starting decades and decades ago, recognize that that’s a problem. There are truly talented people who want to grow their careers and not grow their careers into management. Those good organizations created dual-track growth, dual-track promotional opportunities where people could stay on the technical track of move into the management track and move up through the ranks. There’s no technical ladder CEO position that I’ve ever seen. There are CEOs who have been technical, but they are CEOs, not some kind of parallel to a CEO in a technical track. But there’s a role that goes all the way up the ladder to just below the CEO in good organizations.


If you want to stay on a technical track, find an organization that has a technical track.

Nate Black: I’d like to find out if there’s any important questions, from your point of view, that I left out that I should ask about management?

Ron Lichty: There’s one aspect. There’s a low-hanging fruit that if you’re a manager or even if you’re on a team, there’s a low-hanging fruit that is plucked way too seldom in technical organizations. I can’t speak about the rest. But certainly, in technical organizations and product organizations. That’s onboarding. We did a whole chapter on what to do after you’ve recruited someone between when they’ve accepted the offer and when they’re maybe a month into the job and what that transition looks like. So, there’s two parts to that. One is making sure the person actually shows up for the first day, because if they’ve been in the recruiting cycle and there may be somebody else after them who makes them –


a better offer after they’ve accepted yours and there are an awful lot of us who are managers who have had the experience where we thought we had someone hired and they didn’t show up on the first day or they showed up just long enough to say, “Oh, by the way, I accepted a counter offer from my former boss,” or, “I accepted a better offer from some other company.” So, the care and feeding in between accepting an offer and coming on board is significant and important. But secondly, onboarding itself, the first day, the second day. So, HR does onboarding into benefits, but we need to onboard people into teams. So, I’m also the co-author of The Study of Product Team Performance. We query people on product teams all around the world. The developers, product managers, project managers, Scrum masters, everybody who are – testers, everybody are on product teams about, “Are they on a high-performance product team or a low-performance product team, or average; how do they characterize their team?” Then, “What are practices?


How do they characterize their practices?” One of the things that was found in the first study – so I was not the co-author of the very first year that the study was done and my interest was so piqued that I made a point of contacting the co-authors of it. They didn’t have an engineering voice and they recruited me to be part of the team. It was an unexpected – I have another job now that I wasn’t expecting to have.

But the outcome of that first one was that there are five characteristics of teams that correlated with high-performance teams and one of them was effective onboarding. So, that next year when I was in my first co-authorship year, we decided we would ask teams about how effective was their onboarding. The number of people on teams who said that their onboarding could be considered a best practice was 5 percent.


Given that onboarding correlates with high-performance teams and only five percent of teams are willing to call out their onboarding as effective as a best practice, this is a low-hanging fruit. We need to onboard people onto our teams better. We need to help people become productive way faster and become part of teams way faster.

Nate Black: I’ll be sure to include a link to the study in our show notes as well as a link to your book. Where else can people find more information about you and the work that you do?

Ron Lichty: Well, so I’m at Our book is You have to spell it right. You’ll find links to the study from both of those and links to stuff we do and managerial training we do and we have Addison Wesley recorded video training based on the book. All that stuff is – you can find out about off there.


You can also find more rules of thumb. So, we’ve continued to collect rules of thumb and the additional rules of thumb are on

Nate Black: Thanks, Ron. The book is an incredible resource. I enjoyed reading it. I encourage everyone to pick it up. In addition to those rules of thumb, you had a set of tools at the back of the book including spreadsheets for conducting interviews, making sure everyone’s asking the right set of consistent questions.

Ron Lichty: And for onboarding.

Nate Black: And for onboarding. Let’s not forget a whole chapter on onboarding. Ron Lichty, thanks for being on Software Engineering Radio.

Ron Lichty: All right. Thanks, Nate.

Recording: Thanks for listening to SE Radio, an educational program brought to you by IEEE Software Magazine. For more about the podcast, including other episodes, visit our website at To provide feedback, you can comment on each episode on the website or reach us on Linked In, Facebook, Twitter or through our Slack –


Channel at You can also email us at This and all other episodes of SE Radio is licensed under Creative Comments license 2.5. Thanks for listening.


[End of Audio]



Tags: , , , , ,