A common concept in the "Agile" community is that of T-Shaping. Regardless in which form or fashion it is promoted, the narrative is basically this: People have certain skills, and if they are one-trick ponies or are too generalist, they need to form a so-called "T-Shape." Nonsense!
The concept of the T-Shape
A broad set of skills plus one deep expertise is a "T", multiple deep expertises are "Pi." And then, no model couldn't be "improved" by adding complexity, so we get variations like "M" Shapes, i.e. non-generalists with multiple expertises, and "E" shapes who aren't only experts, who also have "experience, exploration and execution." - although that's clearly buzzword bingo terrain, because what kind of an expert doesn't also have these?
Even I have blogged about T-Shaping, for example, here.
With the model, we were moving the burden onto people: "You must form a T/Pi/E-Shape." Thats nonsense, because it's not like people wouldn't do that on their own volition. In fact, most people who find that they can't use their skills at work will spend their time acquiring off-work skills, such as, for example, learning an instrument: everyone is Pi-Shaped, the only question is if it helps the company.
And now, I announce the time to ditch this model in favor of another model that already predates the Agile Manifesto - "Psychological Flow", by Mihály Csíkszentmihályi.
Psychological Flow
Let's take a look at the model Csíkszentmihályi proposes: He uses the dimensions of "Challenge Level" and "Skill". The very assumption that people have "one" or even a very limited number of skills is already absurd. Consider, for example: breathing. Do you know anyone who doesn't have this skill? Depending on what would qualify as a "skill," people are experts in thousands of them.
Instead of thinking about skills as discrete variables with a discrete set of values (e.g., "none", "basic", "advanced", "expert" ...) - we could think of "skill" as a continuum of different, integrated topics on a continuum spectrum.
Most importantly, the psychological flow proposes a second dimension: the level of challenge, in relation to the skill. For example, asking a Chess Grandmaster to state how a pawn moves is like a relaxation exercise. On the other hand, someone who never cared about Chess won't even take an interest in this question, "why should I care?"
If you'd ask a senior project manager to take care of large, critical programme, that brings out excitement and a sense of, "I am the right person for this job, and I can do it." Their brain would immediately sort through potential approaches and how to make it a success.
A college fresher, on the other hand, might be anxious about where to start and what to do.
That's the basic concept.
Notice that neither the "challenge level" nor the "skill level" are measured on an absolute scale - they can be considered from the perspective of the person who is doing the work: Is this work "low challenge" or "high challenge," does it require "low skills" or "high skills?"
How is Flow related to T-Shapes?
Well, it is - and it isn't. Instead of asserting that a person has a certain skillset required to do the job, we reframe the skilling challenge:
- Is a task adequate to a person's skill level?
- We should not under-challenge people, lest they bore out.
- We should not over-challenge people, lest they become become worried or anxious.
- How do we ensure that people receive challenges which allow them to use high skill?
- High challenge, medium-skill tasks get people to become interested in what they do and that's how they grow.
- High challenge, high skill tasks bring the best out of people.
The challenge, hence, is to identify meaningful, highly challenging work which is at least within grasp of people: medium skills get people excited, high skills get people to perform at their best.
Failure in "T-Shaping" isn't on the individual - it's team management not ensuring people have sufficient challenge to grow and show their performance.
(note based on feedback: in a self-managed team, "team management" isn't top-down - it's what teams decide to do)
T-Shaping ignores Flow
The T-Shaping model makes an implicit assumption: that all the work in the expertise domain is of interest to a person, and that it's a good use of their skills. This isn't always the case. Part of the work may make a very advanced person fall asleep, while being quite challenging for someone new to the domain. Hence, the best way to distribute work in a team isn't based on a certain "T-Shape," but to ensure that people reach a flow state - that is:
A team as a whole performs best not when people exercise a certain "T", but when the work provides everyone with sufficient, yet not overwhelming, challenge.
We shouldn't upskill with the goal of acquiring an abstract "T-Shape" - that's a weird framing already.
Instead, we should distribute work in a team so that everyone is excited to do what they do, while ensuring nobody is overchallenged and anxious or underchallenged and bored.
Whether the result is something like a "T-Shape," doesn't even matter - because the primary result is a highly qualified team whose members are comfortable taking on slightly bigger challenges every day.
Let's forget the T-Shape.
Let's refocus on the question,
"How can we distribute work within our team, so that everyone gets to spend the highest amount of time possible in a flow state?"
Interesting way of thinking. I would challenge this with a question: What do we do with a bottleneck in the team's value stream? There is always one. How about the team's value flow? IMO, T-shaping can help collaborate better when a need to help other steps arise to increase the flow of a whole team. I think there's a balance between the two - individual and team flow.
ReplyDeletePsychological flow, despite the name, "flow" has nothing to do with the thing you label "team flow".
DeleteIn fact, the #tameflow approach labels the latter to be "operational flow," which is just one of four flows that should coincide for highest possible performance.
The reason why "T-Shaping" is a useless model in my perspective: it tells you what, but not how. Psychological flow tells us "what" - and "how". And it takes a subjective, human perspective rather than treating the human as a kind of "resource." If you get this one thing right - always distributing the least complicated task in an area of expertise to the person who is closest to consider this task to be doable, yet challenging - then the bottleneck will automatically resolve itself, because people upskill automatically.
T-Shaping becomes a consequence rather than a goal or a means.
The analogy is not generally used to describe the ideal distribution of depth of knowledge across different areas, or as any Holy Grail. The premise is just false.
ReplyDeleteThe visual analogy is used to explain why an "I"/specialist profile isn't good enough in an agile software development team. The "T-Shape" idea is not a model, it's just an analogy. Analogies are just that.
As I mentioned, you're putting the burden on the individual instead of on the system. People aren't "T-Shaped," because their organization wasn't set up to use them in that way. And suddenly, agilists come around the corner to state, "I-Shapes aren't good enough in an agile team."
DeleteThe message this sends to management is clear - "these people aren't good enough. Fire them, replace them with better ones."
That, however, doesn't fix the problem as long as the organizational system is still designed on using people primarily within their area of specialization, while marginalizing their ability to grow and expand their horizon.
The concept of psychological flow opens a clear way of thinking about how we can practically change the way of distributing work within a team, so that the team as a whole is better.
T-Shaping isn't bad - it's just missing the mark, since it doesn't offer any practical advice beyond, "These guys are worthless because they aren't cross-skilled." Which isn't their fault - because that's what they got paid for.