Who Will Do the Work? Make the Company’s Team Slide More Than a Biography Page

Two founders, a domain adviser, a contractor with a narrow brief, and a support hire they intend to make. Written as a biography page, this slide is easy to produce and pleasant to look at. It is also silent on the question the person reading it is actually asking.

A team slide is where a proposal says who will do the work. Most are written as though the question were who these people are. Those are different questions.

Start with the work the company is proposing to do

Before anything goes on the slide, list the functions this particular proposal depends on. Not the company's ambitions — the work in front of it: building the thing, selling it, supporting people who use it, managing delivery when something goes wrong.

The test for whether a function belongs on the slide is blunt. If this work stalled for a month, would the proposal break? If yes, the reader needs to know who holds it. If no, leave it out. An investor reviewing a seed round, a hospital evaluating a scheduling vendor, and a manufacturer choosing a supplier each need a different subset of the same list, and every one of them is better served by five sharp lines than by a reproduction of your organizational chart.

Consider a fictional example I'll use throughout. Tidepool is an invented appointment-scheduling product for small physical therapy and dental clinics; nothing about it comes from a real company. Its plan for the coming year requires someone to build and maintain the product, someone to configure each new clinic account and train its front desk, a review of the payments connection before card payments go live, judgment about clinic workflows and pricing, and a route for live clinics to get help when something breaks.

That is five functions. Not one of them is "strategy." Each one is a place where a name can be wrong in a way that matters.

Map actual people and commitments to those functions

Once the functions are listed, each one gets a person and a capacity. Four capacities are common, and they are not interchangeable:

• Operating. This person does the work inside the business now, and the plan is relying on it.
• Contracted. A defined scope, a deliverable, an end. The relationship stops when the work does.
• Advisory. This person informs decisions. They are not on the hook for delivery.
• Planned. Nobody is doing this yet.

The distinctions sound obvious in a list and collapse the moment a slide gets designed. A title does not establish scope. Neither does an association, a past employer, or the fact that someone agreed to take a call once a month.

Here is Tidepool's map, with invented roles but concrete commitments:

Two things in that table are easy to get wrong. First, the contractor's review has a scope and an ending. Once the report is handed over, the specialist is not part of delivery, and the slide should not let a reader assume otherwise. Second, Dev appears twice. That is honest. A slide that gave support its own box containing a different name would look more balanced and be less true.

Shared responsibility is not a flaw to hide. It is information a reader uses to understand how thin the plan is in one place.

Choose experience that explains the responsibility

Only now does it make sense to decide what each person's background is doing on the page. The evidence should make the assignment legible — a specific skill, a prior responsibility, or an eligible example tied to the job you just gave them.

For Rosa, the relevant detail is that she has built booking and scheduling systems before, not that she once worked somewhere impressive. For Dev, it is that she has configured accounts and trained front-desk staff at this scale. For the contractor, the assignment itself is the evidence: a defined review of a payments connection, with a signed scope. For the adviser, the connection is to a decision she actually influences — clinic workflow and pricing — not to the general aura of having run clinics for a long time.

A recognizable employer name with no explanation tells the reader that someone was once near relevant work. It does not tell them what that person will do here. If a name is worth including, one clause should carry the connection: what they did, in what setting, and why it maps to this job.

Two temptations to resist. The first is compression into a career biography, which spends the reader's attention on a life instead of a role. The second is invention — a polished outcome, a credential, a hint that a former employer is still a client or partner. A short, accurate line beats a full one. "Runs onboarding: configures accounts and trains front-desk staff" is more useful than three sentences about an operations career, and it is far more useful than a logo.

Make gaps and dependencies readable

Every early-stage plan has work that has not been given a dedicated owner: absorbed by someone whose main job is something else, or not covered at all. The slide's job is not to hide that. It is to say what the gap is, what the plan assumes about it, and when the assumption will be tested.

For Tidepool, the open item is support for clinics already using the product. A front-desk coordinator who cannot save a booking on a Friday afternoon needs a route to a person. Today that route runs through Dev, between onboarding sessions. The plan assumes a support hire will take it over. No offer has been accepted, and there is no start date.

Notice what a team slide should and should not claim about that. "We are hiring a support lead" is a statement of intent. "Support is handled by Dev until the role is filled" is a statement of fact. The two have different grammatical moods for a reason, and readers who fund or buy from you will read the difference. A proposed hire is not a filled role, and even a signed offer includes ramp time before anyone is competent on the product.

