It's going to be a process, but you have to break down the problem, and attack it piece by piece. I can identify a couple issues in your short description: - U

It's going to be a process, but you have to break down the problem, and attack it piece by piece. I can identify a couple issues in your short description: - Untimely completion of core tasks. There may need to be more frequent check-ins with more granular goals, along with accountability or at least retrospection for missed checkpoints. If a checkpoint is missed, the dev and you have to figure out the why of it and how the process can be improved in the next iteration. - Lack of resourcefulness/grit. This can be taught. This is where it helps to pair someone with a strong developer or yourself. As a teacher, we modeled the learning process as I-do, we-do, you-do. It may be enlightening for an unproductive dev to see better habits in action. But you can't just show a skill and hope it will be replicated. You have to gradually shift more responsibility to the other party to transfer the knowledge. - Misspent time. Not every subproject is useful for its own sake. Hold your team members accountable for demonstrating the value of tangential work beforehand, and put your foot down if you're not convinced. Everyone loves a side-project, but it's not a substitute for progress on the core goals. Most people want to improve, but everyone has some mixture of compentencies where they will naturally self-improve and ones for which they will need mentorship. This isn't the sort of thing where you can make one exasperated speech and see overnight improvement. The goal should be gradual, consistent increases in productivity. And don't forget, since just became a team lead, you also need guidance and continuous feedback. Be proactive in seeking it. Good luck!