Ron 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.

Transcript brought to you by IEEE Software

Nate Black 00:01:05 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 two 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 Schwab dot coms. 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 a conference and professional group talks on implementing agile and scrum and transforming software development from chaos to clarity, Ron, welcome to software engineering radio. Thanks, Nate, 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 00:02:08 Well, a programming manager is a manager, coupe manages programmers and the, um, the challenge is that my coauthor Mickey mantle, and I think that programmers are that we who, who are or have been programmers are pretty unique bunch. Um, 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. It’s no weird thing that there’s a huge crossover between software developers and musicians. The number of programmers who also do music is, is really huge. And interestingly music has both a left brain and a right brain kind of aspect to it. It has a very, very analytical, a way

Ron Lichty 00:03:00 That it’s put together in 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. And that combination of engineering and artfulness or engineering and craft is pretty unusual. Uh, electronics engineering is very cut and dried mechanical engineering is very cut and dried. Uh, aeronautical engineering 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, uh, pro in, in, uh, I have friends who are novelists who say, you know, writing software is a lot like writing a novel, you start with a blank page and craft it from there.

Nate Black 00:03:47 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 00:03:58 Yeah. So the challenge in managing us and managing programmers is that not only are we different from everyone else, but we’re different from each other. So programmers are different from every everyone else in the sense of being both left-brained and right brand in both being both engineers and craftspeople. And we have to motivate and to enable both parts of brands, both parts of who programmers are. And we also have to think about how, how programmers differ from each other, not, not just how they differ from other groups of people, but how they differ from each other, you know, in our book, uh, we slice and dice us into in, in various ways to try to be helpful and 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. Uh, there are morning people and night people. There are farmers and Cowboys. There are so many ways to think about it. And ultimately every programmer is unique. And 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, each of those qualities in each of those people.

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

Ron Lichty 00:05:40 Uh, so do managers write code? So that’s a, 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 as critical 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 then possibly neither of them. Well, um, they’re very different qualities. Uh, the, the transition from programming, they actually the transition through a career path. Um, 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.

Ron Lichty 00:06:45 And 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 that work for you, teamwork and motivation, and, uh, or to get out of the way of their own motivation. And it’s, it’s a really, a people kind of job with a technical kind of background.

Nate Black 00:07:23 You’ve talked before about the need for programmers to focus on their work and focus being an important part. 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.

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

Nate Black 00:07:51 Why is programming management hard?

Ron Lichty 00:07:55 Well, to start with it, 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 their coach. We as managers are essentially coaches of our teams and 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, uh, is a real challenge. One of the things that, um, that I just cited was that change from climbing, from, 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. And 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, um, 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 00:09:24 How much training do managers usually have before they’re thrown into the fire. So to speak

Ron Lichty 00:09:30 A great question, I have talked to audiences of Dao, probably thousands of managers. And it’s a question that I asked to find out exactly how much management and training I’m seeing in my audience. And I’ll have, uh, everybody in the audience, who’s a manager stand up and 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. And then I’ll ask those of you. Who’ve had those of you, all of you standing, I’ve had at least one day of training and 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 5% or less of managers. Who’ve 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 00:10:44 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 00:10:54 So becoming a manager is not something we get to decide. We can, we can train for it. We could plan for it. We could prepare for it. We could think this is my career path, but it’s somebody else who decides whether we get an offer to be a manager. And that manager hood offer could come because our manager quits and his manager says, Ron, you’ve got some people skills, you manage the team. And that happens more often than not in talking with a lot of managers. You are just tapped to become the manager. And, uh, 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 00:11:40 What should you think about before you accept that role and step into this new role?

Ron Lichty 00:11:45 You want to think about what it is that you want to do and what you like to do. And I would suggest, think about trying it out. You know, we do in, in modern management, in modern project management, we talk about process experiments. And, you know, I think this is, 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 would be one thing to think about is, am I the, in my, the best shot my team’s got for having a manager, because that could make a really big difference. And then think about, let me try this out and think about it. So my own transition to being a manager was, uh, what I was, I was intrigued by. I was interested in becoming a manager. I was a programmer. I had what I thought was the best job in the whole world.

