I Hired Her for Her Strengths. My Manager Called It a Weakness.

I hired a developer once specifically for her strengths, and my manager told me it was a weakness. She was fast. She liked to deliver. She wanted to solution her own piece of the work and she stayed out of the overall architecture, deliberately, which at that moment in the industry read as a limitation rather than as a choice.

This was the era of the cross-discipline rockstar, the engineer who was supposedly great at everything. We had those people. What they mostly did was argue about architecture, at length, while I wanted to move. Work I handed to her came back finished, including the work the rockstars found boring or would not touch.

I felt exposed defending her, and it caused real issue with the person above me. I did it anyway, and I would do it again. It was the right call even though the organization could not see it, and the reason it was the right call is the thing I want to spend today on.

Conventional wisdom says a strong team is made of strong people, so building one is selection plus development. Hire well, then improve what is weak. Every technical leader reading this has written a development plan aimed at somebody's weakness, most have written several, and very few would say the hours were justified by what came out the other end.

Notice what both halves of that have in common. They treat the person as the variable. The seat is a given, inherited from an org chart, a job description, and a headcount plan, and almost nobody derives it fresh for the work actually sitting in front of the team right now.

Here is why that ordering fails, and it is not a motivational claim. Weakness remediation does not work for most people, because changing an ingrained habit requires the person to genuinely want the change, and wanting it is not something a manager can supply from the outside. That is one of the reasons I stay out of motivation entirely. Follow it through and the conclusion is unavoidable: if the person is the variable you cannot reliably move, the seat is the variable you actually control.

So the seat is where the work is, and the seat is almost always stale. What a role demands, derived again for the work in front of it, is what I call Design Load. A design load is the number on the drawings, and it goes out of date exactly the way a job description does. When a building's use changes, engineers do not trust the old number; they derive a new one for the new occupancy and check every member against it. The job description written two reorgs ago is the old number.

Against that stale number, every mismatch reads as a fact about the person. What I call Bearing Capacity is what someone can actually carry, tested against real situations rather than inferred from a title, and the useful half of the idea is that it is not a fixed number. In geotechnical work, the capacity of ground varies with the width and depth of the footing set into it: the same soil rates differently under a narrow footing than under a wide one. Capacity belongs to the person, and it is drawn out or suppressed by the shape of the seat you set them into. Test the ground before you blame it.

The mismatch then runs in two directions that look nothing alike from outside, and the conventional frame cannot separate them because it has only one word for both, which is performance. Over-capacity presents as quiet competence: no complaints, no drama, steadily less initiative, and a resignation nobody saw coming. Under-capacity presents as decisions arriving late and the same category of fire recurring every quarter, handled competently every single time and never actually prevented. One of those needs a wider seat. The other needs a different person or a smaller load, and treating either one as the other makes it worse.

The operational cost of never re-deriving is that your team's total capability stays roughly flat while the company keeps moving along the Load Curve. That gap widens slowly and then quickly, because that is what the curve does at the bend, and it widens fastest exactly where nobody has looked at a seat in three years.

There is also a cost that never appears on an org chart, which is the one I paid. The rockstar ideal penalizes the manager who does this correctly, because shaping a seat around somebody's strength looks like tolerating a limitation. The structurally right call is the one you have to defend upward while it is still unproven, to people who will read it as lowered standards.

The leaders who build teams that compound are not better judges of talent, and they are not tougher about performance. They stopped treating the seat as a fact and started treating it as the thing they design.

Concretely, that means starting from the team's activities rather than its roles: the things that actually have to happen, listed out, before anyone's name is attached. Then the names go on, one per activity, marking who genuinely excels at it. Seats are built from what that produces, which is why a seat crafted this way frequently looks nothing like the job description that preceded it.

That approach is faster and stronger than remediation, and it carries one real cost worth naming rather than hiding. A team of well-matched complements develops person-shaped roles, and it is most fragile at the moment somebody leaves. Speed and coverage are both legitimate and neither can be removed, which makes this a Structural Bearing to hold rather than a problem to solve. The way you hold it is to derive coverage in the same sitting as fit rather than hardening it afterward, because two is one and one is none.

So here is the thing to do this week. List your team's activities. Not roles, not titles, activities: the things that actually have to happen. Then put one name against each, the person who genuinely excels at it. Any activity with no name against it is a gap your org chart is currently hiding, and any name that appears against activities their seat does not formally include is capacity you already have and are not drawing.

Designing the seat is where capability starts. The LeadershipOS™ book covers the layer that decides whether it compounds: Coaching, and the difference between developing one person directly and developing a manager's capacity to do it without you: http://TheLeadershipOSBook.com