Getting to Know You – The Key to Successful Leadership

Episode 7

Good leadership looks like a flock of birds. That doesn’t mean everyone on the team has to dress in feathers, rather it means leadership is dynamic, shifting, and also tight knit. In this episode of Programming Leadership, Marcus talks about what it takes to be a good leader and provides real solutions on how to build trust and gain feedback from your team.

 

 

Show Notes

• Being a young leader over a team with more experience requires emotional intelligence and collaboration in order to build trust and confidence.
• Truly get to know your employees. It helps build trust and reduces negative impressions.
• “Preconceptions are relationships based on past interactions with people that remind us of someone else.” – Marcus
• Followership is not inferior to leadership.
• One-on-one meetings should be frequent, consistent and not canceled.
• One-on-one meetings are important for building trust and gaining real feedback.

Links:

• GitPrime.com

Transcript

Speaker 1:  Welcome to the Programming Leadership Podcast, where we help great coders become skilled leaders, and build happy, high performing software teams.

 

Marcus:  Welcome to the Programming Leadership Podcast. I’m Marcus Blankenship. I want to take a question from the audience today, start a little bit differently than we have in the past. I was speaking with someone and they asked me this question. Let me set the context. It was a software architect who was younger, maybe 30, and they were going to be moving into a leadership and management position, and they asked me if age was going to be a problem for them. In fact, they particularly said, “Will older people on the team have a problem with me being younger?”

 

Marcus:  Of course, I can’t exactly say yes or no, but here’s my answer. I said there’s a few aspects at play. The first is, is that oftentimes younger managers, and myself included, tend to come off really strong when we are feeling a little insecure about our position. That means we’re more likely to tell than to ask. We’re more likely to dictate and announce, and in fact, to be honest, we’re more likely to go away and plan and architect, and draw up beautiful ideas, and put them into long documents, and then give them to the team with the hopes that then the team will execute, because we see that as our function in leadership, as doing the thinking work. And when a team of smart people, especially maybe that are a little bit older, or if you’re like me, a lot older than 30, receives such plans, such architectures, well, sometimes we don’t respond to it as graciously and thankfully as the leader might expect.

 

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. Story points, velocity, burndown charts, burn up 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.

 

Marcus:  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. 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 for a demo at GitPrime.com.

 

Marcus:  The first tip I … If you are a younger software leader, if you are younger than your team by, say, 10 years, I want to offer this advice in this show. It’s just for you. The first thing is, and this advice goes for leaders of all ages, but I think there’s a particular tendency when we’re younger. First, remember that you actually don’t have anything to prove. You’re in the role. Well, let me take that back. You do have something to prove. The thing to prove is that you’re not a jackass. I apologize if that’s offensive. I don’t mean to be, but the first thing your new team is going to be looking for is, are you going to be heavy handed? Are you going to come in and dictate? And boy, that is exactly what I did, and it’s what I see a lot of software managers doing who don’t feel really confident about where they fit in the team.

 

Marcus:  So they go away, they drop huge plans, they bring them to their team. Even though they say, “Oh, this is just a suggestion,” the reality is is that their team takes it as, “This is gospel. This is the way we’re going to do it,” and people imagine that there’s no room for other ideas or negotiation because you’ve gone away and you’ve created this thing and it looks like it solves all the problems. That has a lot of problems, but it’s particularly hard for people who have more experience than you to not be consulted on how that problem should be addressed. So I guess that’s the first thing to recognize, is that if you come off too strong, do too much telling, and you are a person who is new to the role or who has a lot of senior people working for you, they may object to that. Or if you’re like the team that I managed, I’ll be honest, they might just ignore you, and I have had that happen more than once, and it is hard to stomach when your team goes, “Oh yeah. That’s cute. Run back and attend the meeting, and we’ll get the real work done.” Not saying they should do that, but when you start by being too large rather than too small, that’s that’s what often happens, so sometimes new managers tend to come off too strong.

 

Marcus:  The other thing that can happen is that there is often an immediate reaction based on just age and appearance. This is just the reality. If someone were to come along who was 25 and tell me, “Marcus, you’re 48, and I’m your boss, and you’re going to do what I say,” I would immediately look at that person and think, “You don’t even know anything about life.” Now, I wouldn’t say that, because for a lot of reasons I wouldn’t say that, but here’s the thing. I would guarantee that the people on your team, if you’re younger, are having some sort of initial reaction, and you then could think about starting a little bit in the negative.

 

