Motley: To be a lead developer, technical skills are absolutely the most important. Everything else is secondary, tertiary, and whatever word comes next.
Maven: A lead developer must lead from several different perspectives, including people, process, and technology. To properly balance technology and people, build a great team, learn to delegate, and break up your responsibilities.
[Context: Maven and Motley are hanging out at lunch debating on what it takes to be a good lead developer]
Motley: No, no, no - you're wrong. The absolute most important skill that a lead developer possesses is technical skills. Everything else is far down the priority list. If I cannot make technical decisions then I am worthless.
Maven: Well, I partially agree-
Motley: You can't agree! You just said technical skills were not most important!
Maven: Let me finish, please. Remember to practice "seek first to understand, then to be understood" instead of "listening to respond", but I digress.
Motley: Blah, blah, blah. Get on with it.
Maven: The phrase "lead developer" means different things to different people. If you are leading a small team of 3-4 developers, then I agree with you, a lead can focus more on the technical aspects of the job, although not completely at the expense of some other areas. However, if you lead a team of 10 developers, that typically does not leave much time for technical stuff and you will spend more time managing people. Note that I am using the term "lead" and "manager" here together - my definition of a "lead developer" assumes that you have direct reports in the organizational structure, and thus, have management duties.
Motley: I can see job responsibilities varying by size of team, but I still think technical stuff is the most important. The phrase "lead developer" still has the term "developer" in it after all.
Maven: True, and you are still expected to be solid technically, but there are other aspects to development, as you know. A lead developer must lead from several different perspectives, including people, process, and, of course, technology. You are a key decision maker in your role and you represent the business, but not at the expense of the people. People issues often have to come first. You are the one expected to grow their careers after all.
Motley: I admit I have other responsibilities than technology. But my team of 10 people is doing pretty well. I don't have to focus on managing a whole lot. I can concentrate on writing code.
Maven: Who mentors your people? Who grows their careers? Who manages the dependencies of your team? Can you possibly attend all technical meetings? Who handles recruiting new people? Who attends upper management meetings? Who reviews all the designs? Who triages the bugs? Perhaps you could do all of that, but you would work a very long day and probably a do a half-ass job at everything.
Motley: I just find that a lot of that stuff takes care of itself. My boss, however, has been screaming at me a bit more lately, I must admit. But I just love the technical stuff and would rather spend time on that!
Maven: Loving technology is great, but you have to balance your tasks on technology lead vs. management. You have a job to do that involves both axes of leading and management. If you don't enjoy both pieces, then why are you a lead? Companies these days have growth paths for individual contributor developers so as not to force them into management.
Motley: I do like the other stuff, but I like the technical stuff more.
Maven: That's fine. You just have to balance technology and people. In order to do that, there are a few keys:
- Delegate: You cannot do everything. Delegate tasks when necessary and fully trust the person you are delegating to. Additionally, do not just delegate the work associated with the task - you should delegate ownership of that task. Make the person completely accountable for finishing it.
- Build a great team: Surround yourself with highly diversified good people. As a lead with a reasonable-sized team, you likely need to give up some of the technical stuff. To compensate, ensure you have one or two senior technical gurus on your team to delegate decisions to.
- Break up your responsibilities. Perhaps ask for another lead at your level of the organization so that you can have a smaller team allowing you to focus on technology more.
Motley: Not bad, Mave. Good suggestions overall. Perhaps what I can do is concentrate on making the key decisions, focus more on design, and give myself some smaller development tasks that are off the critical path of the project to keep my skills fresh.
Maven: Now you're talking! That will free up some of your time for managing careers in addition to the product, mentoring, reviewing the work of the team, refining and enhancing team processes, managing relationships between your team and other teams in the company, and overall making the team a well oiled machine. Of course, we have been mostly talking about management here and less about leading. We should follow up this conversations one of these days and expand on that. We could also talk a lot more about being a good manager.
Motley: I will be a better dev lead tomorrow. Glad I came up with some refinements to my working style.
Maven: Do you think I had something to do with your refinements in this conversation?
Motley: Not a chance.
Maven's Pointer: As a lead developer at Microsoft, I spend far less time in the source code than I have in the past. Let me clarify - I am in the source code quite a bit, just not contributing new code. Instead, I have chosen to focus more on design issues and code reviews when I find the time. However, if I had far fewer than 10 reports, that would allow me to be closer to the code and even be a contributing developer, although not at the expense of the people I need to help grow. Different people have differing opinions on exactly what the role of a lead developer is, and truthfully, it really depends on the specific situation. However, most "leads" are also managers, and caring about your people and removing distractions from their everyday work is a high priority. Let me know if you want to discuss leading and managing more, in the context of developers of course.
- Managing Humans: Biting and Humorous Tales of a Software Engineering Manager, by Michael Lopp, Apress, ISBN: 159059844X, June 2007.
- Hard Code: Lead, Follow, or Get out of the Way, by I.M. Wright (a.k.a Eric Brechner), http://blogs.msdn.com/eric_brechner/archive/2007/12/01/lead-follow-or-get-out-of-the-way.aspx