Creating feature teams when technical teams are still technically immature

Question

My current team is quite technically young (close to all of us have less than a year presence in my company), in the software framework that my company is using.

The person who has the most experience in that framework, has one-year and half experience and has no prior work experiences, except than this one.

The rest of the team is gone or is working on different projects.

Yet we have projects to deliver.

I have discussed with my CTO but also with the team about the best way to organize this and I think honestly, this is the optimal way, having think about it again and again.

The idea is to make everyone contribute with what they know e.g the senior guy who has the techincal knowledge of the framework but not great software-work experiences and one of our new guy who has great software skills-experiences but no great knowledge of the platform. That means putting on hold until ready the idea of feature teams.

Yet someone from an other team came up with this idea, that I disagree with

• Putting our 'senior' person on the coding and asking the rest of the team to work on more minor projects work until they have the necessary skills.

As said earlier, the aim is to create feature teams, each team who will have a good/great contributor and also to train people to get them on the train. And also to deliver the projects we have at hand.

The question is the following and is more of a way to say "convince me that I'm wrong":

Has anyone tried with a new team, to create feature teams when "Putting our 'senior' person on the coding and asking the rest of the team to work on more minor projects work until they have the necessary skills." ?

Thanks

Answer 1

This really seems like a situation that calls for some Agile thinking:

• the work belongs to the team as a whole
• collaboration and knowledge sharing increases quality
• growing a team's capabilities has value to the business

At minimum, I would use pair programming to grow familiarity with the framework, along with team code reviews (eg in Github PRs or similar) which would also help with quality as well as knowledge sharing.

If I literally had only 1 person with significant familiarity with the framework, I'd rotate that person through pairings with everyone else.

I'd build some structured training in the framework for the rest of the team into my schedule at the beginning. Maybe there's a 2-4 week period where FrameworkExpert is paired with one other person doing feature work, while the rest of the team is studying up on the framework, working through a book or tutorial together, with FrameworkExpert serving as a resource for questions. Then in the next 2-4 week period, maybe I can have half the team doing feature work, while the other half continues training.

Answer 2

I've implemented a similar measurement twice in a start-up environment and it didn't work as expected because people left for a more directed way of learning aiming to validate their skills with a bachelor / master's degree.

The initial decision had implications, requiring me to:

. plan how to educate them (and help when questions arise and when I could);

. review their work giving them feedback in how to improve (with CI/CD this is somehow implicit as well and becomes more of a standard);

. still ensure things get delivered (and assume major responsibility on this).

It was a process that didn't take longer than 3-6 months and was rather intense. This was good for me in terms of managing people apart from doing my work and I was willing to do it. The problem was that people left 1-2 months after.

All in all, it appears to me the proposal has continuity in mind. It comes with a cost but nonetheless, it's an investment that can bear its fruits as long as there's commitment from both senior member and other's. It can also have consequences such as losing the senior member.

So, from my experience, I agree with the person from the other team only if both requirements are in place (this reduces risks:

. the resources have long-term contracts and / or you know its within their plans to continue in the firm for at least 1 year;

. the senior member is willing to do it.

Answer 3

If any such person exists in your company, your team may need to engage an "internal mentor" or "internal consultant" who can be tasked with assisting your team in understanding the challenges that face them and with controlling the technical risks of your implementation.

This does not mean that this person "will write the code," thus obviating the benefit and most of the role of your team, but rather that (s)he will set the course that your team should best-follow in these uncharted-to-you waters. This mentor serves as a subject-matter expert (SME) and has the responsibility to guide you as to what is the best thing to do without being tasked with actually doing it.

Face it – the probability is high right now that one or several of you are gonna make mistakes simply because you didn't (yet) know that you were making one. Your bridge-team needs to take a pilot aboard, because, even though most-of-ye more or less know how to steer the boat, "here, there be dragons ..."