So, What Is Leadership, Really?

Episode 2

This week on the Programming Leadership podcast, we’re diving into the theories and definitions of what leadership means and looks like (and even what it doesn’t look like)! Even if you wouldn’t call yourself a “natural born” leader, Marcus encourages you to remember that leadership is a process, requires learned skills and everyone has the building blocks to become a great leader. So, what are you waiting for? Tune in to find out how you can start building your leadership skills today.

 

 

Show Notes

• Leadership is a process, something we can improve over time as there’s no ultimate goal or right/wrong way to do it.
• Leadership outcomes is not about controlling people, it’s about creating an environment that affords everyone the ability to work on solving the most important problem at hand, because we all want to work on solving these problems.
• Leader’s don’t have to have the title, “Manager.” They’re often those people on your team who care; who believe that it’s better when everyone contributes and that the job gets done smoother.
• Marcus breaks down the two camps of leadership theories: entity theories and dyadic theories.
  • The entity theory asks, makes a leader so great? “It’s the idea that we look up to these leaders, admire them, and if we ever find ourselves in a leadership or management role, let’s try and become like them. Let’s model them.” [00:13:19 to 00:13:30]
  • Dyadic theories study the relationship between the leader and the follower. “The quality of relationship that people have with their boss is a predictor of how good their performance is and how satisfied they are.” [00:16:59 to 00:17:07]
• Everyone has the building blocks to be a great leader.
• If you’re new to a leadership/management role, Marcus suggests to reduce your coding time and increase your people time. In other words, start delegating more.
• Time management is one of the most difficult things in the transition from programmer to manager.

Links:

• Book recommendation: Becoming a Technical Leader by Gerald Weinberg
• Book recommendation: The Design of Everyday Things by Don Norman
• Herzberg’s two-factor theory of motivation
• Hackman’s job control [characteristic] theory
• Marcus’ webinar on time management for technical leaders
• Sponsor: GitPrime

Transcript

Marcus: Welcome to the Programming Leadership podcast, where we help great coders become great leaders and build happy teams. I’m your host, Marcus Blankenship. Today’s episode: One more time, what is leadership?

 

Marcus: On the last episode, we talked about the difference between managing and leading, and I told you that managing is a lot about controlling and assigning and allocating and assembling things. You manage your money, you manage your time, you manage your schedule, your servers, your code, you get the idea. Management is important, because we have limited resources in our lives. If I had unlimited money, I wouldn’t need to manage my money. But of course, I don’t. One thing that programmers used to have to manage was memory, for example. But now, that seems like it’s effectively unlimited, so we don’t have to think about it anymore, but I digress.

 

Marcus: This episode, we’re going back, to dive into this sticky question: what is leadership?

 

Marcus: Let me pause and thank today’s sponsor, GitPrime. GitPrime’s platform allows you unprecedented visibility into your development team. For too many years I’ve had to guess at the status of projects without any real data to make decisions from. Oh, I have tried everything: StoryPoints, Velocity, burndown charts, burnup charts. You name it, I’ve tried it. Worse yet, I’ve made the mistake of promising my boss when something would be done only to be disappointed. When I dug into things with my team I was always surprised between what the charts show and what’s actually happening. Now, it’s not like anyone’s messing up, but things are happening that I have no visibility of, which meant I couldn’t even discuss it with my team. GitPrime changed all that.

 

Marcus: With GitPrime, you can leverage git-level analytics. That’s where the real work is happening. It provides deep insights to help you have better conversations with your engineers and your whole team. See things better. Build things faster. Learn more and sign up for ademo at GitPrime.com.

 

Marcus: Now, my favorite definition of leadership comes from Jerry Weinberg’s book, Becoming a Technical Leader. And that says that leadership is the process of creating an environment which allows everyone to work on solving the most important problem at hand.

 

Marcus: I wanna break this down, because I really like this definition for a lot of reasons. First, this definition frames leadership as a process. It doesn’t happen overnight. It is a continual striving to create and improve this kind of environment. It’s not about perfection, it’s about incremental improvement over time. And I think that also means there’s no absolutely right way or wrong way to do it, and there’s also no ultimate goal. You can’t ever say, “We’ve arrived at creating the perfect environment that allows people to problem solve together.” No, there is always room for improvement, and we don’t have to be ashamed that we’re not the best in the world. All we have to do is recognize that this is something we can improve as a process over time.

 

