Skip to content
Home » Blog Posts » Up-skilling team members reduces risks

Up-skilling team members reduces risks

Spreading knowledge to improve skills removes silos, which helps the team

Risks come in all shapes and sizes in software development. Some are obvious, like deployment, and new technology. Hopefully, they are also all pushing code to a remote repository regularly. There is also some less obvious ones that students, and others with less experience encounter.

Student teams often note that there is a risk to their work because they have different skill levels, or abilities in the team. No one has ‘all’ of the skills they need to know. The normal path after this is to ask team members to ‘go do some tutorials’ to learn the new stuff. This works for some people. Others, however, get stuck as they find it hard to learn on their own. Some also get lost trying to find a tutorial that maps fully to their scenario, and are not sure how to combine a few different ones.

Photo by Van Tay Media on Unsplash

Do work together to reduce team risks

There is a better path. I normally ask teams to start doing some foundation work together as a team, all at the same pace, in the same room on a shared screen. This helps to ensure that everyone is on the same page, and each team member’s experience can help each other find their way through the material. This also builds team understanding and empathy.

Collaborating together to do the work is more effective than asking team member to ‘go learn how do y’ on your own. Collaboration saves them from learning the wrong thing (they use an old tutorial so don’t know about newer options), or from starting with basics, instead of skimming and applying what they learn to the new thing.

By doing more work together the team reduces a number of risks. These are more wins, which pay back the team over time.

The more work the team does tougher the few bottlenecks they create as ‘specialists’. This keeps the work flowing as they don’t wait for Bob, the database person, to make a change. Now, anyone can do it.

Guide your teams to collaboration

Teams resist this whole team approach. It is counter-intuitive. Some think everyone should contribute individually. Here’s a few other issues people propose. Talk them over with your people.

One option to a solo specialist, would be to create a ‘specialist pair’, who do the deeper digging, and then guide the team sessions. This means there are two specialists to help, and helps to keep the bottleneck wider.

In line with this, there should be no ‘front-end’ and ‘back-end’ sub-teams. This also creates bottlenecks, and is less useful than it appears. If there is a front/back division, then how/when do decisions get made about the API that connects them? It would be better to maybe arrange ‘feature pairs‘ of people, if the team decides on subgroups.

Get your teams to experiment with these approaches. The longer they try them, the more likely they will change their development process to include them.


This post is part of a project pulling together my materials and ideas about Teaching Team Collaboration: the Human-Side of Software Development for software development to students.

If you’d like to be notified of future posts, then please sign up for more using the adjacent form. When you sign up, then I’ll send you a free copy of the collaboration rules as a PDF from the book. You can also follow me on LinkedIn

The ideas above are from my book 101+ Ideas to Improve Team Collaboration, which covers all of these little things that students can do to improve their collaboration. Also available via Kindle.

Cookie Consent with Real Cookie Banner