Unquiet Desperation

photo credit: Jonathan D. Blundell

Working as a team lead in any company is especially challenging. A lead developer straddles the gap between the coders and management, forced to take communication from one side and relay it in a manner the other can understand. It’s tricky business, and it’s not something you learn in school.

Here are a few tips I’ve picked up in the last few years, some of them learned the hard way. I hope they’ll serve you well.

1. Provide Solutions: Management is looking for your expertise, even when they think they know better. Temper your speech. It’s easy to get into the habit of saying “No, that won’t work because…” Don’t throw up barriers. You’ve gotten this far in your career because you’re good at what you do, so use your experience to find the creative solution.
2. Accept Input: Listen to your developers. There are days that they’ll know more about the current state of the codebase than you well. If you are lucky, you are leading people who are talented in disciplines that you are not. Listen to these people, accept their input.
3. Make The Call: Eventually, the discussion has to end. Take the data and make the best decision you can. That’s your job.
4. Play It Straight: Be honest. When you screw up, take the blame. When it’s your team, deal with it.  Trying to hide errors just compounds the problem. Without honesty there can be no trust.
5. Share Knowledge: The most fun I have with my team at Mahalo is when we are talking about tech, sharing ideas, new code, and new methods of getting the job done. This is real team-building. As developer, we prize knowledge above most other things. Share it with your team. Learn from them as well. Don’t be afraid to ask someone to teach you a skill you’ve wanted to learn.
6. Keep It Short: Management doesn’t really care how an HTTP Request Handler works.  Keep your explanations short and to the point. Ask if they want more detail. Understand that speaking techie will alienate non-techies, and will cause a slight distrust of what you’re saying. If you cannot avoid giving a technical answer, keep it short and sweet.  It’s not their job to know how it works, they just want to know it works.
7. Choose Your Battles: Your development team will inevitably want things that management cannot provide, and management will always mandate things that are not easy to do. It’s your job to find the middle ground. That will usually mean compromise, and while it’s not pretty, it’s how the sausage is made.  Save the digging in of heels for when you really need it.  An extra button or a different way of processing a form is not worth the trouble, in general, but a new form that causes the entire database to change is worth the fight. You’re not just there to take orders…you’re the caretaker of the project. Give feedback, and if you are overruled, determine how far you’re willing to take it. Be realistic in your assessment: is it a true battle to be fought or merely an inconvenience?
8. Keep A Journal: Keep a journal of the projects you run. Take notes, so you can remember why decisions were made. There will be times that you’ll look at some piece of code and you’ll have no idea why it’s doing what it’s doing. Your journal will save you from the ever-embarrassing “I dunno.”