Be a Better Lead

As developers we have our tiers, ranks if you want to call them that. From the junior developer to the principal architect and everything between it. And the majority of us would be the senior level. Experience to do our job on our own with little to no need for guidance. Let’s look at the typical ranks we as developer go through:

• Junior Developer - right out of college or a coding bootcamp. Green as they come and will need guidance almost daily.
• Developer - for the most part they can code solo but still will need some guidance.
• Senior Developer - as mentioned before they can do their job with little to no guidance. They are also a great resource for developers and junior developers especially.
• Lead Developer - they are here to lead a project or a particular part of the project. Helping all the other developers deliver quality code.

We can go on to architects but for what I want to talk about today we are going to focus on developers. We are not talking about architects today, not saying they cannot develop they can and often do.

Let’s first break down the difference between leading and managing. I love to lead people but hate to manage them. There is a difference between the two. And before recent changes, my wife was a manager, and we would have this argument often. People need to be lead not managed. She argued for managed and why not she was a manager at the time. I would argue people need to be lead. We often see that photo (which for copyright reasons I am not posting here) of the difference. The boss is being pulled by their staff sitting behind their desk barking orders. Whereas the leader is up front doing the work with the team.

The long and the short of it is that a manager will tell a team what to do and let them do it. Whereas a leader will ask the team to do something with them, sharing in the work. I ask no one to do something I am not willing to do myself and neither should you. This is so true when it comes to developers. Earlier in my career I used to bitch and moan about developers and junior developers. I felt like I was an overpaid babysitter. I was approaching them all wrong. I was senior to them because of my skills and experience. But how did I get here? And my incorrect thoughts at the time was that I earned it so should they. How can they earn it if I am not helping them do so?

At one of the companies, I used to work at they had a junior developer group called the MDC. And this group was a great idea for any consulting company. And I give my former boss full credit for this idea. You can create a farm system of talent that you can grow all the while giving a better blended rate for any project. After a while when they matured, they would graduate in to working in one of our regions. Again, genius idea.

So as a senior developer jumping on to a project, we would get assigned a team of junior developers from the MDC. When I would start a project the first thing, I would ask each developers from the MDC was this:

I hate working with junior developers in the MDC, what are you going to do on this project to graduate out?

Harsh words I know. It was true I hated working with junior developers out of the MDC. It wasn’t because of them as individuals, it was never personal with any of them. I wanted them to grow I wanted them to be better. So when I dropped, what are you going to do on this project to graduate out? It was an opportunity for them and me. Can we make this happen? So, with this first conversation we set goals. Not like “go get this certification” but more of “hey you are leading stand up today.” We set these goals together and I made them write it out. Through the length of the project we made sure to hit them all. I would level with customers on the engagement that I was doing this. Most of them didn’t care and some even helped in the process. But, what I realized is that this is how I wanted to be lead. But, more so I didn’t want someone managing me.

Throughout my time as a senior developer, I had the honor to have all six junior developers graduate. This process of building developers up while building software is what it means to lead. So here are a few things to understand.

Every Developer is Different

First, their lives are not yours. Do not attempt to think you understand where they are coming from. Take the time to listen and understand what you can. A developer from an underrepresented group has a different experience. They face things you might not. Or they could be having personal struggles you don’t know about. I made this mistake before and am embarrassed to admit to it. This is tailoring your approach with some level of empathy. Now this doesn’t mean you have to be condescending or belittling.

Everyone’s Skills are not the Same

As every developer is different in one way or another so are their skills. I have met senior developers who have never written a unit test. I often wonder how they got to this level without this knowledge. You need to identify where they are and where you can help them move up to. Are they front-end only and want to explore the middle tier? Or are they a Java developer who wants some more experience with Angular. If the opportunity arises give them the chance to grow here. What you don’t want to do is to send them off to watch a YouTube video and then dump work on them to do. Pair up with them get them comfortable with what they want to grow into on the technical side.

Code Reviews

Code reviews are a chance to improve not to criticize. I was the worst with a code review. People who worked with me years ago know this. I would print the code and come to the meeting with a red Sharpie. We would play this game, “what’s wrong with your code?” I helped no one with this approach. In fact, this is why I rather do Team Up or Paired Programming instead of doing a code review. If your company does Paired Programming, then you know it’s like doing a code review as you are coding.

Work Yourself out of a Job

This one is tricky. Things you do when you lead others, needs to be what other need to learn. Often, I would ask another junior developer to do a peer code review. Sometimes they would have to review my code. This was awkward for them, but it was something they needed to learn. Something I had to learn the hard way. So, take the time and look at your task and pick one or two to show others how to do. From reviewing and approving a pull request to a code review. Or even reviewing a new way of doing something. Whatever it is show someone else how to do this. I mentioned earlier I used to assign the job of leading morning scrum to someone. This wasn’t because I was lazy but because others need to learn. If it makes sense to delegate something for others to grow do it. Make sure you show them how first.

Feedback Quick and Often

This is critical, feedback is not only to correct if need be but to offer praise. For the most part people want some praise for what they have done either in person or not. Some people are shy and don’t like to be put on the spot. Some love it and even crave it. If someone is running stand up flawlessly say so. If they are stepping up and helping others, again say so. I am a firm believer that positive works better than negative. When the feedback is to help someone course correct do this one on one. Calling someone out in this manner is counterproductive.

Finally

Encourage your company to hire junior or mid-level developers. I have recruiters reaching out to me all the time looking for everything senior level or higher. How do people get to that senior level without getting the chance to grow into it? Creating an environment of developing these people up helps not only them but our industry.