When a technical leader decides they need to “build broader skills,” the usual move is predictable. They sign up for a course. They read a book on the adjacent discipline. They add a few keywords to their LinkedIn profile: design thinking, data literacy, stakeholder management. Some attend a workshop. A few take a certification. Almost none of them make any genuine progress in t-shaped skills development.
The problem is not effort. It is method.
Would you get in a car with someone who has read a lot about how cars operate, but never driven before? They know about engine, the physics of weight distribution while steering, stopping distance. But none of that means they can drive.
The approaches above treat breadth the same way: absorb information about the adjacent domain until you know enough to feel literate in it. But knowing about a domain and knowing how to operate inside one are not the same capability. A developer who has read three books on product management knows what a product manager does. They do not know how a product manager thinks, where the pressure comes from, what the real trade-offs feel like at two o’clock on a Thursday when a stakeholder has changed their mind and the time box ends on Friday.
That knowledge does not live in books. It lives in experience.
The T-shape’s horizontal bar is not informational breadth. It is operational breadth: the ability to contribute meaningfully — not just comment intelligently — in domains adjacent to your primary expertise. That requires you to have been responsible for something in that domain, to have made real decisions with real stakes. Not observed from the sideline.
This rules out the easy paths. The course gives you a mental model and a certificate. Neither is the horizontal bar.
What builds the horizontal bar is working inside an adjacent domain, not studying it from the outside. That means taking on projects that deliberately cross the boundary: the engineering lead who volunteers to own a piece of customer research. The product manager who spends time embedded with sales when a deal is close to closing. The data analyst who presents their findings directly to a commercial audience and owns the follow-through — not just the model, but what the business does with it.
Value is in contribution, not just observation. You are building the horizontal bar when you are the person responsible for something in an adjacent domain, not when you are the person learning about it.
This is uncomfortable to acknowledge because it narrows the options considerably. You cannot build genuine breadth quickly, and you cannot build it safely. It requires being bad at something for long enough to get past the initial uselessness phase, and most professional environments do not reward that willingness. The course is easier to take than the assignment is to request, and it produces a credential rather than a gap on your track record.
How do you identify where your T is weak?
The most reliable signal is discomfort at specific kinds of meetings. Not the discomfort of being in a room with people who are better than you at your core domain — that is depth anxiety, which is different and productive. The kind of discomfort I mean is the feeling of being present but unable to contribute: you can follow the conversation, but you have nothing to add that the room does not already know. You are a listener, not a participant.
Those meetings map your horizontal bar gaps. The conversations you leave without having said anything useful. The decisions you are not asked to weigh in on. The domains where you know the vocabulary but not the texture.
Pick one of those gaps. Find a way to become responsible for something inside it — not just to learn about it, but to own a piece of it with real stakes. It does not have to be a formal rotation or a new title. It can be a project that nobody else wants, a problem that sits at the boundary between your domain and the adjacent one, an initiative where your primary expertise is necessary but not sufficient and you have to figure out the rest.
The early stages of this will feel wrong. You will be slower than the people who have been in that domain for years. You will ask questions that reveal how much you do not know. You will make calls that a native of the domain would not have made. There will be a specific kind of embarrassment that no curriculum prepares you for: the embarrassment of being visibly mediocre at something you have chosen to do.
That feeling is not evidence you are doing it wrong. It is the signal that the breadth is real and not performed.
The T-shaped professional who comes out the other side of that experience has something the course-taker does not: they know what it actually feels like to work inside that domain, and that knowledge changes the quality of their questions permanently. Not the vocabulary. The texture.
The horizontal bar is built in that gap between vocabulary and texture. Crossing it takes longer than a certification or a book — it takes the period of early uselessness that most people are not willing to sit through, and the willingness to stay until the contribution becomes real.
The centaur model makes the same argument about human-AI collaboration: you cannot build the capability from the outside.
You would not discover the gap between knowing about driving and being able to drive until you were behind the wheel. The car crash will settle the question fairly quickly.
Professional breadth that is only informational fails the same catastrophic way. Usually in the room that matters most.
Leave a Reply