Marcus: Second, I really like the outcome. The outcome is not controlling people. It’s not even, frankly, shipping great software. It is this other word called affordance. Okay? If you’re familiar with Don Norman’s fantastic book, The Design of Everyday Things, he talks about affordances are the things in everyday things that allow us to grip and manipulate and control the things around us. So a car radio has affordances of knobs, okay? Now, this is not about controlling people. This is about creating an environment which affords, and that’s the word I like, better than allows, affords everyone the ability to work on solving the most important problem at hand. Okay?

 

Marcus: So the other thing, of course, this assumes is that everyone wants to work on the most important problem. I believe this is 100% true. It’s also backed up by science. Herzberg’s two-factor theory of motivation and Hackman’s jobs control theory, both that came out in the ’60s and ’70s, identified that some of the biggest motivators for people was the work itself. We want to do good work. We want to work on hard problems. We want to do work that matters. And to me, it’s such a beautiful way to put it, to say that we’re going to create an environment which affords everyone the ability to work on solving the most important problem at hand. I think that’s a beautiful statement, and I think that everyone, everyone on your team and you, want to work on the most important problems at hand.

 

Marcus: Okay, now third, it doesn’t say that it allows people to work on any problem they want. Now, this is very important. It says that this special environment called leadership, that leadership creates this special environment which allows everyone to work on the most important problems at hand. Have you ever been assigned to work on a problem that didn’t seem to matter? I have. Maybe only certain people with certain titles got to work on the important problems. Frankly, it stinks. Right? You’re over there in the corner working on something, but it feels like, in comparison, your work doesn’t really matter. And I wanna work on problems that matter.

 

Marcus: This definition of leadership doesn’t say, “Create an environment where everyone’s busy,” or, “Create an environment where everyone’s productive.” Or, maybe another word we like to use is, “Create an environment where everyone’s contributing,” but no. This is an environment. Leadership is an environment where everyone’s working on the most important problem. I love that, and I think that’s what your team wants. In fact, truth be told, I talk to a lot of people who leave their jobs and unfortunately, one of the reasons programmers and managers leave their jobs is that they say, “I just couldn’t really contribute to things that mattered. I was somehow hamstrung,” and I find that really sad.

 

Marcus: Now, the last element to point out is that sometimes there are big, hairy, important problems that executives want us to solve. Okay? I get that. Those are very fun, challenging problems, sometimes. But there’s almost always a set of problems right here within arm’s reach. And I think that’s what Gerry meant by, “at hand.” These are the problems at hand which we could be working on. Which, many times, we should be working on. Sometimes these are the problems that everyone on the teams, seems, would agree need to be solved, but maybe never gets solved. Maybe we never get around to dealing with it. Does this sound familiar? Are there problems on your team, today, that if you sat your team down and you said, “Hey, what is the most important thing that we work on? What would impact our ability to serve, our ability to code, our ability to produce quality, our ability to be motivated? What would matter most?” I bet the things that your team sees are different than the executive sees. And I think that those, maybe, could be thought of as the problems at hand.

 

Marcus: Okay, let’s also, just for a minute, hit on this idea of what the definition doesn’t say. I think that’s just as telling as what it does say. It doesn’t say who’s a leader, it only says what they do. They create this environment. Of course, lots of people without the title “Manager” are doing this today, right where you work. My guess is that there are people on your team today who work hard to create an environment that makes everyone more productive and effective. They don’t have a special title, but they care. They care that everyone can contribute. They believe that it’s better when everyone contributes; that the job get done smoother. They aren’t worried about getting the credit or being in control, or getting the next promotion or power or prestige. These are leaders who are on your team today, and they’re leaders from within the team.

 

Marcus: Actually, it’s funny. One of my clients recently told me, “My boss went on vacation this week, and man, everything got easier.” How sad is that? Managers, bosses, executives and these capital ‘L’ leaders often inhibit, rather than contribute to, this environment. When they leave, people say, “Wow, things are so much easier and better now.” It’s all too common, and unfortunately, it’s pretty sad.

 

Marcus: Now, I really like this definition of leadership. Again, it’s Gerry’s. It comes right out of his book, Becoming a Technical Leader, but I’d be remiss if I told you it was the only one that I liked and that I believed in. And I think there’s another one that dovetails in so nicely, and it’s backed by more science. Gerry’s theory is backed by a lot of hands-on work leading teams.

 

