7. Build the Team for the Battle Ahead¶
The team layer starts here. This chapter is about building the right team for the mission. The four that follow are about what you owe that team once it exists.
Early-stage startup. Around $100,000 in funding. I joined as a senior founding team member.
Not my first time inside a company like this — which is the part that should have made the architecture smarter than it turned out to be.
I was the product guy. The team got built around what the money could afford.
A fractional CTO, titular only — the day-to-day CTO work fell to me.
One frontend developer.
One fullstack developer who also did DevOps.
One backend developer.
One junior UI designer doubling as UX.
And me, doing 60–70% of the actual work — product, de-facto CTO, business analyst, COO duties, all at once.
That was the architecture.
The architecture was not designed. It was the shape the budget allowed.
I built the team I could afford. I did not build the team the work needed. Then I tried to be everything the team was missing.
That worked for a season. After the season, it caught up with all of us.
The mission was uncertain. That part is critical.
The startup began as a B2C product. Mid-flight, we realized monetization on the consumer side was not viable. We pivoted to B2B2C, maintaining the consumer side as a customer-acquisition layer for a business partner.
The mission shifted while the team was already running.
The team had been built for one mission. The mission changed. There was no slack.
No role designed to flex into a new shape. No character mix designed for ambiguity. No learning capacity designed in deliberately.
The team kept running. It just ran inside an architecture built for a different battle.
The cost did not arrive as one event. It arrived as several pressures compounding across months.
The top layer burned out. Not just me — all the top guys. The people doing 60–70% of the actual work on top of their nominal roles ran out of room. There was nobody designed to absorb the overflow because the architecture had nobody designed to absorb anything.
The staff felt the uncertainty. A team always feels mission instability before anyone names it. Energy got quieter. Meetings got longer. The room read different.
A team member left.
Not because of workload alone. Not because of uncertainty alone. Because of both, compounding.
Workload alone, people can usually survive. Uncertainty alone, people can usually survive. Workload plus uncertainty does something neither does on its own.
The tech team and UX team started giving feedback on product and business decisions.
This is the part I want to be careful about.
That was not the team behaving badly. That was the team filling a vacuum the architecture had left open. When no one is holding the lanes, someone in the room will. Vacuums get filled. The team was doing the architecture's job because the architecture was not doing it.
The honest read is that the architecture failed first. The boundary blur was downstream.
Bugs and issues could not be addressed fast enough. A team already covering double roles started missing things. That is also predictable. A team without slack does not just slow down — it starts dropping the work that does not have an obvious owner.
This is where architectural slack becomes a useful term.
When the mission is unstable, the architecture must include slack — capacity to absorb a pivot, roles that can flex into adjacent work, trust that survives a strategic change.
A team without architectural slack breaks at the first pivot.
That is what I had built. A team with no slack, into a mission that was already moving.
What I missed at the time was that the variable was not skill. The variable was learning capacity.
In a startup, every person will eventually wear a hat their job description does not include. The team that survives is the team that can learn into the next hat fast.
Or, said the way I have said it many times since:
In startup, you can't avoid doubling roles. What matters is learning capacity.
This is the chapter's hardest claim, so I want to land it cleanly.
Skill matters. Skill is the floor. A team without baseline skill cannot ship.
But under mission uncertainty — which is the default condition in operator environments, not the exception — learning capacity, complementary characters, and trust are the variables that determine whether the team scales.
Learning capacity, because every person will eventually wear a second hat.
Complementary characters, because a team of identical shapes will fail in identical ways.
Trust, because doubling roles only works if the team trusts each other enough to let it work. Without trust, doubling becomes resentment.
Those three are the architecture variables. Skill is the floor. But once the floor is there, learning capacity, complementary character, and trust determine whether the team survives uncertainty.
What bad leadership usually does¶
The default is to build the team the budget allows and call it team-building.
The leader looks at what the money can afford, fills the seats, and assumes the architecture has been designed. It has not. It has been accepted.
The other default is to build for the org chart. Roles get filled because the chart says they should be filled. The mission is not in the conversation. The composition is not in the conversation. The chart is.
Both defaults skip the work.
The work is composing for the mission ahead — who fits next to whom, what character covers what gap, who can learn into a hat the org chart does not show yet.
A team is not a collection of talented people.
A team is the right composition for the battle ahead.
The principle¶
Do not build the team only based on the org chart.
Build it based on the mission.
A high-performing team is designed, aligned, and held to a shared standard.
Why it matters¶
A team built for the wrong battle does not announce itself early. It looks fine. The seats are filled. The org chart is complete. The standup runs.
The break shows up later — at the first pivot, the first crisis, the first stretch where the work demands more than the job description.
That is the moment the architecture is tested. A team designed for the mission absorbs it. A team accepted from the budget cracks under it.
Burnout in the top layer. Quiet departures. Lanes blurring as the team fills the gaps the architecture left open. Bugs slipping. The slow grind of a team running inside a shape that was wrong from day one.
None of those are the team's fault.
They are the architecture's fault. The architecture is the leader's job.
What better leadership looks like¶
A leader who composes the team for the mission ahead, not for the org chart that exists.
A leader who reads the mission honestly first — what battle are we facing, what does it demand, where is it likely to move — and then designs the architecture against it.
A leader who selects for capacity under uncertainty, not just skill on the current job description. Skill is the floor. Capacity is the slope.
A leader who builds in architectural slack when the mission is unstable. Roles that can flex. Characters that complement. Trust that holds through a pivot.
A leader who, when the team starts overflowing its lanes, reads the overflow as a system signal rather than as misbehavior. The diagnostic is what gap in the architecture are they filling, not why are they overstepping.
A leader who sells the mission honestly — including the difficulty, including the uncertainty — and asks for real commitment, not compliance.
The framework — M.A.T.C.H.¶
I did not have this framework then. I built it later from the bruise.
Five elements, in order. Skipping one collapses the rest.
M — Mission. Define the battle.¶
Before composing the team, define what the team is being composed for.
What are we trying to achieve? Why now? What problem are we solving? What happens if we fail?
What does success look like?
And — this is the question most leaders skip — what kind of mission is this? Speed, quality, recovery, growth, crisis, or transformation?
A speed mission and a quality mission demand different team compositions. A recovery mission and a growth mission demand different team compositions. Naming the kind of battle is part of defining the battle.
If the mission is unclear, the architecture cannot be designed. It can only be guessed at. That was my first mistake.
A — Architecture. Design the team composition.¶
Architecture is the work most leaders skip and call hiring instead.
Hiring fills seats. Architecture decides which seats need to exist, who fits next to whom, and what gaps need to be covered by what kinds of people.
The questions:
Builders or maintainers? Fast movers or careful thinkers? Technical depth or business translators? Stabilizers or challengers? Calm under pressure? Detail-oriented? Communicate upward? Own ambiguity?
The balance to design across: technical, personality, pressure tolerance, thinking style, ownership, chemistry, mission fit.
This is also where architectural slack lives. If the mission is unstable, slack has to be designed in — not hoped for. Capacity to absorb a pivot, roles that can flex, trust that survives a strategic change.
The Capacity Read below is the diagnostic for the A element specifically — particularly for early-stage and uncertain-mission environments.
The Capacity Read
When you cannot hire for the perfect skill match, evaluate three capacities instead.
1. Learning capacity.
How fast does this person learn into something they have not done before? In early-stage environments, every person will eventually wear a hat their job description does not include. Learning capacity is the variable that determines whether they can.
2. Complementary character.
Where do this person's strengths and gaps complement the rest of the team? A team of identical shapes will fail in identical ways. A team of complementary shapes can cover for each other when one of them is loaded.
3. Trust.
Will the team trust this person under pressure? Will this person trust the team back? Trust is what allows the doubling of roles to actually work. Without it, doubling becomes resentment.
T — Translation. Translate the mission into each person's role.¶
A defined mission and a designed architecture are not enough. Each person on the team has to know what the mission means for them.
What does this mission mean for this person specifically? What role do they play? What strength is being relied on? What weakness needs to be covered by someone else?
What decision can they own? What standard must they meet?
Translation is the moment the mission becomes operational. A team that has heard the mission but never had it translated to their own role will execute by guessing. The guesses will be wrong in different directions for different people.
C — Commitment. Get real buy-in.¶
The previous chapter named sell, do not transmit as a forward-pointer. This is the longer version of that move.
Translation produces understanding. Commitment produces ownership. They are different things.
After the role is translated, the leader has to ask — and mean — does this make sense to you?
What concern do you have? What disagreement? What support do you need? Are you willing to own your part?
A team that nods at the mission is not committed. A team that has surfaced its concerns, had the disagreements honestly, and then signed up — that is committed.
This is also where the mission has to be sold honestly. Including the difficulty. Including the uncertainty. A team that bought a clean version of the mission and finds out the real version mid-flight is a team that quietly stops buying. Selling does not mean hiding the hard parts. Selling means making the hard parts visible and asking people to commit anyway.
H — High Standard. Hold the line after commitment.¶
The H element only works because C preceded it.
Once the mission, the architecture, the role, and the commitment are in place, the standard exists. The standard is the agreed mission, used as the basis for feedback and accountability.
The shape of the feedback is specific:
We agreed this team needs clarity and ownership. This output does not match that standard. Let's fix it.
Notice what that sentence does. It references the agreement. It names the gap. It points to the fix.
It does not reference the person's identity. It does not punish. It holds the line on what was already agreed.
If the team never agreed to the standard, holding them to it is just fear management dressed up. The C element is what keeps H from drifting there.
That sequence — commitment first, standard second — is what makes the H element ethical.
The five elements together:
The M.A.T.C.H. Worksheet
M — Mission. Define the battle.
What are we trying to achieve? Why now? What problem are we solving? What happens if we fail? What does success look like? Is this speed, quality, recovery, growth, crisis, or transformation?
A — Architecture. Design the team composition.
Builders or maintainers? Fast movers or careful thinkers? Technical depth or business translators? Stabilizers or challengers? Calm under pressure? Detail-oriented? Communicate upward? Own ambiguity? Balance: technical, personality, pressure, thinking, ownership, chemistry, mission.
T — Translation. Translate the mission into each person's role.
What does this mission mean for this person? What role, behavior, strength, weakness? What decision can they own? What standard must they meet?
C — Commitment. Get real buy-in.
Does this direction make sense? What concern do they have? What disagreement? What support do they need? Are they willing to own their part?
H — High Standard. Hold the line after commitment.
Use the agreed mission as the basis for feedback and accountability. Example: We agreed this team needs clarity and ownership. This output does not match that standard. Let's fix it.
Ethical boundaries¶
M.A.T.C.H. is easy to misread as a way to extract more from a team. It is not. The four fences below are inseparable from the framework.
The four M.A.T.C.H. fences
Inspire people. Do not manipulate them.
The mission is sold honestly, including the parts that are hard. Selling is not theater. If the team would not have signed up for the real version, the leader did not sell — the leader manipulated.
Challenge people. Do not exploit them.
Stretch is part of building a high-performing team. Exploitation is not. The line is whether the challenge is in service of the mission and the person's growth, or in service of getting more output for less.
Sell honestly. Do not hide difficulty. Do not fake reward.
A team that finds out the real difficulty mid-flight stops trusting. A team that finds out the reward was not what was promised stops committing. Both costs are paid for years.
Do not use loyalty to demand unhealthy sacrifice.
"We are a family" is not a substitute for fair workload. Loyalty is built. It is not extracted. A leader who uses loyalty to ask for what is unhealthy is spending capital that was meant for something else.
These four fences live with the framework. If a team-build move would fail any of them, the framework does not authorize the move.
The point is not to engineer commitment.
The point is to design a team that can carry the mission ahead, honestly.
That is the responsibility behind M.A.T.C.H. The framework is the discipline. The fences are what keep the discipline from drifting into pressure.
Simple rules¶
- Build for the mission ahead, not the org chart that exists.
- Read the mission honestly first — including what kind of battle it is — before composing the team.
- Under mission uncertainty, design in architectural slack. Roles that can flex, characters that complement, trust that holds.
- Select for capacity, not only skill. Learning capacity is the variable that determines whether the team scales.
- When the team overflows its lanes, read it as a system signal. Find the architectural gap. Do not punish the overflow.
- Translate the mission into each person's role. Understanding is not commitment.
- Sell the mission honestly, including the hard parts. Ask for real commitment, not compliance.
- Hold the standard the team agreed to. Not a standard the team never signed up for.
Reflection questions¶
- What battle is this team being composed for? Have I named the kind of mission honestly?
- Did I design the architecture, or did I accept the one the budget allowed?
- Where is the architectural slack? What absorbs the next pivot?
- Am I selecting for skill on the current job description, or for capacity under the uncertainty ahead?
- When the team starts overflowing its lanes, which architectural gap are they filling?
- Has the mission been translated into each person's role, or only announced?
- Did the team commit to this, or comply with it?
- Is the standard I am holding one the team agreed to?
Reminder¶
The team I built then was the team the budget allowed. The team I learned how to build later was the team the mission needed. The difference between the two is the framework above — and the discipline to use all five elements, not just the easy ones.
A high-performing team is designed, aligned, and held to a shared standard.
In a startup, you cannot avoid doubling roles. Once the skill floor is there, what matters is learning capacity.
That is the standard.