De-Risking Project Delivery Through Team Capability

Overview

My design process

Problem

I couldn't answer a basic staffing question

The idea did not begin with software. Leading distributed teams, I repeatedly faced a project that needed a specific capability — and could not answer:

Who in this organization actually knows how to do this?

Knowing another department had seven designers did not tell me which one had the expertise. The workaround was manual: forms, manager outreach, spreadsheet analysis. It worked. It did not scale.

The current-state workflow

The problem wasn't measuring skills. It was reducing execution risk.

The design challenge

Could team capability become an early signal for project risk — before the organization commits to the work?

That shifted the north star from a better skills assessment to helping managers assemble capable teams — and act when capability is missing.

Research — Assess

Research

I tested the operating model before designing the product

Experience generates a hypothesis. It is not evidence. Before software, I needed to know whether capability information actually improved decisions.

Research questions

1. 01

   How do leaders currently understand what their teams can actually do?

2. 02

   How do they decide who belongs on a project?

3. 03

   When do capability gaps become visible?

4. 04

   What do managers do once a gap is identified?

5. 05

   How do development, mentoring, staffing, and planning connect — or fail to?

Methods

100+ aggregate research and validation touchpoints across interviews, assessments, pilots, and validation activities — not 100+ unique professionals or formal qualitative interviews. The landscape had many point solutions; the missing connection was between capability, work, intervention, and delivery risk.

The manual prototype

Software was not the innovation. The operating model was.

One alpha pilot

Directional evidence from one early alpha pilot — not universal performance data. Team-level signals exposed patterns individual conversations missed.

Define — Align

Define

Research changed the product

The original concept — make team skills visible — did not survive research. Good.

Jobs to be done

Key research insights

How might we…

Ideation

Design — Implement

Design

Design principles

Operating model

Shared capability architecture

I designed one shared capability model rather than separate systems for assessment, staffing, mentoring, and development. A shared skill taxonomy and proficiency scale connect evidenced capability with project requirements. Career-level expectations remain a separate development context; they do not define project demand.

Assessments create evidence; projects create demand; availability determines capacity. TCE compares all three to distinguish capability gaps, capacity gaps, concentration risk, and evidence confidence.

How capability gets meaning

A capability score has little meaning in isolation. TCE interprets development evidence in context: the discipline, career-level expectation, skill, and common proficiency scale. Comparing an evidenced proficiency with a career expectation identifies a strength or growth area; project readiness is a separate comparison against project requirements and availability.

Product roles such as Team Member, Manager, Organization Admin, and Platform Admin control access to information and actions. They are intentionally separate from professional capability and career level.

Key user flows

Flow 01 — Understand team capability

• Configure framework
• Complete assessment
• Map evidence to skill + proficiency
• See patterns → decide

Aggregate patterns before raw scores.

Flow 02 — Build a project team with AI

Flow 03 — Close a critical gap

Product evidence

1 2 3 4

1. 1. Critical gaps Missing capability surfaces before delivery is underway.
2. 2. Coverage Required skills compared with available capability.
3. 3. Remaining risk Exposure stays visible, not buried in detail.
4. 4. Intervention path Mentoring and support sit next to the signal.

1 2 3 4

1. 1. Team readiness Coverage against targets, not employee ranks.
2. 2. Gap concentration Highest-severity exposures rise first.
3. 3. Shape & movement Patterns over time, not a static heatmap.
4. 4. Priority list Drill-down when needed — not by default.

Privacy boundary: the Trust Signal shown in Member 360 belongs to the member’s self-view. Manager views receive only privacy-eligible team or cohort aggregates; they do not expose attributable responses or an individual Trust Signal.

Human-centered AI

Trust Signal: a non-negotiable design constraint

I designed the Trust Signal around a non-negotiable constraint: sensitive behavioral data could not become manager surveillance. Aggregation, participation thresholds, and systemic rather than individual response are design requirements for that boundary.

From prototype to working product

Design system as execution guardrail

Validate — Iterate

Validate

What evidence changed

The observations below combine interview synthesis, alpha-pilot use, diary feedback, and manual workflow evidence. Sources overlap, so they are presented as cumulative product evidence rather than isolated experiment results.

Before / after — operating models

Outcome

From personal workaround to a validated problem and testable beta product

Real alpha usage included managers, participants, diary feedback, and iteration.

What I will not claim yet

TCE is still in beta. I do not claim reduced project failure, retention lift, or ROI that has not been measured. Evidence today: the problem exists, managers recognize it, capability can expose actionable patterns, gaps can connect to support, requirements can be compared with capability, AI can reduce combinatorial staffing work, and organizations agreed to keep testing.

What I learned

Next validation questions