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?

  • 6
    Not sure this is an answer, but I would personally want you to keep the team(s) organized and personalize your management a little bit. Know what they're working on, keep up to date with what they're working on, etc. When you're not organizing them as a group, take part in code reviews, help write modules that need a bit of extra help and maybe spend time with individual developers. I've had a manager or two who weren't helpful and didn't check in with us to see how things were going - but also didn't want to know (yes, bad manager). Aug 24, 2012 at 2:43
  • I think the roles you mentioned in title all have different specifics and use different set of skills. Which one is it?
    – Euphoric
    Aug 24, 2012 at 5:44
  • 3
    Detailed requirements and "unnecessary layer of bureaucracy" aren't the same. The requirements can save your life especially when working with a big team. Don't under-estimate their power.
    – superM
    Aug 24, 2012 at 6:10

3 Answers 3


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.

  • 5
    I can't help but feel like this list is very negatively oriented. This is like "protect me from bad stuff." What about positive impact?
    – Nicole
    Aug 24, 2012 at 2:29
  • 1
    @NickC I thought the above is part the job of the manager. What do you mean with positive impact? Aug 24, 2012 at 9:41
  • 2
    @nickC eh, I tend to have a negative outlook on things, but also in my experience, reducing negative impact has the biggest positive impact on a team's productivity and morale. Especially if you're concerned about belaboring people with process.
    – Telastyn
    Aug 24, 2012 at 11:07
  • @NickC I completely agree with Telastyn, in the end his list may just highlight what would devs face if not having a tech lead. Although, more positive points could be added, ie. "Good tech leads have an overall vision for the technical direction of the product and make sure the team understands it. They delegate feature areas to other team members and let them own their decisions. They recognize that their team members are smart, trust them, and rely on them to handle significant pieces of the project." see engineering.foursquare.com/2014/01/30/…
    – Adriano
    Sep 22, 2014 at 11:00

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?

  • "A good manager has a big influence over a team's happiness" : I think you're right, but this raise another question "Can a team be happy even with a useless manager?"
    – Adriano
    Sep 22, 2014 at 11:03

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.
  • 1
    +1. Everyone must know how to learn.
    – superM
    Aug 24, 2012 at 6:18
  • The FizzBuzz test is to eliminate people with the so called inertia of mind, isn't it? After dealing with complicated problems for a while, most of us can't see any simple solutions for simple problems.
    – superM
    Aug 24, 2012 at 6:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.