I started my career as a software developer, because I love computers and I love building things. Building software, no matter the type of involvement, is an experience worth working toward. There are few things that can provide as much joy in such a short amount of time than seeing the text you’ve written come alive. In the last 5 years of my software development career, however, I’ve been leading teams of developers rather than just typing the lines of code that go into the software. Working with a team and building great things together is something I love regardless of the type of contribution I am making.
Now that I am transitioning back (at least for a time) into a primarily development role, I want to take some time and reflect on that change. I have enjoyed all of the work that I have done in my career, and I look forward to many more years building great things with great people.
I will never stop writing code. It’s too much fun to give up completely, but I also love people and working with people. For that reason, I enjoy leading teams of developers as well. I’ve spent these past 5 years trying to improve my leadership, not just for my own benefit, but for the benefit of my teams and the software we create. As many of you know, I blog so that I can share what I’ve learned with everyone (including my future self). Let’s talk about leadership.
Know Your Team
As a leader, it’s important that you know your team’s strengths as well as their weaknesses. This is not exactly a radical idea, but it’s one that I’ve seen ignored far too often. Every member of your team has goals, opinions, preferences, etc. They’re people. If you don’t know anything about them, you’re not leading your team. The best experiences I’ve had as a leader are always when I am communicating and soliciting feedback and ideas from everyone involved.
I make a point of getting to know my team. I make sure to lighten the mood, so I can meet the professionals as well as the people they are. If I know that certain people have tendencies toward certain things, that allows me to lead them better. It’s my job to make sure that they’re doing their job well and are happy about it.
A good friend of mine, Steve Smith, recently took on the role of CTO of Falafel Software, and I was chatting with him about that new role. He was commenting about getting to know his team and having discussions with them. I suggested he spend an hour or two pair programming with everyone he’ll be working with. This gives him the chance to talk with them and also learn how they like to work. It comes with a couple of very important benefits: it lets Steve write some code and it also lets him learn about the projects.
Know Your Projects
One of the most frustrating things as a developer is having to constantly explain and re-explain a project to a manager. Don’t be that guy. Make sure you know the project. You’re involved. Sure, you need to talk and ask about how things are going, but you should understand what’s being done. You’re not there to tell people what to do. You’re there to help people get those things done.
If you need to sit down and pair with your team, do it! Sit with the designers and help them design. Sit with the developers and help them code. Work with the team. You’re a part of the team.
When I am leading a team, I am with the team. I’m only in my office when I need a quiet space. The rest of my time, I am sitting right next to the team. If I roll my chair back, I’m bumping into a developer or a designer. That’s my ideal situation. When anything happens in the project, I need to at least be aware about it, and constantly pestering my team for status updates is not an appropriate way to do that. It wastes their time and reiterates that my time is more valuable than theirs (completely false).
Solicit Feedback
Clearly, before I make a decision, it’s a good idea to make sure that the team has a chance to weigh in on things. When you are a leader, it is likely not a democracy. Make sure you know that and make sure the team knows that. If a decision I make will impact the team, I at least alert them to it before the decision is made. This gives the chance for cries of outrage. More often, I prefer to actually have a quick discussion before making my decision.
One topic that comes up all too often is physical versus digital kanban boards. This often has to do with the circumstances of the project. Obviously if everyone involved in the project is in the same room, a physical kanban board has a lot of benefits, but if you’ve got a single remote user, you’ll lean the other way. I’ve had a few developers with strong opinions one way or the other, so I try to accommodate when I can. I know which to use for each project because of the developers who are on them, because I get to know my team.
Asking for feedback allows the team involvement in the decisions and gives them some stake in things. Make sure you’re listening and taking their suggestions to hear. I know that I never know the best approach from the start. I chose my team, because they’re smart and can help me make the right choices. Often the right choice is based on the team, so you really should ask the team.
Identify Leaders
As a leader, you need to help other leaders become better leaders. Often leadership qualities are on your team. That’s great for you! Let them take on some leadership. Give them the chance to lead some discussions, meetings, projects, etc. It will help them (and the team) to build great things. Sharing responsibilities with others will let you focus more, and will let them grow as leaders. You’ll need peers to help you lead others and people to cover for you when you’re busy or out of town.
Your team is often better at leading than you (or they) might expect. A leader who has never had the chance to lead may not know they can. If you can identify and grow leadership in your team, you will have empowered your team to make good decisions. The more your team can do on their own, the more you (and the entire team) are able to accomplish. Build more. Build better. Build the leadership in your team. It’s there already. You just need to find it and grow it.
Lead the Team
Yes, this also sounds kind of silly to mention here, but I am serious. There is a big difference between leading and directing. If you’re leading, you’re out front blazing a trail. If you’re directing, managing, or even guiding, you don’t have to be out front. When you’re leading a team, you’re setting examples. You’re doing things the right way (whatever that is for your project). You’re not cutting corners or doing a sloppy job. It’s your job to not only help, but to make sure that everyone else can follow in your footsteps to achieve success.
How you lead a team is extremely important. If you cut corners, your team will as well. If you have a sour attitude about the project, that will spread. If you’re lethargic and bored by the project, you won’t be seeing an interested, engaged team. Be the team you want your team to be. If you don’t you can’t expect any better from anyone else. This doesn’t mean you need to be the best developer, designer, tester, copy-editor, or anything else. You just need to be willing to put forth good, positive effort. You’ll be amazed at the results. When I do that right with a project, I am always impressed with how the whole teams steps up to every challenge. Whenever I’ve cut a corner, I see it repeated. It’s just not worth doing.
Set an example. Be a leader to emulate. Stay positive. Keep things moving smoothly. That is your job. Leading is hard. Doing it right is harder, but it’s very worth it. If you do it right, your team will do amazing work that will have you in awe. With that said, I’d like to thank all of the developers and designers who have ever been on my teams. I was glad to have every one of you on my teams, and you did fantastic work. (You all knew that already though!) We all achieve some great things! Now it’s my turn again!
Comments