Marcus: So let me give you this other one, okay? There’s as many leadership theories out in this world as there are programming languages. So there’s a huge, wide variety to choose from. That is really saying something, right? ‘Cause there’s a lot of languages. And I don’t know, I was thinking’ about it last night, and these leadership theories actually share something in common with programming languages. I might be stretching this a little bit, but I think they’re both attempts to understand something that’s really complex and nebulous, and really try and give practitioners better tools to work with.

 

Marcus: So let me get a little nerdy, here on ya. You’re probably a nerd if you’re listening to a podcast named Programming Leadership. Leadership theories can all be broken into just two camps: Entity theories and dyadic theories. And you can tell people this and sound really smart. Entity theories are also known as great man theories. Not to be sexist, but that’s what they’re called. And these have been around for thousands for years. And frankly, they remain very popular today. Now, these theories focus on the traits and qualities and behaviors and priorities of the leader. They put a microscope on the leader. The leader is the entity to be studied. The leader possess the leadership. Traditionally, the leader was studied, maybe like you might think about generals, kings, executives, founders, visionaries. Right? We get Napoleon, maybe the guy that was in Braveheart, William Wallace, Abraham Lincoln, John Kennedy. These are all examples. As are Steve Jobs and Bill Gates, of people who have been studied under great man theory scientific studies. They look at them and they say, “What made Steve Jobs so great? What made him such a great leader?” And then they really try and dissect all that.

 

Marcus: Now, of course, the reason they’re trying to dissect it, is the thing that goes with it, is the idea that if we knew what made Steve Jobs such a great leader, then we could maybe model some of those traits. Or maybe we’d learn that there was no point, because Steve Jobs maybe was born with a spark of genius, that he was just born that way. And so what we should do is, if we’re trying to hire for leaders, is we should just look for born leaders, or natural leaders.

 

Marcus: Now, entity theories are where we get these ideas about born leaders and natural leaders. And my guess is maybe you even heard some phrase like this when you were in elementary school. Maybe some teacher said, “Oh, you’re a natural leader.” This idea that some people are “born to lead,” or that they’re born possessing these special sparks of leadership genius, this is entity theory leadership, great man leadership. You could probably see why it’s called great man leadership, now. Right? It’s the idea that we look up to these leaders, admire them, and if we ever find ourselves in a leadership or management role, let’s try and become like them. Let’s model them.

 

Marcus: Unfortunately, this traditional idea of leadership leaves most of us out in the cold, including me. I’ve always felt like I was looking in at the cool kids. I was never accused, any time in my life, of being a natural leader, of being a born leader. Nope. That’s not me. If you google me, you’re gonna see pictures of me, Marcus Blankenship, and you will see what a giant dork I am. So I am sitting here talking to you, as a leader who has to say that this idea of entity theories and great man leadership, I don’t believe in it. I don’t believe in it at all.

 

Marcus: So let me tell you what I do believe in. So entity theories focus on these ideas of great men. It’s just not very useful. About 40 years ago, though, some psychologists were thinking the same thing. They thought, “Yeah, okay, maybe this leadership thing has been studied wrong. Maybe we’ve been looking in the wrong place. Maybe leadership might not be all about one person, the leader. But what if it’s about two people? The leader and the follower. And what if it’s about the relationship that they have together?” Now, in sociology terms, two people is a dyad, D-Y-A-D. So this is why it’s called dyadic theory. It’s about two people, not just one. And here’s a little bit of trivia you can use as the next time you wanna impress somebody. This was originally known as vertical dyadic linkage theory, and feel free to use that to impress people that you know, but other than that, forget it and never use it again.

 

Marcus: Alright. So these psychologist wondered, like, “Does a person’s relationship with their boss have any influence on their performance or their job satisfaction?” So these psychologist wondered, “Does a person’s relationship with their boss have any influence on their performance or satisfaction?” To put it in psychology terms, they wondered if there was a statistically significant correlation between the quality of relationship someone has with their boss and that person’s performance and satisfaction at work. Can you guess what they found? Well, hold it. Before I tell you what they found, let me ask you this, let’s do this quick thought experiment.

 

Marcus: Think back. Think back to the best boss you’ve ever had. Okay? Did you do great work there? Were you a good performer? Were you happy at your job? Now, let’s flip the question around. I want you to think about the worst boss you’ve ever had, and one comes to mind for me immediately, a guy named Paul. Did you do great work there? Were you a good performer? Were you happy at your job? If you’re like most people, you did much better work for your best boss than for your worst boss, and you were happy and more satisfied. I know I was. And we could go into boss horror stories, but we won’t do that today. I just want that thought experiment, every time I run it in my workshops, people nod. Sometimes people even jump up and they’re like, “Holy crap! I’ve been a high performer at every single place I ever worked, except this one job, and my boss hated me, and I hated him. And now I start to get it.”

 