Marcus:  So what they’re going to be watching for you is, again, are you going to come in and act like you know it all? Are you going to come in and do a lot of telling and a lot of upfront design, a lot of problem solving, and just leave them to implementation? You know, the easier thing, because you know how modern systems should be built, and they’re the old timers. Maybe for a lot of reasons you perceive that the group doesn’t want to be involved with problem solving. I think that’s probably a learned behavior, so here’s what I’m going to suggest. When someone confronts you with that look of judgment based on nothing more than your age, your appearance, your hair color, whatever it is, the judgment, I want you to step back and try and detach from the reaction that you feel about that, which is usually a negative reaction.

 

Marcus:  We don’t like being judged. I don’t blame you. I don’t like being judged, but if you can step back and you can think to yourself, “All right, that person has a viewpoint of me. It’s not the correct viewpoint, and now I want to get to know them. I want to win them over, and I want to prove them wrong.” Yes, they have an initial viewpoint, but most people’s first impressions are relatively loosely held. If you go on to reinforce those initial behaviors, then they’re going to be harder to break.

 

Marcus:  But let’s say that … I guess it could be the same way as if a young person, somebody who’s 25, looked at me and said, “Oh, I now work for Marcus. He’s 48 years old, and my guess is that he’s not very up to date with modern coding techniques. He probably did a lot of mainframe work. He’s probably going to want a lot of status reports.” They might have all that and that might be a really negative connotation on the first impression, but if I come alongside them and show them, not that I have to win them over by being a great programmer, but I show them that I know what I’m talking about, I show them I understand their world, and here’s the thing. This is actually the key to the whole element. If I really try and get to know them, well, why does that matter if we really try and get to know people? Because then they actually form impressions based on experiences, not on the outward impression that we give based on age, based on dress, based on 1,000 other factors.

 

Marcus:  I know that there’s a lot of people who are listening to the show today who are being judged unfairly by those around them, and I’m not going to tell you it’s fair. It’s frustrating, but I think in many ways we can’t change the other person. We can only change us, and so we have to step back and we have to imagine we’re not going to be that stereotype. As an old guy, I’m not going to be stuck in my ways. I’m not going to propose COBOL and Perl as the best solutions in the world, and I’m really going to avoid telling those “back in my day” kind of stories. And I’m going to do that because I want the other person to know that I see them here and now. I’m not living in the past where I’m just remembering my glory days as a programmer, but I’m interacting with them today based on who they are, based on what the work is right in front of us. And in doing so, I hope to create a relationship that’s based on today, and of course you’re probably hearing me use those words “today” in the past because preconceptions are relationships based on past interactions with people that remind us of someone else.

 

Marcus:  In fact, I’m guessing that this young engineering manager who I spoke with today, he’s got team members that are older and he’s probably gotten some looks and some smells based on their experience with younger leaders and the arrogance and pitfalls that younger leaders sometimes fall into. We don’t have to fall into those things, so I know that ageism is a thing, sexism is a thing. The world is imperfect, but we can be more aware of our own responses and we can then set out to say we’re going to act in a certain way no matter how the other person acts towards us. And I believe that’s probably one of the most fundamental things we can do to win them over.

 

Marcus:  All right. This actually leads into the topic I want to spend a few minutes on today, and that’s the primary channel you’re going to win people over. Now, this phrase, “win people over,” sounds awfully salesy, I get it, but that’s not what I mean. If you’re going to talk, if we’re going to talk together on this show about leadership, I feel we have to also talk about followership. And that word “followership,” some people react to it really badly. You probably hear it and you might just hate it. In fact, I was just talking with someone the other day who said, “I like leadership but I don’t like to follow anyone.”

 

Marcus:  Followership, I think, is a natural reaction to situations where people trust each other, where one person rises even momentarily as a leader, and the group listens, considers and then acts on their ideas. In fact, in a lot of ways I think great leadership looks like a flock of birds, okay? The next time you see a flock of birds in the sky, I want you to notice that, especially if they’re zigging and zagging, the leadership position, the bird at the front is changing, and so it’s almost like leadership gets passed around and the flock moves dynamically.

 

