Know Who Knows

When a manager staffs a critical team, the person they actually need is the connector, the one trusted by the right experts. Organizational topology is invisible, so the manager defaults to whoever they already know.

Know Who Knows is an enterprise talent-mapping interface built around 3 coordinated views (roster, org grid, talent network) that progressively narrow a 200-person pool to a defended shortlist by making the topology of expertise visible. The interface has to make that topology legible without forcing the manager to run a centrality calculation in their head.

Enterprise intelligence
Information architecture
Talent navigation
Concept prototype

Role: Principal product designer for the entity and network analytics model. I designed the 3-view navigation system, progressive scope narrowing, and the guided path from project brief to discovered connector to final shortlist.
Domain: Enterprise intelligence and talent navigation, reframed from an entity-navigation model originally built for a legal and financial intelligence platform.
Status: Concept prototype. The design target is a faster defended shortlist: the proof is the workflow architecture, not a claim about production telemetry.

A list misreads a person

01 · The misread

Finding the right expert is not a search problem. It is a graph navigation problem. The person you need is the connector who knows the people with the right skills.

Finding the right person in a large organization is a representation problem. When organizational structure is opaque, managers default to the people they already know, not because they are the best fit, but because the topology of expertise is invisible. When the topology becomes visible, the decision improves.

The same person looks completely different depending on which view you use to examine them. In a table, they are a row of attributes. In a treemap, they are a block of proportional weight inside a cluster. In a network graph, they are a node with a specific position in a topology: central, peripheral, or bridging.

A manager assembling a team for a critical AI initiative is trying to find the person who can pull the team together: who has the relationships across departments, who is trusted by the domain experts they need to recruit, who has worked with enough of the relevant people that the team will actually function once formed. That is a topology question, and it cannot be answered by sorting a table.

So the system treats expertise as topology, not a list. A manager needs to see who connects the right experts, which departments are covered, and where collaboration risk appears before committing a shortlist.

3 views, 3 questions

02 · The move

Each view answers a different question, and the right view depends on the decision you are trying to make. The information architecture defined 3 scope dimensions (department cluster, skill band, relationship depth) and mapped which view surfaces each dimension most legibly.

Information architecture diagram: entity types feed 3 coordinated views (Roster, Org Grid, Talent Network), each surfacing 1 scope dimension (skill band, department cluster, relationship depth). — The information architecture defined 3 scope dimensions (department cluster, skill band, relationship depth) and mapped which view surfaces each dimension most legibly.

The 3 views were designed as a progressive narrowing sequence. The order carries the argument: you cannot rank before you scope, and you cannot read topology before you narrow.

Roster: the full candidate space
You start in the Roster because you do not yet know what you are looking for: you have a project brief and a rough sense of the skills it requires. The Roster shows the full candidate space, sortable and filterable, but deliberately neutral about relative importance. Nothing is ranked because ranking at this stage would be premature.

Carries: department · seniority · key skills · location
Org Grid: where those candidates sit
You move to the Org Grid when you notice a pattern that prompts a structural question: why are there so many relevant candidates in a department that has nothing to do with the initiative? The Grid is a treemap that shows where those candidates sit in the organizational structure. Blocks are sized by match confidence. Drilling down reveals clusters of co-located expertise: teams that have already built the skill set you need, teams you may not have known existed.

Carries: filters from the Roster · match confidence · department drill-down
Talent Network: who connects whom
You move to the Talent Network when the Org Grid has narrowed the candidate space to a cluster worth examining closely. The network shows the relationships between people: past projects, shared managers, co-authorship, collaboration history. Nodes are sized by connectivity. The hub node is the person you are actually looking for: the person who knows the most people in the cluster.

Carries: the scoped cluster · edge weight by relationship type
Shortlist: the decision with its rationale attached
Dragging a person from the network to the shortlist, or clicking the add button on their profile sheet, adds them to a persistent shortlist visible as a badge on the floating action button. The shortlist panel shows not just who is on it, but the coverage map: which skill clusters have been addressed, which remain open, and what the network centrality of the team looks like as a whole. A team of individually excellent people who have never worked together is a different risk profile than a team of slightly less skilled people with dense shared history.

Carries: skill-coverage map · team network centrality

View transition diagram: a progressive path from Roster to Org Grid to Talent Network, with a persistent scope-context bar carrying filters and drill-downs forward, ending in a final shortlist. — The 3 views share a persistent scope context. Filters applied in the Roster carry into the Org Grid; a department drill-down in the Grid scopes the network to that cluster. The user never loses analytical context when switching views.

The hub discovery is the core interaction. In a force-directed graph, hub nodes naturally migrate toward the center as the physics simulation settles. The visual affordance is immediate and physical: the most connected person is at the center of the group. You do not need to run a centrality algorithm in your head. The topology makes it visible.

Fig. 03 Hub detection

Clicking any node opens a profile side sheet without losing network context. The hub designation (the silver ring on the most connected node) is calculated from edge count and weighted by relationship type: direct collaboration counts more than shared organizational proximity.

