Early Startup Team Building: Design the First Operating Model

Five talented people can share a company name without functioning as a team.

One optimises for a launch date. Another protects an architectural boundary. A third follows customer requests. The founders settle every collision, so work appears coordinated until they become unavailable.

The problem is not a shortage of trust exercises. The company has hired individuals before designing the system that makes their work interdependent, decidable, and visible.

Early team building is the design of that first operating model.

It defines why the team exists, who belongs to it, which decisions it can make, how work crosses roles, and what happens when evidence or people disagree.

Decide whether the work needs a team

Not every collection of early hires should become one team.

A real team needs a bounded membership, a shared result, and work that requires coordination. If three specialists can deliver independently to a founder, calling them a team does not create useful interdependence.

Write the team’s joint work in one sentence:

Together, we are responsible for [outcome or service] for [specific people], within [boundary], while protecting [critical constraints].

The sentence should identify something no member can achieve alone. It should also exclude work the team does not own.

Wageman, Hackman, and Lehman’s Team Diagnostic Survey is grounded in conditions such as a real team, compelling direction, sound structure, organisational support, and coaching.[1]

Their validation analysed responses from 2,474 people in 321 teams across varied organisations. It validates a diagnostic instrument; it does not prove that copying its conditions will make a startup effective.

The practical challenge is still valuable: do not expect teamwork from a group whose membership, purpose, or task is unclear.

Build the model before writing values

Values such as ownership, candour, and speed sound attractive because they leave the hard choices unresolved.

“Act like an owner” does not say who may change price. “Move fast” does not say which customer promise cannot be risked. “Be transparent” does not say where a decision must be recorded.

Start with six operating contracts:

1. Purpose: the shared result and user or customer served.

2. Membership: who is on the team and which capabilities are available elsewhere.

3. Authority: decisions the team owns, decisions assigned to one role, and boundaries requiring escalation.

4. Coordination: how work, evidence, and commitments move between people.

5. Disagreement: how challenge happens and how unresolved conflict moves.

6. Revision: when and how the operating model changes.

Values can then describe the behaviour expected inside those contracts. Without the contracts, the values are open to whichever interpretation has the most status.

This is narrower than Product Org Design for Clear Ownership.

Org design sets boundaries across teams. The early operating model makes one team’s work coherent inside its boundary.

Choose membership from the work system

Early hiring often starts with impressive candidates and ends with a search for work that fits them. Reverse the sequence.

Map the decisions and work required to produce the shared result:

• understand the user and commercial problem;

• decide product direction and scope;

• design and test the experience;

• build, secure, release, and operate the product;

• support customers and learn from live use;

• manage legal, financial, or domain obligations.

The team does not need a dedicated person for every line. It does need reliable access to the capability and clarity about who carries the decision when that capability is external.

Name gaps honestly. A founder covering sales, product, and support is not three staffed functions. A fractional security adviser is not a full-time responder.

Avoid “culture fit” as a substitute for evidence. Define the behaviours the work requires: exposing weak evidence, documenting a consequential choice, asking for help, challenging a founder, or handing over an incident.

Assess candidates against observable work and the variety the team lacks. Similar communication styles can feel frictionless while leaving the same assumptions unchallenged.

Draw an authority map, not a role list

Job titles describe areas of contribution. They rarely resolve a live collision.

For each recurring decision class, record:

• who frames the decision;

• who contributes evidence or expertise;

• who decides within the normal boundary;

• who can block for a named legal, safety, or ethical reason;

• who operates the result;

• what condition requires escalation;

• what evidence can reopen the choice.

Decision classes may include target segment, pricing exception, product priority, technical architecture, production access, customer commitment, hiring, and incident severity.

Do not give every decision to consensus. Consensus can be appropriate where shared commitment is the decision. It becomes avoidance when nobody can close a time-sensitive trade-off.

Do not give every decision to a founder either. That keeps local work coherent only while the founder has attention to spare.

Team Alignment: Make Local Decisions Coherent explains how a shared operating frame lets people make compatible choices when the leader is absent.

Design coordination around dependencies

Meetings, documents, and chat channels are mechanisms. Their job is to make interdependent work easier to coordinate.

Okhuysen and Bechky reviewed coordination research and proposed three integrating conditions: accountability, predictability, and common understanding.[2]

That paper is a conceptual synthesis of prior literature, not an experiment on early startup teams. The three conditions are useful as questions, not as a guaranteed formula.

For each important dependency, ask:

• Accountability: does each person know who owns the next action and decision?

• Predictability: can people anticipate when input, review, or a hand-off is needed?

• Common understanding: can they explain how their work changes the whole result?

Choose the lightest mechanism that creates the missing condition.

A weekly customer-evidence review may create common understanding. A decision record may create accountability. A visible release forecast may create predictability for support.

Do not schedule a meeting for information that a current record can carry. Do not demand asynchronous work when the decision needs rapid disagreement among several disciplines.

Define one source of truth for active commitments, one place for consequential decisions, and one route for urgent operational work. Tool proliferation makes the operating model harder to inspect.

Write a charter that can govern real work

A useful team charter is not a page signed on the first day and ignored afterward.

It should contain the team’s joint work, authority map, critical dependencies, coordination mechanisms, and revision triggers. It should name behaviours in observable terms.

Mathieu and Rapp studied 32 MBA student teams in a business simulation. Teams with strong performance strategies did better over time, with the strongest sustained results when both strategies and team charters were high quality.[3]

