I know this feeling too well.
You start a project, and it feels great.
The kickoff goes well.
Everyone sounds aligned.
The plan looks solid.
Then, a few weeks later, something starts to slip. Not all at once. Just enough to feel it.
A project that looked fine on Monday starts dragging by Thursday. Meetings get shorter and sharper. People get tense. Someone wonders whether the wrong person was put on the work. Someone else starts talking about execution. By the time the problem has a name, the team is already carrying it.
I have managed people, built teams, and made staffing calls under pressure, and I kept seeing the same pattern: a lot of team problems are diagnosed too late, and diagnosed badly. We blame execution, communication, ownership, or the individual. Sometimes that is true. But often the real problem started much earlier, when the work was planned without a clear view of the team that had to carry it out.
Where the truth actually lives
Most organizations have systems for tracking work, time, titles, and headcount. They are much weaker at showing whether the team behind the plan is actually set up to deliver it.
Jira can tell you what is in flight. HR systems can tell you who reports to whom. Portfolio tools can tell you what has been promised.
None of them, at least not in a practical way, tells you whether the skills required by the work actually match the strengths, readiness, growth path, and support capacity of the people assigned to it.
So the truth ends up living somewhere else: in fragments, in private spreadsheets, in a manager’s notes, in memory.
Who is stronger than their title suggests.
Who is overloaded but still delivering.
Who is ready for more.
Who is not ready yet.
Who needs mentoring.
Who is quietly becoming a risk because nobody has adjusted the plan around them.
That shadow layer of knowledge is where the real team usually lives.
Once the project is underway, the gap turns concrete.
A team gets staffed because names are available.
A person gets assigned because they look close enough on paper.
A manager makes the best call they can with incomplete information.
Then the strain starts showing up where teams always feel it first: uneven quality, missed handoffs, slower decisions, hidden dependence on the same few people, rework, frustration, and the quiet loss of confidence that happens when someone is asked to carry work they were never properly set up to do.
That is why the shadow spreadsheet matters. It is not just a workaround. It is evidence that the official planning pipeline is missing the part that leaders actually rely on when they make judgment calls.
Why I built TCE
For a while, I carried that picture the way a lot of leaders do: in my head, in scattered notes, in rough mental models that were never stable enough to trust. After enough of those moments, the conclusion became hard to avoid: if the only real view of team capability lives in someone’s private spreadsheet or memory, then the system is already broken.
I built TCE (Team Capability Engine) to pull that truth out of private memory and make it part of planning.
Not as another reporting ritual. Not as another profile system that teams have to keep feeding.
The goal is lightweight input with useful output: a short project intake, brief capability updates when roles or responsibilities change, and simple check-ins around support, readiness, or mentoring when they actually matter. Not giant forms. Not endless upkeep. The point is to capture the signals leaders already try to reconstruct by hand, without turning the team into clerks.
Turning signals into judgment
People provide the source data. AI does the synthesis.
More specifically, it looks at the misalignment between what the work requires and what the documented team signals actually show. It compares project demands against capability depth, current readiness, support load, growth needs, and mentorship context. Then it turns that into something usable: where the fit is strong, where coverage is thin, where risk is rising, and what kind of intervention makes the most sense.
In practice, that means moving from a vague red flag to something more useful. Not “this project is off track,” but “this project depends on skills the current team only partially covers, one of the strongest contributors is already carrying too much support load, and the plan needs either different staffing, a narrower scope, or targeted mentoring.”
That is the role I want AI to play in operations.
Not replacing judgment. Strengthening it.
Why this matters beyond delivery
TCE is built around a simple idea: people development and product delivery should not live in separate conversations. If capability is invisible, delivery suffers. If growth is treated like a side project, retention suffers next.
I have seen good people blamed for situations that were created upstream. I have seen managers make hard calls with half the picture. I have seen talented people burn energy trying to survive inside plans that never really accounted for them in the first place.
The work always notices.
And the cost is not just slower delivery. It is churn. It is stalled growth. It is burnout. It is the quiet damage that happens when a team keeps shipping while getting weaker underneath.
What I’m looking for
I am looking for pilot partners who want to test this in real operating environments, pressure-test the model, and help shape something genuinely useful.
If you lead operations, delivery, product, design, or cross-functional teams, and you have felt the limits of tools that can track work but cannot really see the team, message me.
For more detail, see the whitepaper, Team Capability Engine: https://designerofthought.com/whitepaper/team-capability-engine