There is also a dependency worth naming: onboarding and support are competing for the same person's hours. A slide that lists Dev twice without saying so invites the reader to assume two full-time capacities where there is one.

And be careful with the adviser. A domain expert who takes a monthly call can change a pricing decision, catch a wrong assumption about clinic scheduling, or introduce you to a buyer. None of that is delivery capacity. An adviser on the slide is a signal about judgment available to the company, not about hours available to the customer.

Keep these two judgments separate at all times. Whether the presentation is complete is a design question. Whether the team is sufficient is an operating question, and a tidy slide does not answer it.

The same company, written two ways

Here is how Tidepool's slide reads written as a biography page.

Rosa, Co-founder and CEO. Product leader with a decade in business software. Dev, Co-founder and COO. Operations specialist who built onboarding at a high-growth software company. Payments specialist. Former engineer at a large payments processor. Adviser. Twenty years in outpatient clinic management. Support. A support lead will join the team. A row of four logos: two former employers, one investor, one technology partner.

Nothing here is false, and everything here is unhelpful. The reader cannot tell who configures a new clinic account, what the payments specialist was engaged to do, whether the support hire is a plan or a fact, who answers a clinic's email next Tuesday, or why any of these people are the right ones for a scheduling product rather than, say, a payroll service. The logos do the heaviest lifting and carry the least information.

Written as a responsibility map, the same four people and one gap look like this:

Product build and roadmap — Rosa, co-founder, full time. Has built scheduling systems before; owns the roadmap. Clinic onboarding and configuration — Dev, co-founder, full time. Configures accounts and trains front-desk staff. Payments connection review — contracted specialist. Defined scope; delivers a written review before card payments go live, then the engagement ends. Clinic workflow and pricing — adviser. Monthly call; advises on pricing and workflow decisions. Not part of delivery. Support for live clinics — no dedicated owner. Currently handled by Dev between onboarding sessions. A support lead is planned; no offer accepted, no start date. The plan assumes this role is filled before the next cohort of clinics goes live.

The second version is not more impressive. It is more answerable. It tells the reader who does the necessary work, why each person's experience connects to that work, and where responsibility is still unresolved.

What it does not tell them is whether the team is large enough. Dev's remaining hours may cover the current book of clinics; they may not. That depends on how many clinics are live, how many support requests arrive in a week, and what onboarding actually consumes — none of which the slide establishes. Whether Tidepool can deliver its promise is a capacity question, and the page cannot settle it. What the page can do is stop pretending the question does not exist, so the reader can ask it with the right facts in hand.

The biographies were never the problem. Answering the wrong question was.

Frequently asked questions

What should determine who appears on a team slide?

Start with the functions this particular proposal depends on, not the company's ambitions or full org chart. The blunt test: if this work stalled for a month, would the proposal break? If yes, the reader needs to know who holds it. Different readers—investor, hospital, manufacturer—need different subsets, and five sharp lines often serve better than an org chart.

What capacities should I distinguish when describing each person?

Common capacities are operating, contracted, advisory, and planned, and they are not interchangeable. Operating means the person does the work now; contracted means a defined scope and end; advisory means the person informs decisions but is not on the hook for delivery; planned means nobody is doing it yet. A title, association, or past employer does not establish scope.

How should I choose what experience to include?

Include evidence that makes the assignment legible—a specific skill, a prior responsibility, or an eligible example tied to the job you gave them. A recognizable employer name without explanation only says someone was once near relevant work. Avoid compressing into a career biography and avoid inventing outcomes, credentials, or client/partner relationships.

How do I present gaps and proposed hires honestly?

Say what the gap is, what the plan assumes about it, and when the assumption will be tested. 'We are hiring a support lead' is a statement of intent; 'support is handled by Dev until the role is filled' is a statement of fact. A proposed hire is not a filled role, and even a signed offer includes ramp time. Also name dependencies, such as onboarding and support competing for the same person's hours.

Does a complete team slide prove the team is sufficient?

No. Whether the presentation is complete is a design question; whether the team is sufficient is an operating question. The slide can stop pretending the capacity question does not exist and give the reader facts to ask it, but it cannot establish whether the team can deliver its promise.

Further reading

• Connect the Funding Ask to the Work the Company Will Do — After mapping functions to people, read this to connect the funding request to dated work, named owners, dependencies, and controlled versus commercial outcomes.
• Does Your Film Need an Archivist, a Historical Adviser, or More Reporting? — Read when an adviser's title is doing the work: it shows how to choose by demonstrated contribution and define what the advisory engagement returns.