Congratulations and condolences. You are about to embark on a journey that is fraught with frustrating experiences. Having done something similar, here's what I

Congratulations and condolences. You are about to embark on a journey that is fraught with frustrating experiences. Having done something similar, here's what I can tell you, though I consider my experience at best a mixed success. First, focus on fundamentals. Spend time with the guys who are having trouble getting stuff done. Pair program with them, letting them drive. Or pair them up with one of the people who do work well. Second, create effort estimates. No, really. Sit down and have these guys explain to you what they will do and estimate the amount of time. Tally it up as you go, then double it, telling them you want a margin of error (make sure to double it again when speaking to your boss, but don't tell the developers that). Encourage them to speak with you immediately if they run into problems that will derail the estimate. This exercise will help a lot in terms of getting them to understand what they really should be doing. Third, don't be a micromanager. Assign a task, support them and check in periodically, but don't push them to do things a certain way. I am really not a fan of the standing morning meeting. Instead, talk to them individually for 5 minutes every morning. It's more of a pain, but it's less stressful on them, which is good. At the same time, encourage them to talk to each other and do have an occasional team meeting (a quick one) explaining where you are heading. Fourth, forget about programming. Sadly, you won't have time for it. With a team this size, you might still have some time, but it's best to lower your expectations dramatically. You'll be doing quite a bit more thrashing between different tasks aimed at supporting your team. You know work for them, and your job is to keep them focused and productive. This really means two things: (a) don't take on large or important projects or projects with major deadlines, and (b) don't seize control of the system architecture. Why? Because you won't have time for it, and will block the rest of the team while you do the research. Fifth, and this is somewhat in conflict with #4, the buck stops with you. Example: my team wanted to switch from using Django's built-in template system for Jinja2 without any real need to do so (we made very light use of the templates anyways; their argument was more of a preference). I listened, but ultimately said no. We had much bigger fish to fry, and this would have been a costly distraction with no upside. This was not a popular move, but the issue was let go after a few weeks. Sixth, be honest with everyone about how things are going. If the devs are not pulling their weight, encourage them to get better. Offer help, guidance, etc. If they don't improve, consider letting them go. If you are a team lead, chances are you don't have that power, but surely your boss will want to know that the company is paying good money to the people who don't do the work required. Lastly, remember, as the lead, it's your job to move the furniture out of the way for your team to get shit done. Your priorities have shifted, and now you are in a different role. The sooner you adapt to that mode, the better. P.S.: Take vacations, and often. Burnout sets in twice as fast for team leads.