The same dataset is encoded across 3 coordinated views (table, treemap, network), each surfacing a different structural dimension, each supporting a different decision moment, and each preserving enough shared context that the analyst never loses the thread. The design principle is not interface variety. The right view at the right moment is itself a form of uncertainty reduction.

A 200-person pool, once the topology is visible

03 · The pool

200 Person candidate pool, narrowed by 3 coordinated views

3 Coordinated views: roster, org grid, talent network

<4 min Pool to defended shortlist in the guided walkthrough, a calibration point, not a measured result

A manager assembling a tiger team can move from a 200-candidate pool to a defended shortlist in under 4 minutes in the guided walkthrough, without touching a spreadsheet or calling 3 intermediaries to find the right person. No timed comparison against a manual process exists; the walkthrough is the calibration point, not a measured result. The outcome is a navigable atlas of organizational expertise: a manager can narrow a large candidate pool, inspect collaboration risk, and defend why a connector belongs on the shortlist without leaving the workflow.

Roster view

The Roster is the neutral starting point. It shows the full candidate pool as a sortable table, with filters for department, seniority, key skills, and location. Nothing is ranked yet, because ranking before scoping would be premature. The manager sees the full space, notices patterns, and decides which dimension deserves attention next.

Org Grid view

When a pattern appears in the Roster, the manager switches to the Org Grid to ask a structural question: where do these candidates sit in the organization? The treemap sizes departments by filtered candidate volume and shows average availability and skill coverage. Drill-down reveals co-located expertise that might otherwise be invisible.

Talent Network view

Once the Org Grid narrows the candidate space to a cluster worth inspecting, the Talent Network reveals the relationships between people. Node size and position show connectivity; the hub node is the connector who knows the most relevant experts. Clicking any node opens a profile side sheet without losing network context, so the manager can add the right person to the shortlist with rationale intact.

Interactive prototype

The prototype demonstrates one complete staffing review: filter candidates, validate org coverage, inspect collaboration risk, and finalize the shortlist. A guided tour is available inside it.

Fallback screenshot of the Know Who Knows talent network prototype showing a force-directed graph with a silver-ringed hub node. — Know Who Knows interactive prototype, covering the full tiger-team assembly critical path.

Build

3 coordinated views: Roster (sortable data table), Org Grid (treemap with drill-down), Talent Network (force-directed graph)
Persistent scope context across view transitions: filters carry forward, drill-down scopes the network
Hub node detection: centrality weighted by relationship type and collaboration depth
Shortlist panel with skill-coverage map and team network-centrality summary
Embedded guided tour walking through the full tiger-team assembly critical path
Material Design 3 system, dark mode, high-contrast pearl and black palette
Single-file HTML prototype with no build tools, no framework dependencies
Source build: mixed-fidelity HTML5 prototype with a Protovis and D3.js predecessor, for a legal and financial intelligence platform

Who this serves

04 · Audience

The current case study reframes the entity-navigation model as an HR and talent application. It preserves the 3-view architecture and progressive scope narrowing, then adds a guided path from project brief to discovered hub to final shortlist. The question underneath does not change with the domain: which node connects the others, and can you defend putting it on a list?

Staffing manager: Assembling a tiger team from a project brief. Needs a defended shortlist without calling 3 intermediaries, and needs that shortlist to hold up in a staffing review.
Compliance lead: Running a review on a flagged intermediary. Needs the entity that links multiple subsidiaries, counterparties, or jurisdictions, with the context preserved for the next analyst.

Worked example: a flagged intermediary in a KYC review

From roster to ownership treemap to counterparty network, using the same 3 views and the same progressive narrowing.

Roster
A compliance lead filters the entity roster to the flagged intermediary and its immediate legal entities, creating a scoped candidate set.
Ownership treemap
The lead switches to the Org Grid to see which corporate family concentrates ownership exposure and whether the risk sits at the parent or a subsidiary.
Counterparty network
The lead opens the Talent Network around the flagged intermediary to find the hidden connector: the individual or entity that links multiple subsidiaries, counterparties, or jurisdictions.
Shortlist
The connector and 2 related entities are added to the shortlist for further review, with the network context preserved for the next analyst.

What this does not prove

05 · Limits

Design intent

The design target is a faster defended shortlist: the proof is the workflow architecture, not a claim about production telemetry.

No timed comparison against a manual process exists. No timed study exists yet; the guided tour is the calibration point, not a measured result.

What I would measure: time from project brief to defended shortlist against the current process of the manager; the share of shortlists that include a connector the manager had not worked with before, the topology-made-visible signal; and shortlist survival rate through staffing review.

Better filters will not find the connector. Filters find attributes, and a connector is a property of the topology, not of any row. When the question is relational, the encoding must be relational.

Provenance

Rooted in 15 years of enterprise data-product design, including design-system work for a legal and financial intelligence platform delivered embedded: 200+ reusable components, 100+ usability participants
Concept prototype. The guided walkthrough is the calibration point, not a measured result