Ron Lichty 00:12:43 I was in a two person programming shop. We were doing everything from a bedded microcontrollers to compiler code generators, to multimedia entertainment applications, and early word processing software. And I was really intrigued by gee. I wonder what managing a group of people like me would be like, and it was thinking about that. And it was really the only reason that I wanted to leave this two person shop was I couldn’t become a manager and a two person shop. And there was one other company I was interested in working for really interested in working for. And that was Apple computer and Apple made me an offer to come be a manager. And I said, sure, yes, I’ll come do that. In fact, I was not managing developers. I was asked to come manage to create a product management group in a technical, in a technical sense, a product management group of development tools inside of Apple computer.

Ron Lichty 00:13:40 And 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, uh, about a year and a half in, they reorg my job out of existence and said, go looking for another job inside of Apple. And 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. Uh, it was, I don’t think I was a programmer for more than a month or two before they made me the manager. Uh, 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.

Ron Lichty 00:14:30 That’s very different role programming and managing programmers. And, you know, I think you really have to think about the trade offs are that as a programmer, you’re working on code, you’re working on making thought stuff work. You’re working on a 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, and you don’t get that as a manager, you don’t get the same ecstatic excitement and, and, uh, joy coming from achieving. And you know, you also don’t get quite the same level of despair, uh, 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. And it’s, 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 from

Nate Black 00:15:43 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 00:15:55 Uh, it’s a much less measurable kind of result, but

it’s, it’s a feeling that I’ve got a team that’s really, really on the same wavelength, a team that’s really jelling a team. That’s really becoming a high performance team and I’ve helped to enable that I’ve, I’ve helped people to see what their connection is to the bigger picture. I’ve helped people to see how 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 our have each other’s backs and do respect and trust and, and really come together as a team, not just a group of individuals. And there’s a huge amount of gratification that comes from looking at your team and realizing that you’ve done, that

Nate Black 00:16:59 You talked about what success looks like as a manager, but in your book, you also described the pointy haired boss, and that’s kind of an archetype for what a bad manager looks like. What is a pointy haired boss?

Ron Lichty 00:17:12 Yeah. Well, the point of air boss comes out of Dilbert and, and, and it’s the boss. None of us, hopefully, hopefully no one listening to this show wants to be the point of here at boss. We’re all trying to be the, the opposite of that archetype. 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, it was a peak experience for me,

Nate Black 00:17:43 A matter of avoiding doing certain bad things, or is it something positive you have to go after or a, Oh, absolutely.

Ron Lichty 00:17:50 A combination. We managers need to figure out how to set boundaries without, 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 00:18:35 Can you describe what happens when a manager tells a programmer what to do and also how to do it?

Ron Lichty 00:18:41 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. And what micromanagement does is it causes people to step back. Uh, 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. And it’s really counterproductive. It’s really counterproductive on the part of managers

Nate Black 00:19:24 And part of bringing your whole self is also bringing in that right brand aspect that you were talking about. The creativity is, do you have an example of something that a programmer contributed that just was out of left field? They weren’t expecting to made a positive impact.

Ron Lichty 00:19:39 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. And the inventor of that device, uh, this was, uh, 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. And 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 do, how to, how to create the guts, how to make this thing, deliver what it is that I’m asking for. And 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, you know, bring yourselves to this and give, give me the best that you can give me.

