Leaders Need to Be Coaches to Enable Developer Effectiveness

Transcript

Shane Hastie: Hey folks. Before we get into today's podcast, I wanted to share that InfoQ's International Software Development Conference, QCon, will be back in San Francisco from October 2 to 6. QCon will share real-world technical talks from innovative senior software development practitioners on applying emerging patterns and practices to address current challenges. Learn more at qconsf.com. We hope to see you there.

Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I'm sitting down with Phil Alves. Phil, welcome. Thanks for taking the time to talk to us today.

Phil Alves: Oh, no problem. Thanks for having me.

Shane Hastie: The place I like to start with my guests is, "Who's Phil?"

Introductions [00:49]

Phil Alves: I'm a entrepreneur, a below-average software developer. I love to build products, and I have multiple companies in my career. I also have hobbies. I love flying airplanes, and I love Brazilian jiu-jitsu. I'm Brazilian myself, even though I've been living in the United States for 10-plus years. Yeah, so that's kind of like me in a nutshell.

Shane Hastie: So the reason we got together is some of the work you're doing on technical leaders be better coaches, coaching the people around them. What does it mean for a leader to be a coach?

What does it mean for a leader to be a coach? [01:29]

Phil Alves: I like to make the differentiation between training and coaching. So training is usually the syllabus from A to B to C. We're teaching a topic. Coaching, it's more like we were talking to the person that we're coaching or mentoring. You're understanding where they are, and you're helping them with the problems that they have right now. It's a lot more customizable. I think sports knowledge works very well for building software. I see, let's say, the coach of an NBA team. He's there at the team, he's looking at exactly what's happening right now, and he's bringing his players in and say, "Hey, do this different. We can do this better."

So that's what coaching is, and I feel like we don't have a lot of tools and ways to do that in software development, even though we have been building software for 20-, 30-plus years. So I want to do better there. The way that I figured out that we are not that good is when I had a software team that grew from 10 to 100 and things start to fall apart because when your team is small, it's very easy. Everyone is working together, and you can see, but once things grow and then you start adding people, just training won't do it. You need to graduate from training to coach, and I'm building a product to help people do just that. The product is called DevStats.

Shane Hastie: DevStats, what are some of the stats? What are some of the things we can measure in this space?

Six metrics for development effectiveness [02:51]

Phil Alves: I'd like to start benchmarking where your development team is against industry standards. The industry standards coming from research that were done by Google and Microsoft, like the DORA Metric research, the space framework, and the six numbers that I like the most, it's planning accuracy. How well are you planning? What's the percent of the things that we say we would do that you actually got done? And more important is where we want the number to be, because if the numbers in 100%, there's a problem. Going back with our sport analogy, it means that you're going just for the layups. It means that you're not taking risks enough. So where should that number be? And a good place for that number to be is 80%. That's the sweet spot of where we want that number to be.

The next thing we look at is change in the failure rate. What's the percent of the things that we move to production that they're breaking? So we're looking at that, and you're like, "How well we are doing?" And again, if things never break, it probably means they're moving too slow. So we want that below 10%, 15% and then we track that across teams and be like, "Okay, your change failure rate here is 5 or 6." And that's what we look at.

The next number of the six that are the main ones that I like to look at is cycle time. How long does it take from when we start working on something until when that code gets merged?

The next one, it's deploy frequent. How frequent are we making deploys? The more efficient a team is, the more frequent they're going to deploy. High-performing teams, very-high performing teams like GitHub team, they're performing every single day. But more realistically, if you are deploying every week, you're in a very good place.

Then we look at code review size. That's one of my favorite numbers because that's about collaboration and that's about making sure that we are not biting too much. So how big is each piece of code that's going to code review? It's actually real code review happening, and we want that number to be 400 lines of code max. Most times, when people connect our tool to check where they are, they're over 3,000 lines of code. There's no way a developer is going to be able to review 3,000 lines of code.

Then we look at rework rate. What's the rate of things that we did that we are having to redo it over and over again? And that maybe it's because of bad planning, it's because of things they're changing, or for every reason.

Indicators of individual effectiveness [05:05]

So there's many other things that the software track, but those are the six main numbers that I like to look at a team level, and then it's called DevStats. So I like to look at numbers at the dev level. So at the individual level, I'm looking at how well is his collaboration, like how many PRs he review, how many PRs he comments, what's the size of his own PR, his own pull request. The more senior the developer, the more I want him reviewing work and helping other people progress. So his biggest impact, it's not actually writing code himself, but it's helping other people get better at writing code. That's something that's very hard for teams to understand, and it's a mindset shift because sometimes senior developers, and again, I see that happen all the time, they would feel like their actual work's getting behind when they're trying to help other people. The way that we track, we want to show their impact not only in coding production but the impact that they did with the other people. So we look at collaboration.

