T-Shape specialists — who are they, and why do you need your team to have such

Dim Blinov
Agile Pies
Published in
6 min readSep 7, 2022

--

Check out my course about Scrum on Udemy for free https://medium.com/agile-pies/scrum-fundamentals-1-5h-course-on-udemy-for-0-limited-offer-279d03e516cd

Who are the “T-shaped specialists”, and why this quality is desired to be present in any of your team members and is important for the team's effectiveness.

Briefly

Competence = knowledge + skills.

T-shaped skills or T-shaped people — a metaphor for describing employee competencies.

In the letter T:

  • The vertical line is the depth of knowledge and skill development in employee's core area specialization.
  • The horizontal line is the ability to collaborate and apply competencies in related fields other than their main one.

Therefore, a T-skilled specialist is

someone who has a well-developed competence in his main specialization, and at the same time understands and can do the job in the related areas of the team at the initial or intermediate level.

The ideal T-employee in IT company has the competencies to develop software from scratch and bring it to the prom. For example, for a web application these competencies may be SQL, Python, HTML, CSS, JS, Photoshop. And for Android apps developer also Android SDK, Java, Kotlin, etc.

A good T-employee will not complain too much when he is asked to work outside his main specialisation, but will take up the task, figure it out and do it, even if it would take him more time.

In fact, the horizontal line of the letter T is uneven, but stepped.

T-skilled specialist is someone who has a well-developed competence in his main specialization, and at the same time understands and can do the job in the related areas of the team at the initial or intermediate level.

A bit of history

In the 1980s, the term “T-shaped person” was used internally by McKinsey & Company to select and develop consultants.

Other letters

Other metaphors for the development of related skills:

  • I-skilled = well-developed core competence.
  • U-shaped skills = deep functional/subject experience + general management skills.
  • M-shaped, W-shaped = T-shaped with several deeply developed competencies. These specialists are good at the average level in many areas, and in several they are masters.
(Figure from the web.)

Closely related terms

  • Full-stack developer — in the terms above this is an employee M-shaped within a variety of development and testing sub-disciplines. This does not always mean having product management, analytical and UI design skills.
  • Bus/truck factor — the minimum number of team members that, if suddenly disappear from a project, will cause the project to stall due to lack of knowledgeable or competent employees.
  • A cross-functional team is a team with all the competencies to implement a project from an idea to a result. At the same time, each team member can be I-shaped, but in this case the “bus factor” would be very low, the team speed can be unstable, and readiness forecasts are inaccurate.
  • The Competence Matrix or Star map is a tool for team diagnostics in order to increase the bus factor and the effectiveness of the team.

We discuss these topics in more detail on the “Fundamentals of Agile and Scrum” course.

Benefits of developing related skills

Benefits for the team

  1. The team as a whole has more competencies => the team can perform priority tasks, and not those they just have enough competencies for.
  2. Workload is more uniform and, again, on priority tasks, and not “I’ll do this for now while waiting for my peer to complete her task.”
  3. The understanding of each other’s tasks increases => participants are more involved in planning and synchronization => risks are more thoroughly identified => the number of unexpected incidents is reduced.
  4. The level of mutual assistance and support between team members is increasing, claims are reduced, the climate is improving, team morale is growing.
  5. The team has more opportunities, higher independence = “we can do it” => intrinsic motivation and personal responsibility are higher.
  6. Bus factor increases = fewer internal constraints and dependencies on each other. Interchangeability.
  7. Fewer drawdowns in competencies => more sustainable implementation speed => more accurate predictions/estimates => stakeholders has more trust in the team.
  8. The speed of delivery is higher.
  9. A ready increment is delivered at the end of each iteration more often.
  10. Less micromanagement.
The green arrow is a positive connection, a change in one direction. Pink arrow — negative connection, changes in opposite directions.

Benefits for an employee

  1. You can do a mini-project alone from start to finish.
  2. Tasks are more diverse. You will not tire of monotony. Motivation is higher. You can choose what is more interesting, change the direction of personal development without leaving the team for fresh tasks.
  3. A wider choice of vacancies. If you will, it is easier to become a Team lead or a Software architect.

Limitations of T-shaping development

  1. Unwillingness to strain for the sake of learning new things.
  2. Unwillingness to develop in fear of becoming a person on whom everything is put on: “If I am a multitouch, others will burden me more. If I refuse or do not have time, they will be dissatisfied.”
  3. Unwillingness to develop in fear of becoming a “non-specialist” (this is a popular opinion of team members I worked with). The desire to be a master in one craft, and a belief that becoming a master in several disciplines at the same time is difficult or even impossible.
  4. General fear of being replaced => the desire to be irreplaceable, and thereby a person increases his value in the company.
  5. It happens that there is one such person in the team, and other participants are responsible for their silos of tasks.
  6. And then it is difficult to replace such an employee => he becomes irreplaceable, but not for one competence, but for several, and for all complex tasks (bus factor decreases).
  7. And then not the whole team is responsible for the whole product, but to a greater extent it is that senior team member.

Possible disadvantages for an employee

  1. In each separate area you become worse than a narrow-deep specialist.
  2. And you do not keep up with all the trends, because technologies are updated very quickly, and it is difficult to study both deep and wide at the same time.
  3. And if your team and product use several languages or technologies, you have to peek into the manuals more often => your productivity decreases.
  4. Such an employee is always in great demand, constantly busy with work.
  5. And that’s why people around him bother him on weekends and on vacation.
  6. And therefore his self-study on adjacent disciplines goes slower.
  7. And if he is working on one product, then the probability of overload is higher.
  8. And he may receive uninteresting legacy tasks, just because “who else could do it — you know that, it’s not difficult for you, right?”
  9. And he may receive complex defects more often than others.
  10. A narrow specialist with the most expensive skill earns more. (But do you want to do only one thing?)
  11. It’s not easy to find a place with the same technology stack. On the one hand, it’s bad that when you change jobs, part of the stack will be different. On the other hand, it is good that the probability of intersection of the technologies of the current stack and those listed in the vacancy is higher.
  12. Recruiters scan applicants CVs by keywords, and full-stackers may be called for random irrelevant vacancies.
  13. If you write a lot of things in your resume, recruiters won’t believe it. Solution: adapt the resume for each vacancy, removing unnecessary points, highlighting relevant skills.
(Figure from the web.)

Please, check out my online course about Scrum on Udemy.

--

--