Ron Lichty 00:20:38 And the, what was so clear that it was like rolling down a Hill, delivering what he wanted. And I had time left to bring that right brain left brain stuff you were just talking about. I invented a way of storing that data. This is very early on when there was very little memory and the kind of storage spaces that we were doing. And I invented a new way of doing that. And, and he got a patent on the encryption methods that I invented for doing that. And it was 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 00:21:15 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 00:21:29 Communication in every way is one of the big problems that I run into just over and over and over again, fundamentally software development and fundamentally product development is a team sport, and we need to talk to each other. So we, you know, one of the big chasms is between the people who wear the title, product manager and the people who were the title, developers and testers, and what we need is to understand the, what, without, without being told the how, but we need to understand as much as possible. And 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. And 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 it and say, Oh, that one will, will blow our customers away. Fundamentally, there’s a well, so we’ve got a rule Mickey and I came up with a rule of thumb that you can’t over communicate in product teams. Now it’s possible. Then on the sales side, they can, over-communicate, it’s possible on the marketing side, they can over-communicate, but I’m pretty sure that in product development, we can’t overcommunicate

Nate Black 00:22:54 Many organizations use the scrum or agile process for that communication between the team and the product managers. And 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 00:23:14 Coach, and Scandinavia name of Henrik Nyberg who has done some work in scrum with Spotify actually, and has written about that. And he’s got some diagrams that basically shows 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, and scrum masters and testers, and sometimes DBHs and, and other, uh, other functions in them. And 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, of the, uh, 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.

Ron Lichty 00:24:27 They won’t be focused on growing their careers on growing their ability in their field, on communicating across teams with the other people who do what they do and to best practices and how we use best practices and how we, how we, um, leverage standards and, and how we do stuff in a, in an effective way within our particular specialty. And what managers do is to feed all of that and support all of that. And it’s a think of it. Think of it. As you know, we’ve, we’ve talked about matrix organizations and I’m not sure that this is exactly a matrix organization in the classic sense, but it’s definitely a matrix 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, in their growth and in their best practices and in their communications across their specialty to, uh, to doing their best work.

Nate Black 00:25:34 It 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’re, 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 00:25:54 Yeah. Yeah. I, 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 sh the coach of the LA Lakers at that time had won a number of NBA records with the, uh, with the Chicago Bulls. And since then, between the balls and the Lakers as one 11 rings on his hand, and 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 have, but I hadn’t heard of them, but I ended up Michael Jordan DNAR did Michael Jordan, Michael Jordan had sent every shooting record that existed.

Ron Lichty 00:26:57 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 and awe, but they actually played together and they work together and they pass the ball together. Phil Jackson ASO, you know, I played a little bit of basketball when I was in middle school at, which is why I really don’t think about basketball because I swore it off after middle school. But I remember thinking, gee, you know, we get in trouble out there on 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.

Ron Lichty 00:27:51 And 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, 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 00:28:29 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 and 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 00:29:05 Well, so one of the, uh, we were talking earlier about categories of programmers, and there is a category that I would that Mickey and I labeled jerks in bozos. There is a category of that probably in every category of work. And 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 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.

Ron Lichty 00:30:02 Every team knows who those people are and cringes, when they evoke that kind of behavior, how do you build a successful team? Mickey? And I started writing our book because we had been having breakfast with each other. We’d 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 and thought these are really valuable to us. Maybe we ought to collect them and share them with other managers. And then it occurred to us. Maybe we had 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 one of those is from a guy named David Deidre, who is a bit of a guru in test driven development and testing and agile.

Ron Lichty 00:31:07 And David’s got a rule of thumb that pair programming for half an hour with a candidate during an interview, we’ll save, everyone’s a huge amount of time. And what happens during pair 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. And I think that’s a really valuable way of, of recruiting and interviewing and identifying people who will work and become part of our team. Rich Sheridan, who runs Menlo innovations, an agile based consulting company out of Ann Arbor. Michigan uses that to the max. Uh, he talks about how, uh, Menlo innovations will bring in 50 candidates for per 50 programming candidates at a time. They will pair them up with each other and have as a third person, a, a watcher centrally, uh, a fly on the wall, watching these two people pair with each other. And 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 to, you know, 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 and effectively, and, and, and really team up.