Marcus: Okay, so these psychologists found exactly the same thing. The quality of relationship that people have with their boss is a predictor of how good their performance is and how satisfied they are. It’s a small step from there to imagine that things like turnover, motivation, enthusiasm, attitude; these are all impacted. We shouldn’t be surprised, then, to hear that Gallup’s 2016 State of the American Manager poll said that, then this is really sad, 50% of people have left a job to escape a manager. 50%! Thus, the saying was born: People join companies, but they leave managers.

 

Marcus: Now, all this research started 40 years ago. And like any good scientific finding, it needed to be repeated to validate it. And repeated it has been, through thousands and thousands of studies across the globe. All types of workers, all environments, even software developers, which I think is really cool. The theory has, of course, continued to evolve. That long name, which I won’t repeat, was quickly shortened to something that was a little more easier to handle. Broadly, now, it’s called leader-member exchange theory, or LMX theory. So if you want to research this more, google for LMX theory, and you’re gonna see lots of articles that talk about how the relationship you have with your boss matters and why, and some specific suggestions you can, as a leader, take from that idea.

 

Marcus: Now, okay. So the bigger point here is a whole new set of leadership theories are starting to evolve. And to be honest, it’s only in the last five years that they now live under a broader name. And that’s the name I’m gonna use more often, and that name is called relational leadership. LMX theory is a part of relational leadership, but there are many other parts. Servant leadership isn’t quite in relational leadership. We can talk about that on another episode. This area of study, and it truly is scientific study, really says that relational leadership is the way people want to be led, and the most effective way for leading smart people in our modern age, with the modern kind of knowledge workers that we have working for us.

 

Marcus: Okay, so I just wanna leave you with a final couple thoughts, here. So the first theory I told you about, Gerry’s theory, and relational leadership dovetail quite nicely. Both are about leadership, not management. The first one talks about creating an environment, and I would assert that the most important aspect of that environment is the quality of relationships we have with those people we work for, and we work with. Neither leadership theory tells us that leaders are born, or a very special kind of person in terms of their traits and qualities like extraversion, public speaking, ability to get outta their shell, whatever. It’s not about possessing natural born abilities. It’s about learning something.

 

Marcus: And this is how I wanna end today. This is my last point. I want you to think about this as our gospel. Okay? Gospel in Greek means “good news.” I think this is our good news, that leaders aren’t born, they’re made. And that is such very good news, indeed, because it means we can all learn to be leaders. I bet you’re actually closer than you think to being a great leader. You already know how to be a friend, a partner, a lover, a sibling, a peer, a colleague. You already know how to build strong trust, caring relationships with other people. You’re wired for that. You’ve got those building blocks to be a great leader. In short, you’ve got this. And we’re gonna continue working on this in future episodes of the podcast, but I just wanted to lay this foundation. That, to me, is leadership and that means that we, together, can learn how to do this better.

 

Marcus: So I promised we’d take a few questions today, and there were a couple of questions from the last show, so let’s dive into these.

 

Marcus: The first one comes from Tim, who writes in, “Marcus, I’m a relatively new team lead and I am absolutely overwhelmed. Should I be programming? Should I be managing, whatever the heck that means? How come every day goes by so fast? And frankly, what the heck is the most important priority?”

 

Marcus: Well hey, Tim. Thanks for writing in. Remember folks, if you’re listening, you can certainly send you questions to marcus@marcusblankenship.com. Alright Tim, what you’ve got here is a situation where unfortunately, you’re overwhelmed and you don’t know which way to turn. So let me just give you a couple of basics to orient you. First of all, if you’re the new team lead or tech lead, whatever you wanna call it, you’ve got to reduce your coding time, and you’ve gotta increase your people time. This is vital. And what that means is, you’ve gotta start delegating more. Alright? I recognize that maybe you’re the best coder on the team, that there are things that the other team members can’t do. I get it, okay? The problem is, is that now, every task you take on that puts you in the critical path, becomes a big problem. Because if I’m guessing correctly, you’re no longer as much in control of your schedule. That means you get to meet with bosses, with clients, with users, with your team. You have got a very, very full calendar.

 