We also look at how many pull requests they create, how many issues they resolve, how often they're committing, we want them to commit, and overall, what were they able to accomplish. So those are the numbers that we look at from the team level to the individual level, that allows then the coach to look at those numbers. Let's say, again, I'm going to keep going back to sport knowledge. If you keep missing the three points, then I have to go and coach you on the... Let's get the three points right. Here's the same thing. If I see a senior developer not doing code review, I'm like, "Your biggest value is bringing other people up. I need you to improve your code review. I need you to do more review and less coding." So that's the numbers that I look at.

Shane Hastie: How do we make it safe to record these types of numbers? Because in many organizations, metrics get gained all the time. How do we make it safe? How do we make it real?

The secret for high-performing development teams is a strong culture [06:53]

Phil Alves: Yeah. I think the foundation before we look at any kind of numbers is your culture. The secret for high-performing development teams, it's a strong culture. It's a culture of where people can trust each other, where they know they're not going to be shut down, where they know that they can be real, where they don't have to lie. Where if the numbers are bad, everyone's going to come together to fix the numbers, not to point the fault, because it's usually like, here's what people don't realize, when something is wrong, it's not a person's fault, it's a process issue. There's a process that's wrong that we have to fix. Good cultures know that.

So when they look at numbers, they understand, "Okay, there's something wrong with our process. What can we do better here?" So it's very hard because you are only going to be high-performing if you have a great culture. It doesn't matter how many tools you try to put on top to track what your people are doing. The foundation, it is going to be the great culture. Then the tools are just like enhancers, and it takes time, it takes experience. Honestly, I don't know how to teach people how to build an amazing culture, but I know that's the foundation to any high-performing team, to any tools that can actually track numbers.

Shane Hastie: Thinking of our audience, the technical influence, or a technical leader, certainly some of the things that we've talked about and the metrics, they're going to be interesting. They're going to be useful. I personally totally agree with you that culture is the foundation. How do we build that culture? How do we nurture that culture? Perhaps, is a better term.

How to nurture culture? [08:21]

Phil Alves: I think it's in the day-to-day with how you react to when things happen. It's how you treat people, how you react to problems. Each culture is different, but the values they have to be set. Let's say, if someone that's not following those values, you have to be willing to hire and to fire based on the values that you set. So sometimes you have a superstar that doesn't align with the values that you set. So you either change your values or you fire the superstar. You have to do that because if people don't believe that the culture... Culture is the way we do things here. It doesn't matter if you're having the wow or not or what you have in the wow. Culture is the way that things happen at a company. You just have to make sure that in the day-to-day the way that things are happening, it's to build people and to build trust, not to destroy people and destroy trust.

Shane Hastie: It sounds so easy.

Phil Alves: Yeah, sure.

Shane Hastie: If I'm in that, and I love what you're saying about the role of the senior developer is to help others be better, many of the people who are in that position or who've moved into that position have got into that senior position because they care about doing the work. How do you help that person become a good mentor, coach, guide?

Moving from contributor to coach [09:39]

Phil Alves: Yeah, it's not that he's going to start doing the work. It's that he has to... The percent of the time that he's doing the work and the percent of the time that he's bringing other people up have to be split. He's still probably going to take the most challenging pieces. But the success of a senior person, in my opinion, is how many other people can you bring up. A success of a leader is how many other leaders can you create. You can be the leader that you wish you had when you're coming at the latter. So that's what you do. I think, especially in the technical space, many times people don't have a leader that sit with them and tell them, "Hey, this is how you can simplify this." One thing that I see most of the time, mid-level developers overcomplicate stuff.

It's like the junior developer makes things simple. Mid-level developers make things complex. Senior developers make things simple. It goes like that cycle. So you have to be sitting with those mid-level people and help them simplify, help them grow. They also have to be in an organization to let you do that, or in some way you have to be able to show to your organization that that's your value add, is because even if I'm very good at doing something, if I bring three other people up, I'm not going to make the work of three people. Especially if I'm avoiding helping these people avoid big mistakes, if I'm helping them move along the way, so I know it's challenging. Working with people is a lot harder than working with technology. My computer does exactly what I tell it to do. Even myself, I like to call myself a below-average coder, and when I'm in code, the computer does what I want it to do, but people don't. So that's another skew to do it.

So you have to develop that. But there's a lot of growth that come from that space and from being able to migrate a little bit more into the mentor and the coach. That's how you go from a senior engineer to VP of Engineering, because then the VP of Engineering is really their coach. Then I feel like you still have to be looking at pull request size. You still have to be looking at how codes were written, you still have to be helping with code review, and you have to be there coaching your players.