Nate Black 00:32:53 And 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 00:33:01 Yeah, absolutely. And 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 higher just hired out of college have unique expertise and unique experience. And our goal as managers is to foment the crosspollination of that expertise and that experience. And 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, uh, and leveraging their manager to make sure that they are,

Nate Black 00:33:44 Is that something that they’re reluctant to do or developers just aren’t in the habit of doing,

Ron Lichty 00:33:49 I’d say yes, and yes, we are introverts. And we tend to dismiss our skillsets either, either, either dismiss them or think 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. And 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 00:34:24 How can the manager surface those unique skills and capabilities and get them programmer to come out of their shell and even progress further and blossom into the best program or they can be.

Ron Lichty 00:34:39 Yeah. So that’s a, that’s a really broad ranging question. The first thing is, 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 and we have to connect with who they are and what they care about. And out of that comes understanding of what they know and what they can share. Uh, you know, some of that’s some of that, maybe even a lot of that’s 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, 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 programmers is so introverted that they sit in the corner instead of engaging in conversation.

Ron Lichty 00:35:31 And our challenge is to find ways to get that introverted programmer into the mix and sharing. And part of it, 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 and 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 with eight other people. So we don’t necessarily put them up at the whiteboard in front of the organization on day one, that’s a transition.

Nate Black 00:36:15 I’ve heard some managers say that their biggest challenge is sourcing the right candidates. Not every team is in a position that the bowls or the Lakers are into 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 00:36:40 Yeah. So I’m going to, I’m going to step back to a rule of thumb, which is, and this is an interesting one because Mickey and I have both identified this as the most important rule of thumb that we think applies to programming managers. And that is we need to always be recruiting. So one of the, one of the things is we come out of being introverts too, but we have to network. We have to go to meetups. We have to be out there talking to people. We need to be collecting business cards. We need to be collecting LinkedIn 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. And our responsibility as a 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, is certainly our personal network.

Ron Lichty 00:37:47 And it’s a network that we need that we need to be able to leverage as hiring managers and recruiting. So that’s one part, or maybe it’s two parts. A 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 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. You know, if we’re being paid enough, what motivates us to do great work and it’s making a difference in the world, it’s, it’s getting the light to come on in people’s eyes, it’s delighting it’s, it’s, uh, you know, making, uh, making a big difference. And 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. And 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 in the world, and be able to communicate that. And I think that’s a really powerful, motivating recruiting message.

Nate Black 00:39:07 I’d like to try to summarize the most important rule of thumb. You said was always be recruiting. And this is the secret to hiring the right people, even if you otherwise would have challenges in sourcing talent, for whatever reason. And 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. And in fact, he gave a whole chapter on the topic of motivation. I’d love to talk more about that later for someone 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, a slice of the pie? Where does a manager spend their time

Ron Lichty 00:39:58 In meetings? Uh, there’s no question that we’re managers spends their time as in meetings. And 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, you know, where does the managers spend their day? Well, I can tell you where I spend the beginning of my day and that’s in the shower and 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. And then I need to be in touch with the people who work for me, people who are in my group during the day, and I need to be in touch with my peers and I need to be in touch with my boss.

Ron Lichty 00:40:56 And those are, those are all meetings. And 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. And, uh, and 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 that solution, and begin to build a consensus around making that solution happen.

Nate Black 00:41:39 It sounds like you’re keeping, uh, 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 00:42:00 So I’d say, I’d say that’s that’s, if not yet, that’s definitely a part of it. I think that the challenge is to make sure that we’re working on the most important stuff. And, uh, 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. And we need to think about 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 00:42:40 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 00:42:53 Yeah. Uh, I’ll give you, I’ll give you an example. So at a company I was at, we had a whole lot of teams across the company, and we were doing very early work with Java. And 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 was essentially systems. 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. And so we would build them out of CORBA, which was hard and deep. And 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.