Marcus:  That’s kind of a weird segue into this one particular channel that is so important. It’s your one on one meeting. Your one on one meeting is the single best way to connect with people, to solve problems early, and frankly to get people on your side and to really understand them. It’s the foundational practice, in my opinion, of relational leadership, and that’s what we want to achieve, is leadership not based on hierarchy, not based on formal authority. That’s where management comes in. But leadership, because people trust you, and you trust them, and you lead them, and sometimes you follow them as well.

 

Marcus:  Your one on one meeting, I’m going to give you the top tips about it, okay? Number one: Have it frequently. I like weekly. If I could do 30 to 60 minutes with each person on my team, I would absolutely advocate for that. If you can’t, and there are some realities that mean you can’t, I’d like to suggest that you do 30 minutes with each person on your team for an hour every other week. Don’t do it monthly. Don’t do it quarterly. That’s not often enough.

 

Marcus:  Imagine a time when you were courting somebody of the opposite sex. You were trying to get their attention. You were going on dates, and you’re going on dates. You don’t have a monthly date. I wouldn’t. When I was trying to get my wife’s attention so that she’d marry me, and we were dating, I didn’t say, “Well, let’s date monthly.” Or, “Let’s date biweekly.” I was like, “Look, let’s go out three times a week.” Right? More is better. You get it, and that’s because you are creating a relationship. You’re getting to know each other, and you’re enjoying spending time with one another. You’re connecting on a whole bunch of different levels, so a weekly one on one meeting, I think, is the best chance you have for creating a great relationship with each member of your team.

 

Marcus:  Now, I know that’s hard, so let’s move to the second point here, and you’ve got to have these things consistently. And by consistently, I do mean week after week, month after month, but there’s more to it than that. I also mean the idea that when you put that one on one meeting on the calendar, that’s a promise, and I don’t want you to break that promise. That calendar invite, have you ever thought about it? That’s a promise that says, “We’re going to meet privately at this time.” And guaranteed, almost every time, that other person is holding onto a few things they intend to bring to the one on one. So you need to be consistent, not just in how often you set them up, but in the fact that this should be the last meeting that you try and reschedule.

 

Marcus:  Now, I get it. Sometimes rescheduling has to happen, but don’t just cancel it, and in fact, please, for the love of Pete, don’t just get swamped and say to the person, “We don’t have anything to talk about this week, right? I don’t have anything. You don’t have anything either, right? Okay. Okay, great. Well let’s just not worry about it.” That sends the wrong message. Could you imagine if you did that with somebody you were dating? “We don’t have anything to talk about tonight at our date, so let’s just skip it.” That sends the message of, “I really, really don’t want to meet with you, and you’re an imposition,” and that’s not going to lead to any sort of great long term relationship, so I want you to remember that that promise is so important to that other person.

 

Marcus:  In fact, a friend of mine once told me, he said, “When my boss cancels my one on one meeting or moves them, I don’t know what to think. I really wonder if he’s mad at me, or maybe something in the business is kind of chaotic and out of control, or maybe he can’t even control his own schedule. I mean, if he can’t control his own schedule, how can he provide for me? How can he move the resources I need? Or maybe he’s mad and he’s got bad news, and he doesn’t know how to talk to me about it. At the end of the day, I just feel bad when my meeting is moved.” The feeling when somebody cancels that meeting with you is never going to be positive, all right? It never feels good when somebody cancels a one on one meeting with you because you’re really going to make up reasons and interpret why.

 

Marcus:  So not only do your meetings have to be frequent and they have to be consistent, but you have to remember the goal. The goal is to build trust. Everything about that meeting should be to build trust with the other person. To get trust, to give trust. It should be about improving the relationship. It’s not a status meeting, but you can talk about work. In fact, I think you should talk about work. I don’t believe in these one on ones where we just talk about what we did this weekend, or our career aspirations. Come on. We are in a work relationship. We have work stuff to talk about. Let’s have those work conversations.

 

Marcus:  There should be feedback. This is a so important, perfect time for you to give feedback to that other person that you haven’t already given about what you’re seeing them do, and this is so important because if you don’t have a regular cadence of giving feedback, then you’re going to save it up and you’re just going to drop it on them like a bomb, maybe at their annual evaluation or out of the middle of nowhere.

 