Shane Hastie: Something that you've been quoted as saying is moving from developer mindset to developer skillset or building developer mindset and develop skillset. What do you mean by that?

The developer mindset is about developing people [11:48]

Phil Alves: You have to get in a place where you're not only writing software but you are developing people. Developing software is a thing, but developing people is another thing. I think if you can do the transition as a developer, you're going to grow a lot. Another thing is, you can get from a place of writing stuff to influencing software. Like a senior person or a leader, you can influence what's going to be done, how it's going to be done, why, what's better. I personally think that's a better place to be, where you're not just writing stuff but you are influencing, deciding, and helping shape a vision of how products are going to look like or how a team's going to look like. That's a good place to be.

Shane Hastie: Another thing, you've touched a number of times on simplicity, and you mentioned the mid-level developer has a tendency to make things complex. How do we coach people? How do we teach people? How do we support people in that simple is good mindset? But not too simple perhaps.

Simplicity is the highest degree of sophistication [12:50]

Phil Alves: I think simplicity is the biggest degree of sophistication. I didn't say that. I don't know who said that, but it's somewhere I read that and I kept repeating like, "Our biggest value in my organization is keeping it simple." What happens is, when we start learning a lot of stuff, we want to use everything that we learn, but we have to make sure that we are just doing what's necessary for the task. I think the way we coach that, it's by showing people how much easier it is to onboard someone into a product that kept things simple. It's showing people that the most senior person that gets the biggest salary is writing simple stuff. I'm like, "Look, this is how I do it." You don't have to overcomplicate because you learned about this somewhere or because you think that that gives you more value. The biggest value it is to get software to market quick and to be able to onboard team members quick.

What I like to say is that at the end of the day, we're building products, and we have to think, "How can I build a product as fast as I can?" So I know it's a hard concept, and I think in the past years we made things a lot more complicated with all the money that was in the tech world because we had so much money. Then there's things with hundreds and hundreds of developers. But now that the money's tight, people are going back to how can I simplify this? How can I do more with less?

But I feel like that was always the way to go, and is that we made a detour into the wrong direction, where we're overcomplicated. We keep saying that we don't have enough developers. Is it because we're complicating stuff so much that we always need hundreds of developers to do any little thing, so we really need to? But now where people have less resources, they have to do things with less, I see a big point to simplicity. But in the last six, seven years, I saw things getting more and more complex, and people want to adding more and more pieces. I guess it goes in cycles.

Shane Hastie: How do we really support our people? As a technical leader, as a senior dev, what does it mean to really support the people that work with me?

Supporting others as technical leader [14:48]

Phil Alves: I think it meant that you are coaching, you are getting to what they're doing. You're not leaving them alone. You are there for them, and you're looking at the right things, the right data points that's going to help that person be better. For example, if their pull requests are too big, you're helping them break down tasks in smaller tasks, you're helping them plan to that. You're showing how you do it. So now they're having smaller pull requests, and I think, again, it's about doing by example, the best way that I know about teaching anything, do it together. Let me show you how I do it. Come here and shadow me. Or let's do a pair programming. Let's get better at this. But also just giving you that person a place of safety where they can raise their hand. They can say, "I don't know."

Another thing that I feel like senior people are very good at saying, it's I don't know. Junior and mid-level people are not very good at doing that because they're afraid of looking stupid. They're afraid of say, "I don't know." So getting that person that you're mentoring and that you are coaching to a place where they start feeling comfortable saying, I don't know, or they hear you and see you saying, I don't know, and being humble, that's where we're going to really help someone develop. Because if they're not comfortable to ask for help to say, I don't know, to look at their data points, where's good? What's bad? To be open and be vulnerable, it's going to be very hard to help someone grow.

Shane Hastie: These are not skills that we typically teach developers in their journey to becoming a senior developer. So how do I learn to coach? How do I learn to teach others?

Phil Alves: By doing. You learn from people, from good coaches. I believe if you don't have a good coach, maybe you should try to find a job where you have one if you want to be a great coach one day. So that's what I honestly believe. You learn from other people. You learn from books. You learn by doing. Books are great, but we can talk about theory all day long, but only when people actually start doing and it started reflecting what they did that they're going to get better at. I can't read everything about flying an airplane, but unless I go fly the airplane, I'm not ever going to become a pilot. That's how things work.

Shane Hastie: There've been some interesting points and great ideas in this conversation. If people want to continue the conversation, where do they find you?

Phil Alves: You can find me at philalves.com, my website. I'm also on LinkedIn, and they could also go and try DevStats at devstats.com. It's pretrial. We don't even ask a credit card, and they can start looking at those data points and how you can better mentor their developers.

Shane Hastie: Thank you so much.

Mentioned

• DevStats
• Phil Alves' website