Ron Lichty 00:43:57 We did decide that we did pick a couple that we wanted to base that on. And we realized that we were, we were moving forward into the future in this application server Java based direction, but we had some older code based around this Corbus stuff, and we needed to solve this one. We needed to stop building CORBA based applications, and we needed to stop having application developers, building CORBA infrastructure. And 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’re 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 Korbel work and having done good CorVel work. The ones, the ones that are in production are the ones that are working.

Ron Lichty 00:44:55 They’ve got a vested interest in what it is they know, and what it is they were able to achieve. And I made it a point to, we had a cafeteria that was on the center floor of the building. So 14 floors on the seventh floor is the cafeteria. And everybody comes down to the cafeteria somewhere between 1130 and one o’clock. And 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. And, and 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. And that there were a lot of stakeholders.

Ron Lichty 00:45:48 And 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 round and 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. And in two hours we had, we had said, here’s what we’re going to do in this case, in this case, in this case, here’s how we can move forward. We had unanimity in two hours and it, 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 00:46:37 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 impose it from the top down. What would have been the outcome had you done that

Ron Lichty 00:46:50 People probably would have left. They would have quit. They would have argued. They would have fought, you know, there would have been all kinds of an angst and conflict and people would have escalated to SVPs and VPs. And there would have been a senior level executive meetings and it would have gone on and on and on.

Nate Black 00:47:09 And the people who stayed behind you think they would be motivated, not so much. Is it the manager’s job to keep the team motivated?

Ron Lichty 00:47:18 Uh, 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, it’s certainly job as a manager to make sure that the people who work for me have a clue. I have an insight into the impact that their work can make and can do. And that’s a, you know, making an impact in the world. I cited earlier as, 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, of code, uh, you know, I think making a difference is, is a huge piece. And then we need to look at making sure we don’t de-motivate people and look and making sure that we’ve got the other pieces of motivation in place. The, so that it’s a place that people want to work that. So 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 though, it’s in that kind of place.

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

Ron Lichty 00:48:39 And the chapter on motivation, we introduced 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 is people. Um, this particular one is a, is a guy named Hertzberg who, and actually all three of them are the 1940s and 1950s is the first one. Everyone will recognize, which is Maslow and Maslow’s hierarchy of needs. Uh, the second two are McGregor and Hertzberg, Hertzberg posited that there aren’t as many things that motivate people as we think one of those things that we think motivates people is money. And his contention was that there are two kinds of motivators, one that are one set that are foundational, that if you don’t have them, you can’t motivate you can’t truly motivate people and the other. And so we call those the motivators for lack, when they’re lacking, they’re de motivators and the other set are truly motivators.

Ron Lichty 00:49:42 And so think about company policies or respect for your supervisor. So, you know, most people don’t join companies because they respect the person that they’re hiring in to report to. And 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. And there’s an HR rule of thumb that says that 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 the motivators. And then there are motivators, which, you know, we tend to think, Oh, let’s put some money in front of somebody. And, uh, you know, this guy, Daniel pink has written a whole book about how drive is the of his book on. Well, one of the, one of the big themes of it is the putting money in front of people in fact, is, is counterproductive as a motivator, the things that motivate programmers.

Ron Lichty 00:50:40 And I’m going to turn to the, uh, 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, 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, of the company and understand how they’re going to make a difference in the world, uh, 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 and technology, and we get to play with technology and have fun with technology. Those are, those are really significant motivators

Nate Black 00:51:33 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 as both a strong motivator and a strong de-motivator

Ron Lichty 00:51:46 Right, and having fun is, is, uh, is as well. If you’re not having fun, you’re likely to leave. If you’re having fun, you’re likely to stay. And 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 de-motivator. So there are things that are both motivators and demotivators, and then there are things like administrative policies that are just the motivators.

