A key feature of any high performing team is it’s ability to cross skill, eliminate skill silos and become completely cross functional.

Let me say that again…

High performing teams ensure that the individuals cross skill so that there are no skills silos so that the team can be completely cross functional. The question is how to get to this point? And the answer is both simple and complex… It starts with the individuals.

As more and more organisations are starting to see the benefits and reap the rewards of high performing, cross skilled teams, it is the individuals in the team that need to understand the importance of cross skilling and embrace cross skilling at their core in order to remain relevant. It is our responsibility as leaders to understand the importance of cross skilling and guide the individuals, allowing them the time needed to develop and embrace cross skilling at their core.

In today’s fast paced, cloud first, continuous delivery world, the days of single skill specialisations are over. A back end developer is now expected to be familiar enough with front end technologies in order to ensure that a complete solution can be delivered in a timeous manner.

I am not saying that you should not have a specialisation, in fact, you should have at least one in depth skill set. So, if you are passionate about something, build the specialist knowledge and skills as this will benefit the team and organisation. What I am saying, is that, in order to become a key part of a high performing team, you should have in depth knowledge of one or more areas, technologies, libraries, frameworks, etc. however, you should also be familiar and functional with the broad range of technologies used by your team. A high performing team is a team that knows that they can rely on each other for the in depth knowledge when needed.

If you ever find yourself saying, “I am waiting for …” or “The FE / BE team needs to complete this part first.”. You need to take a step back and analyse the situation to determine whether you truly need to be waiting or whether, with a little effort and time, you can solve the challenge yourself.

If the team finds an imbalance in work targeting a specific domain resulting in some team members having nothing to do, the team needs to analyse the situation to determine whether, with a little effort and time, the team members can learn the skills needed by the team for the benefit of the team.

Food for thought…

If the organisation is developing a new product and the development has reached a point where there is an imbalance in FE and BE work. Does the goal change or does the pressure simply increase on the heavy side of the imbalance? Now what do you do as a team member? Sit idly by as your team mates drown or step up and get involved to help your team?

If you are not familiar with the concept and benefits of T, π and Comb shaped skills in a team, there are many great resources online. However, these are the skill types, that I have experienced, in brief:

Dash-shaped skills: You are familiar with a broad range of technologies but have no in depth knowledge of any of them.
I-shaped skills: You are a specialist in one technology or domain and are not familiar with anything else.
T-shaped skills: You have in depth knowledge in one technology or domain and are also familiar with others.
π-shaped skills: You have in depth knowledge in two technologies or domains and are also familiar with others.
Comb-shaped skills: You have in depth knowledge in three or more technologies or domains and are also familiar with others.

The question of which skill type you should or can be, depends on you and you alone. The question of which skill type is needed by the team and organisation does not depend on you at all!

In my experience:

  1. Teams with only I-shaped skills never become high performing teams. Don’t fool yourself into believing that a mature project staffed with a team comprised of only I-shaped skills that are capable of delivering solutions quickly is a high performing team.

    A simple test to see if you have a high performing team… If a team member goes on leave; does the work in that domain grind to a halt? Where has the performance gone?… On leave?!

  2. Development teams with a high level of I-shaped skills that are making a concerted effort to cross skill resulting in a steady growth in T-shaped skills will eventually evolve into high performing teams comprised of mostly T and π shaped skills.
  3. Newly formed teams with a high level of T and π shaped skills, possibly complimented with number of Dash and Comb shaped skills will very quickly become high performing teams. I-shaped skills are redundant to a team like this.

But what about Quality. If you have no I-shaped skills, you have no quality… Ridiculous! The nature of T-shaped skills means that you have the specialist knowledge while also having so much more. In fact as the skills evolve into π-shaped skills the team now has more than one specialist in a particular area while also having so much more.

Stop making excuses! You are capable of so much more than you are giving yourself credit for!

Now here’s the absolute kicker for me…

If you have a team that has a strict or traditional separation between the FE, BE and other silo’s and domains. Asking the team if they would like to cross skill will invariably result in resistance and excuses. However, if you ask the team whether they are invested in and committed to helping each other achieve the teams goals, in my experience, you will find that the team is completely committed and even passionate about helping each other.

So, where is the disconnect? They say one thing but do another. It’s clear that they want to cross skill but they don’t know where to start. So where do you focus your energies in order to bring about the change?

At the individual level, that’s where. Look out for the individual(s) in the team that will embrace cross skilling and start with them. This can be as simple as identifying those who treat coding in a different language as a simple exercise of learning the syntax. After all, a loop is a loop, object orientation is a common concept, classes, methods, objects, enums, dictionaries, arrays, primitive types… How many different languages can you name that all use those concepts? Sure, the finer detail will take time to learn and master but the core concepts are identical and all it takes is a knowledge of the core concepts to get started.

Still skeptical?… On a previous project, I had a Java specialist join my team. The challenge with this was that we weren’t using Java at all. This was a C#, ASP .Net project with a JavaScript and HTML front end. So why did we take him on? Because he displayed an attitude and approach of treating each new language that he encountered as a simple exercise of learning the syntax. With the right support, coaching and understanding in terms of the time needed to learn, it took this individual a grand total of 4 weeks to become cross skilled enough to deliver his first full stack solution to production.

When you experience resistance, I propose that you firstly, help the individual to understand how important cross skills are to the team, project and organisition. Then, slowly encourage the individual to start taking on work covering various skills, allowing them the time to learn the new skills and supporting them in the need to ask the specialists for assistance. Once they have delivered their first few solutions, the majority of the remaining team members will start seeing the benefits and will start cross skilling themselves with little to no input needed from you.