Leaders aren’t somehow superior to those they manage—you simply have a different role on the team. Leaders don’t know more than those they lead. Leaders serve the team members who are doing the bulk of the coding. They help the team members understand what other members are doing by facilitating communication. They help the team understand their overall priorities and objectives. Leaders help to keep the team members productive by removing the obstacles—no matter what they are. If a member can’t figure out how to solve a problem, leaders sit down with them and help them work it out. If a member needs to get set up to work from home because their mother is sick, leaders facilitate that. Leaders delegate authority and retain responsibility. Leaders need to learn to trust people to write code and yet stand up and take responsibility for that very code if it fails in the wild. How do you manage it? Personally, survey the team’s code by looking at it, asking them to defend it, and generally being on the look out for “code smell.” If you don’t feel confident drill into it with them until they can convince you that they’ve developed something solid.
Your motto needs to become “Communicate the obvious.” Don’t assume anybody knows anything. Say it out loud and send lots of email. Tell those you report to what you’re doing. Give everybody bad news early. If you have an integration environment that goes down, stand up and announce that it is down. Don’t assume others are going to notice it. Ask who is going to get it running again. Announce to the group that so-and-so is working on it. Ask so-and-so to tell you when it is working again. Announce to the group when it is working again. Etc. Run daily stand up meetings and go around the room and ask three questions: What have you done since the last stand up? What is preventing you from doing whatever is on your plate today? What will you be working on today? Keep these stand ups short and sweet. Break out into one-on-ones with people if they have issues that need to be worked. The important thing is to make sure everybody hears what’s going on within the team and has a chance to contribute things like “did you know there’s a library that already does that?”
Acknowledge the team’s accomplishments and hard work. There’s a ton of humility that comes with being a leader. You’ve got to admit that you can’t get it done yourself, and put yourself at the mercy of your team to do the bulk of the work. You need to thank them sincerely, and often publicly, for their contributions. Don’t know what to thank them for? “Catch them doing something right.” That is, just as you’d go through somebody’s code with a fine toothed comb while criticizing it, do the same but look for clever code, well documented code—whatever’s important to you. Find the good things they’re doing and stand up and say “you did a good job on this.” One of the most rewarding experiences you’ll gain from leading people is the feeling you get when you thank them for their work. When times are tough, sometimes it’s what keeps you coming in the morning.
Don’t ever humilate your colleagues. If you discover some bone-headed code that crashes the system repeatedly, always leave a side door open for escape. Talk to the programmer privately. Programmers are people too...you don’t know if something big is going on in their personal life. We all have problems. When you respect your team as people first, you will be able to count on their support, even when you don’t think you need it. The best way to gain approvals, from department heads, customers, quality groups, etc., that DONT respond to those requests, is to ask for rejection in writing. In other words, email your requests for approval stating that “unless otherwise noted in writing by so-and-so date, we will proceed with the following <purchase> <feature> <whatever>. CC everyone that is relevant. You will get what you need, or at least, you’ll have a tight documentation trail should problems arise in the future.