Marcus: Okay, so the first thing you need to start doing, is you need to start delegating as much production work as you can. Now, I didn’t say coding. I said production work, because I do think you should still be coding. This is actually a variation on a past stance I had. The reason I think you should still be coding is because you are a technical expert, and your team needs your technical expertise. But, the real reality is, is every project you take on that puts you in the critical path, means it’s one more thing that you have to do that does not give you any flexibility to handle problems that come from your team or your boss. And frankly, it robs your team of understanding that bit of code that you write.

 

Marcus: Okay? Every bit of code you write is now a piece of code that your team didn’t write, and probably doesn’t understand well enough to maintain. I want you to think about that. You are literally robbing your team from learning opportunities.

 

Marcus: So here’s what I want you to do: I want you to grab a piece of paper, and I want you to make notes for a few days about exactly how you spend your time. This is especially important if it seems a little nebulous, where your time’s really going. Okay? So I want you to do this, and I want you to track kind of what percentage of your time is spend on coding, what’s in meetings, what’s with your team, what’s with your boss, what’s with your clients.

 

Marcus: And then I want you to reallocate that for a few days. I want you to try taking on no coding tasks. Not forever, but as an experiment, I want you to take on no programming tasks for, say, three days. And instead, I want you to sit down with your team members and delegate those. Now, you might say, “Marcus, I don’t delegate because we used Agile, and people just pull tasks off the board.” Okay, great. Well, that might mean you need to reassign some of your tasks, stories that you currently have open, out to team members. And it might mean that you need to sit down with team members who aren’t quite ready to take on the stuff you would’ve taken, and have a pair programming session to make sure that they are capable and ready and oriented for the work.

 

Marcus: So for three days, you are gonna avoid doing production coding work. You are still going to look at PRs, you’re still gonna do code reviews, you’re still gonna do architectural walkthroughs and demos, but I wanna get you used to being out of the software production cycle, because it’s your job to manage the process and the people, and in fact, to lead the people, not simply to contribute code.

 

Marcus: Now, if this is not your problem; if you are not spending enough time in the code, and your people are taking all your time, I want you to kind of flip this on its head. I still think you should do one-on-ones. And by the way, if you’re not doing one-on-ones, and you are gonna hear me repeat this over and over again, this is the only way to real sanity, in my opinion, is to schedule one-on-ones that are effective for dealing with problems before they happen and to make sure that your employees, your team, knows that there’s a safe place they can come talk to you at a given time. And I bet 90% of the things that they come to you in an ad hoc way, they’re actually just gonna save those up for the one-on-ones. We’re gonna try and get rid of this open door fallacy, and we’re gonna use one-on-ones.

 

Marcus: So if you’re getting bombarded constantly by your team, and you think, “Oh, this is my life,” it doesn’t have to be. Set up one-on-ones and then go into your calendar. And here’s the trick: You have to respect your calendar, or no one else will. I want you to go into your calendar and schedule thinking time, coding time, if that’s where you need to balance. Maybe planning time. Heck, time just to learn something. I want you to schedule every day, a 60 to 120-minute block where you don’t have anything else going on. You are at your computer, and you say, “This is my time to do the important thing that is always getting interrupted.” Time management is one of the most difficult things in the transition from programmer to manager. There are some great resources out there. We’ll put in the show notes, a webinar I did about time management for technical leaders. It was brutal for me.

 

Marcus: Now, you might be also thinking, “Well, Marcus, I could put the time on my calendar, but no one’s gonna respect it. Other people are still gonna book meetings over it, or they’re gonna walk in.” Well, this is where you’ve got to respect it more. First, you’ve gotta set that example. That means if people are just randomly putting meetings on your calendar, you need to learn to say no, or not now. You need to tell people, in advance, this time that you see is blocked out, that is sacred time. I am not gonna move it. Because otherwise, I can’t do my fundamental job. And my fundamental job is thinking, not coding. And thinking takes time and focus and quiet and a place to relax and frankly, just orient yourself.

 

Marcus: I also found tips and tricks … I hate to say this, but I’m going to. I found tips and tricks like coming in early on a Saturday sometimes helped, being there when no one else was at the office. These aren’t great habits, but when you’re trying to survive in a constant barrage of people who need your attention, you’ve gotta find some time when it’s just you, so you can think.

 

Marcus: Okay, all right I hope this was helpful. Good luck and congratulations on your new role. I’ll see you next time.