Are T-shaped skills important in the process of software development and teamwork?

Sometimes Agile development teams need to tackle tasks that require more agility and faster response than the experts recommend. At the same time, they do not have all the tools, information and resources needed to do the job. It seems to me that in such extreme scenarios, when the odds are against the team, there is a team that is most likely to succeed: the one that is built on the new T-shaped skill paradigm.
In short: a person with T-shaped skills has the ability to perform various tasks, but has “deep knowledge” of only a few of them (there is a graphical representation of this concept in the picture under the title of the post).

This description applies, for example, to developers who also know a little about testing and graphic design. Their in-depth knowledge relates to development, but if necessary, they can help the team make mock-ups or do testing. A team made up of members with these skills is more flexible when it faces bottlenecks. When some team members are too busy, another member can take over some of the workload.

Senior ‘Hello, World’ developer?

The vertical T panel refers to the experience and understanding of a particular field, while the upper, horizontal T panel refers to the ability to collaborate with experts from other disciplines, gaining even greater understanding and knowledge of the subject through this collaboration.
For example, one T-shaped developer might have a strong knowledge of Java, but be able to effectively solve problems in PHP, SQL, Ruby, or Python as well.
For many people, this concept can be a problem because:
- Historically, organizations are built around teams with equally skilled people or system components, such as the QA team or the Backend team.
- Lines of management also follow these organizational structures, for example “Support Manager” deals only with the support.
- Entire careers have been built specializing in specific skill sets like PHP developer.
- There is a common misconception that since every person must be a T-shaped, every person must have all the skills needed for the delivery. This is not true.

The traditional approach to building teams around common skills and components has a number of challenges in the complex world we now live in:
- High cost of coordinating work across the flow, no management of the dependencies caused by it.
- Knowledge will be lost during the transfer between different specializations and skills; the decisions that make up the chain will also be lost as the work flows through different teams.
- People become highly motivated in the skill set and knowledge of the product and component, and the motivation to expand skills and knowledge becomes more complex.
- A “this is not my job” attitude can become common when people are not motivated to be responsible for anything more than their particular component.

By building a team with a mixed skill set, rather than around a specific skill set, an organization will be able to:
- Minimize dependencies between teams, resulting in fewer problems with coordination and different priorities.
- Reduce knowledge transfer avoiding information loss.
- Expand and deepen the skills of individual team members over time through collaboration.
- Strengthen team responsibility for the entire solution, and not for its individual fragments.
- In addition to deep technical skills, developers will be able to master “soft skills” such as empathy, problem solving, adaptability and flexibility, seeing the big picture, willingness to learn, communication skills, teamwork, critical thinking.
There are many reasons why companies choose to hire a T-shaped person. Most businesses invest tons of money and time to spread knowledge across their development teams. There is a possibility that knowledge will be lost if employees do not have T-shaped skills, such as teamwork or a desire to learn.
Many companies encourage a “this is not my job” attitude within the team, where developers do not take responsibility for anything other than their own work. Building a team with T-shaped skills rather than conventional skills allows organizations to tackle coordination, management, and prioritization issues, encouraging collective ownership of the entire product or solution, rather than certain elements of it.

Once again, I want to clarify that developers with T-shaped skills still have a specialization in the frontend, backend, or a specific technology stack. However, they can also handle a lot of development tasks, be a design thinker, and even manage a product.
Developers with T-shaped skills enable companies to tackle new challenges and grow quickly. Such a developer can contribute to the project from start to finish, which means you can have smaller teams with more responsibility. They can easily discuss their technologies and compare them with others. It is due to this knowledge that they always know what is happening in their project and can quickly find the source of the problem.
These people are the most in-demand developers. The modern world wants employees who do, for example, a front-end layer, to also be able to use middleware, a terminal in their chosen operating system, deploy their work to the right environment, and know how all this can be tested. Having T-shaped skills is one of the biggest competitive advantages you can have to achieve your goals and compete well in the marketplace.

Teamwork and cross-functional people

A team of T-shaped people, where everyone has different skills and specialties, allows team members to complement each other and form a highly effective team. Teams with these T-shaped people are more efficient because they have fewer internal bottlenecks and contention based on one person’s time.
The end benefit is that the team no longer has a single point of failure (SPOF).
Teams made up of people who already have or want to acquire T-shaped skills tend to be more flexible and resilient in terms of job bottlenecks, because T-shaped skills allow “Swarming”. Not every developer should be able to work on every task. This may be the ultimate goal, but it’s still not realistic in areas that tend to be highly specialized (such as video game development). But wouldn’t it be helpful if each team member could do some work outside of their specialty? Thus, at least a couple of people in a team could perform any task (although perhaps not equally well or at the same speed).

Having team members with T-shaped skills encourages this attitude and makes it practical because people are capable of working on more than one type of task. In these teams, the person who is capable of doing some work should never say, “That’s not my job/responsibility.” However, since a person is not always able to complete any task, a team member may say: “I can not do this” — in the sense of “I am not able to do this”. In this case, the team may decide that this person (without the right skills) will work on this task with another person who has the skills, so that the team has more cumulative opportunities in the future.
Teams with people who still think in terms of individual roles end up with some members already way ahead, and some mired in unfinished work. Classic person-centric thought: “The testers still have work to do, but I’ve coded this feature, so I’m starting to code the next one.” In a team that ‘swarms’, people will realize that it’s usually better to focus and help test, rather than get ahead of yourself to start working on new features.

This post has two main goals in mind: T-shaped skills and encouraging diversity. The first supports mutual understanding and quick teamwork. The latter increases the motivation of people to develop their skills and capabilities. This provides a tremendous opportunity to activate the talents of people. Complex software is developed in a non-linear process, which is why individual skills combined with T-shaped skills allow development teams to create innovative products.