Marcus:  Let me give you an illustration. If somebody comes to you and says, “Hey Marcus. Yesterday I saw you doing this, and I didn’t understand it. What’s going on there?” Or somebody says, “Hey Marcus. Three months ago I observed you doing this, and I didn’t understand it. What’s going on there?” The element of time changes that, at least for me, completely, because if someone won’t come and talk to me when there’s a problem, and your weekly meeting is a pressure release valve to make sure that at least weekly we are having an honest conversation, if someone won’t come and talk to me when there’s a problem and they wait months, I don’t trust that person. Would you? Would you trust somebody who withheld feedback? It’s like they’re keeping score. It’s like they’re keeping a little tally of your errors so that maybe one day they could just walk up to you and fire you. I mean, that’s what it would feel like to me, and so your one on one meeting is a time to drop your guard. It’s a time to give honest feedback, to be curious, to ask, “What’s going on there?” Trying not to assume you know, and it’s a time to get feedback.

 

Marcus:  Virtually every engineering manager I know tells me they do not receive enough feedback from their team to be helpful and to help them improve. They get feedback from their team when there’s big problems, but when things are going okay or there’s just little problems, they will ask, “How’s it going?” And of course you know whenever you ask, “How’s it going?” Or, “How are you today?” You get what I call the checking cashier. You get what I call the checkout line answer, and that answer is, “Everything’s fine.” That’s the face we put on. The “everything’s fine” face.

 

Marcus:  If you don’t get feedback about how you’re doing and what your team needs and how they perceive you, you’re driving blind, right? You can not see the problems before they hit you sideways and people start to leave. You will not know when projects have small problems until there are big problems. When people are a little dissatisfied, as Michael Lopp, known as Rands on the Internet, puts it, they’re putting their shields down and they’re considering other employment options, you won’t know that until decisions get made or it is too late to change anything.

 

Marcus:  And so I want to teach you, before we go, we’re going to round out this episode with a technique that you can use to get better feedback from your team, and that technique is something I call triangulation. Instead of asking, “Do you have any feedback for me?” Or the ever popular, “Is there anything I can improve?” All fine questions, but generally useless because the answer in any sufficient power hierarchy is going to be, “No. Everything’s fine.” Instead, try asking questions like this. “What would you have done in that situation with the client last week?” Or, “The project launched. How do you think we could have gotten better results? Or maybe what could I have adjusted so that we got better results?” Or, “I noticed when that meeting last week that somebody brought up a really hard topic. What would you have done if you were in my shoes?” Those kinds of questions allow you and I to sit on the same side of the table and look at a third thing. That’s why I call it triangulation.

 

Marcus:  The third thing is the problem or the situation that we want to get feedback on. Yes, you are going to get feedback on your own performance, but instead of saying, “How did I do in that meeting?” You’re saying, “I think it could have gone better. What would you have done if you were in my shoes?” You see how that gives you feedback? That tells you what the other person’s thought process was about your work, and in many ways that’s what’s so important. Having that dialogue is not only bi-directionally respectful. You’re asking, “Hey, I saw this.” Not, “How could I have improved?” But, “What would you have done over here? What ideas do you have for that situation? Where did you see me working in a certain way? And maybe what other options did I not spot in the moment?”

 

Marcus:  I want to just bring that up because generally when we can talk about situations, we can avoid words that seems scary to say, and those are the blaming words. “You’re not. You’re not doing this. You’re not doing that.” That feels a lot like blaming to me. And instead, if we can say, “Well, maybe if we tried this approach in that situation,” it feels like we can be more collaborative and we can also get different perspectives on our work. As engineering managers and leaders, I guarantee that you need this different perspectives, these different types of ideas, in order to perform and to know what your team thinks about you.

 

Marcus:  All right. This has been the Programming Leadership Podcast. Find us where all fine podcasts are played, and please do us a favor and give us a little love on social media. Leave us a review on iTunes or Google Play or Spotify. You can find us there. Thanks.

 

Speaker 1:  Thank you for listening to Programming Leadership. You can keep up with the latest on the podcast at www.programmingleadership.com, and on iTunes, Spotify, Google Play, or wherever fine podcasts are distributed. Thanks again for listening and we’ll see you next time.

 

Speaker 1:  This has been a HumblePod Production. Stay humble.