Nate Black 00:52:10 We covered a lot of interesting important material from your book. And I want to start wrapping up, ultimately, who should and should not become a manager. Fundamentally.

Ron Lichty 00:52:21 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. And 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, 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. I, this is not who I am. I am about technology. And 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 awhile. And 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, and to think about what, uh, what he’s doing, can I leverage and what are the pressures pressures on him that I saw myself, uh, 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.

Ron Lichty 00:53:48 He he’s, he’s responsible for my care and feeding, but there’s this whole other set of things where, where managers are actually working to help their managers succeed, who are, uh, 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 00:54:15 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 they recognized later? Yeah.

Ron Lichty 00:54:25 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. And this is a, a significant realization. A second. One of those is that it, one of the uncomfortable things you realize is that, whereas as a programmer, you’re 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 and 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. And you have to communicate that your job becomes one of communication. Way, way, way more than it ever was when you were a programmer, you could just rely on, well, here’s what I, well, here’s what I did. Here’s my code here. Here are the lines of code.

Nate Black 00:55:37 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 by the people that work for him, but the people below you, Nope. Yes. Some organizations only provide management as a track towards promotion. And 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 as that that’s something that you’ve found. And what’s the impact of that

Ron Lichty 00:56:06 Good organizations starting decades and decades ago recognized that that’s a problem. There are truly talented people who want to grow their careers and not grow their careers into management. And those good created dual track growth, drill, dual track, uh, promotional opportunities where people could stay on the technical track or move into the management track and move up through the ranks. Um, there’s no technical ladder CEO position that I’ve ever seen. There are CEOs who’ve been technical, but, but they are. CEO is 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. And if, if you want to stay on a technical track, find an organization that has a technical track.

Nate Black 00:57:08 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 00:57:16 There’s one aspect. There’s a low hanging fruit that if you’re a manager, even if you’re on a team there’s a low hanging fruit that is plucked way to sell them in technical organizations. I can’t speak about the rest, but certainly in technical organizations and product organizations and 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 they’d been in the recruiting cycle and there may be somebody else after them who makes them a better offer after they 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.

Ron Lichty 00:58:18 So the care and feeding in between accepting an offer and coming on board is, 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 coauthor of the study of product team performance. And we query people on product teams all around the world of developers, product managers, project managers, scrum masters, everybody who are testers, everybody who, who 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? And then what practices, how do they characterize their practices? And one of the things that we’ve, that was found in the first study. So I was not the coauthor of the very first year that the study was done. And my interest was so peaked that I made a point of contacting the coauthors of it.

Ron Lichty 00:59:14 And then they didn’t have an engineering voice. And they had, they recruited me to be part of the team. And that 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 were five characteristics of teams that correlated with high performance teams, and one of them was effective onboarding. And 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 and the number of people on teams who said that their onboarding could be considered a best practice was 5% given that onboarding correlates with high performance teams and only 5% 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 into our teams better.

Nate Black 01:00:16 We need to help people become productive way faster and become part of teams way faster. I’ll be sure to include a link to this study in our show notes, as well as a link to your book. And where else can people find more information about you and the work that you do well?

Ron Lichty 1:00:48 So I’m at Ronlichty.com. Our book is managing the unmanageable.net. You have to spell it, right? And, uh, and you’ll find links to the study, uh, for both of those and links to the 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. And, uh, and you can also find more rules of thumb. So we’ve continued to collect rules of thumb and the additional rules of thumb are, are on, uh, on, uh, managing the unmanageable.net.

Nate Black 1:01:29 Thanks, Ron, the book is an incredible resource. I enjoyed reading it and 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 that your everyone’s asking the right set of consistent questions and for onboarding and for onboarding, let’s not forget a whole chapter on onboarding Ron lick T thanks for being on software engineering radio.

Ron Lichty 1:01:54 All right. Thanks Nate.

[End of Audio]

This transcript was automatically generated. To suggest improvements in the text, please contact content@computer.org.

