In the Beginning There Were I-Specialists
At the beginning of the IT world, professionals were trained in one track (for example C++ or DCOM). These were I-shape – narrow specialists.
They are professionals, but to build a product with a full team of I's requires many people – an expert for every action. This is the first problem.
The second problem: communication. Narrow specialists don't always understand each other, and each is immersed in their field. As the team grows, it becomes less agile. Connecting developers, analysts, DB people, and testers was difficult.
IT evolved and it was time to solve this – and so T-shaped were born.
The term T-shaped was coined in 1991 by David Guest in the article "The hunt is on for the Renaissance Man of computing".
Guest predicted that T-people would be the leaders of the future who would take teams and projects forward.
Popularity came thanks to Tim Brown (IDEO) and even Valve in the book "HANDBOOK FOR NEW EMPLOYEES".
At the foundation of agile methodologies stand those same "universals" from the 90s.
Who Are T-People?
According to Guest, skills are spread across two vectors: vertical (depth) and horizontal (breadth). The horizontal line is not uniform – some topics are more familiar and some less.
Why Are They Important for Teams and Companies?
In a constantly evolving market, both depth and cross-domain skills are important. T-people reduce teams, increase flexibility and response speed. This makes building more efficient, speed increases, and communication within the team is easier.
In reality, agile teams are cross-functional.
What does this mean?
A cross-functional team is a group of experts with all the skills to build, maintain, and develop a product without needing other teams.
Why Are Such Teams Important?
-
Flexibility
-
High development speed
-
Independence
-
High productivity
A common mistake: a cross-functional team consists only of T-people. Not true – it can combine T and I.
In practice, many teams consist mainly of I's.
First, growing or finding a T-person takes a long time (years). Second, sometimes it's simply not required.
Example: building a simple landing page in Tilda – will require a designer, spec, and possibly a tester; no backend needed.
I worked in several cross-functional teams on high-load projects. Each team is an independent unit.
In one team there were full-stack developers (familiar with both front and back), analysts, manual and automated testers, and a team lead.
Developers replaced each other on vacation/illness, and development didn't stop. Same with analysts and testers.
A small and confident team managed several projects of the same platform more successfully than large teams, thanks to good T-people.
There were no communication problems – developers, analysts, and testers spoke the same language. Testers could read code and understand which tests to add without help from developers.
About the Disadvantages
T-people are in demand, but there are also less shining sides.
Burnout: need to chase development both in expertise and in adjacent fields.
Psychological "defense": fear that additional knowledge will bring more work, especially if management exploits this.
Doubts: "Is it possible to be an expert in two fields?" – important to encourage to grow a T-person.
Cross-functional teams are not composed only of T-people – usually they "mix" T experts with I's.
Such teams are more flexible and capable of delivering more results in a short time.
