What makes for a good architect/manager/lead developer?

Question

I am the Lead Developer for a small software company. Over the past two years, my team has grown from one developer (me) to a group of about nine people. Most of us are very capable, senior engineers (20+ years of experience building software per person), so very little hand-holding is generally necessary. We use Scrum to manage our efforts, and we usually get a lot done quickly with minimal written requirements.

As the team has grown, I've reached the point where it is difficult for me to retain technical oversight over the entire project while also writing significant amounts of new code myself, so it is time for me to adjust my role. How can I make myself most useful to the team when I'm no longer spending most of my time developing?

My goal is to allow my group to grow even further (i.e. increase Scrum velocity) by adding more developers, so I don't want to simply become the "architecture police" who imposes my will on the team. In other words, I want to be the guy who helps things work better/smoother, rather than be the guy who slows things by down by adding an unnecessary layer of bureaucracy. Still, one of our main risks is that things will spin out of control if we add more people without having enough structure to keep us all on the same page.

What is the best way to achieve my goal?

Answer 1

If you were on a team like this, what would you want your boss to do with his time?

1. Remove impediments to progress.
2. Mediate disputes between team members.
3. Interact with business people so we don't have to.
4. Keep us informed of that higher level business/project stuff so we don't feel isolated.
5. Keep us honest, especially if/when a bad apple gets into the team.
6. Be an advocate for the team to other departments.
7. Be the unified voice of push-back against unreasonable business requests.
8. Facilitate communication amongst the team.

There's probably a bunch I'm forgetting, but that's the core of it. Don't implement process, handle some of that overhead/inefficiency that naturally develops as the team size increases.

Answer 2

I'd have no problems with a team lead that was capable of balancing both managerial and technical duties, but it is tough to find people that do well managing that balance.

If I had to choose between the two extremes from a team lead on a growing team...it's a really tough choice but ultimately I think I'd want the team lead to become more of a manager. On a sizable team you'd hope there would be other candidates to step into the senior developer role that could nurture the team's newer members and still do some heavy lifting in development.

But on a growing team you'd definitely want a good manager too. In fact, having a good person with the management title is important because you want him/her to have enough power to carry out good decisions. A good manager has a big influence over a team's happiness and for exactly the reasons you are indicating; by helping to keep them productive - and good for you for thinking like you are. There are a lot of managers that don't give a rat's ass.

I'd recommend a few other posts here at Programmers. Although they are geared more to a team lead than an official managerial role, they may help:

Making the move to Team Leading

How do I succeed as a Lead Developer?

How to earn team members respect as team lead?

Answer 3

I think it is a balance of these traits:

• Technical skill: You don't want someone leading that cannot assess the quality of the work he/she is directing.
• Self-driven: Can define goals and not be reactive.
• Knows how to capitalize on conflict: Conflict triggers conversations
• Auto-didactic: It is not important that he/she knows everything, but knows how to learn.
• Good attitude and energy: You want someone that motivates and makes everybody's work easier, not a diva that barks orders.
• Experience with failure: Possibly the most important one. I've seen very young leaders who might have no problem with all the previous, but at the first sign of failure they freeze or avoid responsibility. Seniority has nothing to do with age, but the right amount of the right experience, and failure is definitely something to consider.

OTOH, the interview is an important part of getting the right person, I'd recommend you to ask the following questions in the interview:

• "Tell me a project where you experienced failure, how you managed it and what you learned from it"
• "Tell me about one time where you broke the rules to get things done"
• Apply the Fizz Buzz test, with any slight twist you can think of.

The FizzBuzz test is absolutely a must, being right or wrong it is not as important as:

• The time it takes him/her to answer: 15 min average, 30 min borderline ok, >30 min NOT OK
• If he/she is able to debug his/her own code: I once had a guy with 15 years of experience apply for a senior position... he took 40 minutes to get the test done... in pseudocode... got it wrong and could not find out why. I had another case where another guy, spent about 5 minutes justifying himself and couldn't accept he was wrong at all.