The setting was simulated work by student teams. It does not establish that a charter improves performance in a startup or identify this article’s correct charter content.

Its bounded relevance is temporal: time spent defining teamwork and taskwork can shape how a team performs later. The quality of the artefacts matters more than their existence.

Test the charter against recent work:

• Could it resolve a product-versus-sales commitment?

• Does it show who can accept a reliability risk?

• Does it tell a new member where customer evidence lives?

• Does it explain how the team changes a priority?

• Does it define what happens when two owners disagree?

If not, the charter describes an aspiration rather than the operating model.

Make speaking up part of the system

A team cannot adapt if people hide errors, uncertainty, or dissent until the evidence becomes impossible to ignore.

Psychological safety does not mean comfort, agreement, or freedom from accountability. It concerns whether interpersonal risk is safe enough for relevant information to enter the work.

Edmondson’s multimethod field study of 51 teams in one manufacturing company found team psychological safety was associated with learning behaviour.[4]

The design does not establish that one leadership technique caused performance, and one company is a narrow setting. Do not turn the result into a universal checklist.

Translate the boundary into operating behaviour:

• leaders state which parts of a decision remain uncertain;

• a reviewer challenges the claim, not the person’s worth;

• a person who reports a mistake is expected to help contain and understand it, not hide it;

• dissent is recorded when the decision proceeds;

• retaliation, humiliation, or discrimination follows a formal people process, not a team ritual.

Pair safety with decision closure. A team that can challenge forever but cannot commit has moved the coordination problem rather than solved it.

Define the path for disagreement

Early teams often rely on goodwill because formal conflict feels too corporate. That works until status, equity, workload, or customer pressure raises the stakes.

Use a short resolution path:

1. State the disputed object: fact, interpretation, goal, method, authority, commitment, or conduct.

2. Identify the decision owner and required evidence.

3. Separate the work dispute from any relationship or behaviour harm.

4. Set a time boundary for resolution or escalation.

5. Record the choice, dissent, owner, and reopening condition.

Serious misconduct, harassment, discrimination, retaliation, or legal concerns need qualified formal handling. A founder-facilitated debate is not an adequate substitute.

Product Team Conflict: Resolve Work and Repair Trust covers the wider resolution and repair process.

Use the first work cycle as the test

Do not spend a month polishing the model before the team has done interdependent work.

Draft the first version, then run one real work cycle. Choose a bounded customer or product decision that crosses at least three roles.

Observe where the system fails:

• a decision has several implied owners;

• a hand-off arrives without the evidence the next person needs;

• a founder reopens a choice outside the declared route;

• support learns about a release from a customer;

• nobody knows when a technical concern becomes a product constraint;

• a person stays silent because challenge appears costly.

Change the contract at the point of failure. Do not add a broad ceremony for a local gap.

Review the operating model after the first cycle, the first material disagreement, the first production incident, and each meaningful change in membership or customer obligation.

A fictional first-team design

Consider a fictional startup building software for independent clinics to coordinate equipment maintenance. The example is invented and claims no outcome.

The first group includes two founders, one engineer, one designer-researcher, and one implementation specialist. They initially describe the team as responsible for “building the platform”.

They narrow the joint work: help a clinic identify due maintenance, assign it, and retain a trustworthy completion record for one equipment category.

The authority map gives one founder the segment and commercial-boundary decision. The engineer owns implementation inside documented safety and data constraints.

The designer-researcher owns research quality, not product priority. The implementation specialist can block a customer commitment that the current support model cannot deliver.

The team uses one weekly evidence review because customer learning changes every discipline. It uses a short decision record for scope, data, and customer-promise choices.

A clinic asks for an unsupported equipment type. Sales value and implementation burden are disputed. The decision owner hears both, records the boundary, and sets evidence that could reopen it.

During the cycle, the team discovers that maintenance-record recovery has no owner. It changes the authority map and release check rather than adding a generic operations meeting.

No performance result is asserted. The example shows how membership, authority, coordination, and revision become visible before scale makes the omissions harder to repair.

Know when the model is working

Do not reduce team health to sentiment or output volume.

Look for evidence in the work:

• decisions close through the declared route;

• people can explain the shared result and current boundary;

• hand-offs contain the information the next person needs;

• material dissent and risk surface before commitment;

• founders are not the hidden router for ordinary work;

• repeated coordination failures cause a specific model change;

• new members can find authority, context, and escalation paths.

Interpret each signal in context. More escalation may reveal dependency, or it may show that people finally recognise a boundary.

Team development comes next. How to Lead Through Team Development concerns growing capability in an existing team.

Early team building has a prior job: create a real team whose work, authority, and learning can be seen.

Hire people for the work. Give the group a bounded result. Make decisions and dependencies explicit. Then revise the model when reality exposes what the first draft missed.

Sources

1. Wageman, Hackman, and Lehman: Team Diagnostic Survey (instrument validation using 2,474 members of 321 teams, not a startup intervention study)

2. Okhuysen and Bechky: Coordination in Organizations (integrative literature review and conceptual framework)

3. Mathieu and Rapp: Team Charters and Performance Strategies (32 MBA student teams in a business simulation)

4. Edmondson: Psychological Safety and Learning Behavior in Work Teams (multimethod field study of 51 teams in one manufacturing company)

Read next

• Product Org Design for Clear Ownership

• Team Alignment: Make Local Decisions Coherent

• Product Team Conflict: Resolve Work and Repair Trust

• Leadership Presence: Intervene Without Becoming the Gate