I have been assigned as the lead dev of a newly formed team. I am the only person familiar with the software platform we will be using and the only person to have worked in this domain before. There are 4 other devs 2 are essentially collage grads the other 2 are mid level. I'm struggling to balance my time between planning the approach we will take/delivering a POC and training the other team members. Also critical design decisions need to be made and I am trying to involve the other team members as much as possible but without technical or domain knowledge there is a limit to what they can offer in terms of input.

What advice would you suggest to help get the team up to speed technically and in terms of understanding the domain. I am trying to do fairly in depth code reviews as a group, plenty of discussion/explanation/documentation about the rational for design decisions but I'm finding it hard going! Also I wonder if things like sprint planning/design meetings if I should deliberately take more of a back seat as I find myself doing most of the talking although when I do for periods of time in these meetings there tends to be silence and eyes turn towards me.

NB: I have fed back to senior management and made very clear that the lack of experience is a significant challenge and will impact delivery dates, but I've basically been told there is no money for formal training and to make the best of it :)


1 Answer 1


One advantage that I've found about junior developers is that (if you've recruited for aptitude) they tend to make up for lack of experience with eagerness.

First things first, break up work vertically! That is, don't work in layers. When you talk about features in the application, that feature should encompass UI, middle tier, and storage (database, nosql, etc.).

Second, have a consistent design for the vertical slices. Make the process of implementing a feature follow a recipe. E.g. Create the view in html/template engine, implement the controller, the service layer, the repository, domain object, etc.

Work with the developers in a large group to implement a few features (three should do). With the first feature you implement and explain it as you do. Second feature have each developer implement one piece. Third feature have them each implement a different piece than what they did the first time.

Next break the group into pairs and assign each a feature. Circulate among the pairs to help them with any problems they're having implementing their feature.

Have the pairs mix up for the next set of features.

Then have everyone work individually. Everyone should be familiar with the architecture of the system and be pretty much self-sufficient at this point. Also, you have had a few iterations to verify your design to ensure it works as you've expected and make any necessary tweaks.

In the process you've scaled the team while bringing everyone up to speed on the platform and the domain.

  • I really like this as an approach in taking a slice and letting them work through the entire stack. Thanks I will suggest it tomorrow!
    – Sutty1000
    Commented Jul 12, 2016 at 17:48

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.