Design Is a Balanced Team Sport

Ask a team if they're cross-functional and almost everyone says yes. Product, design, and engineering all sit together, all show up to standup, all have their names on the org chart. Cross-functional is easy. Balanced is rare.

The difference is who gets a vote.

I spent four years at Pivotal Labs coaching enterprise and government teams into a way of working we called the balanced team. It's the longest I've stayed anywhere, and it's still how I think about building - so much so that it shaped the firms I went to next. The core idea's almost embarrassingly simple, and almost nobody actually does it: product, design, and engineering are equal partners in shaping what gets built, how, and why. Not "engineering builds what product specs." Not "design makes it pretty after the requirements are locked." Equal voice. Equal vote.

Three lenses, one product

Every meaningful product decision has to survive three questions, and each discipline owns one:

• Desirable (design): is this something users actually want and can use?
• Feasible (engineering): can we build it with the time, skills, and technology we have?
• Viable (product): does this work for the business?

Good products live where all three overlap. Miss one and you can name exactly what you'll get. A beautiful product nobody pays for. A great business plan that can't ship on time. A technically elegant thing users quietly hate. The failure modes aren't mysterious. They're just what happens when one lens doesn't have a vote.

That last phrase is the whole game. Not "doesn't have a voice" - most teams let everyone talk. "Doesn't have a vote." Voice means you get to raise the concern. Vote means your concern changes what happens next. A team where the engineer flags a usability problem and the PM says "noted" and ships anyway has voice without vote. It looks balanced in the retro and behaves like a feature factory in the roadmap.

The four values under the structure

The triad is the structure. Structure alone doesn't make a team balanced, because balance is a behavior, not a seating chart. Four values keep the structure honest, and I've watched teams live or die by them:

Create trust. People know each other as people, not just roles. They're trusted to act in the business's interest, and - this is the part managers resist - trusted to ask for help when they're not sure. Psychological safety isn't a poster. It's whether the junior engineer will contradict the senior PM in front of the room.

Share experiments. Great products get discovered piece by piece, not conceived whole in a moment of genius. Run hypothesis-driven experiments and share every outcome, so the whole team owns the learning instead of one person hoarding the context. A result only the PM sees is a result the team can't act on.

Celebrate failure. A failed experiment is an invalidated hypothesis, not an embarrassment to bury. The sooner a team produces failures, the sooner it steers off a doomed path. Teams that treat failure as shameful stop running the risky experiments, which are the only ones worth running. I've seen a team throw a small party for killing a feature idea two weeks in. That team shipped the right thing three months later.

Welcome diverse voices. Everyone shapes direction regardless of title - engineers weigh in on the experience, designers weigh in on the stack. And you actively welcome the voice that dissents from consensus, because the person contradicting the room is often the one seeing the risk nobody else named.

Miss one value and the others erode. No trust, no honest experiments. No celebrated failure, no real experimentation. No welcomed dissent, no diverse voices worth having. They hold each other up.

How to tell if your team is actually balanced

You don't need a survey. You need to watch a few things:

• One person writes all the stories. Product is running a feature factory; design and engineering aren't shaping scope.
• Design reviews happen after build. Design is a finishing step, not a thinking partner.
• Engineering raises a concern and it gets overridden on the way to the deadline. Feasibility doesn't have a vote.
• "The business wants X" ends every debate. Viability is trumping the other two lenses.
• Standup feels like a status report to one person. The team has a hierarchy it hasn't admitted to.

If you recognize your team here, the fix isn't a reorg. It's smaller and harder: give the missing lens a real vote, rotate who runs the meeting, and name your tradeoffs out loud. "We're cutting the design polish to hit the date - that's a desirability tradeoff, are we okay with it?" Making the lens explicit stops one discipline from being silently deprioritized, which is how imbalance usually happens. Not by decision. By default.

Why this still matters

I coached this model at a Fortune 500 enterprise and at a five-person pro bono design sprint for a food-rescue startup, and the shape held at both ends. Balance isn't a luxury for well-resourced teams. It's the cheapest way I know to stop building the wrong thing, because the wrong thing almost always ships when one lens wasn't in the room with a vote.

Name who has a vote. Build the structure that gives all three lenses one. Then watch what your team stops shipping - and what it starts.

Sources

• The balanced-team model, the desirability/feasibility/viability lenses, and the four values (create trust, share experiments, celebrate failure, welcome diverse voices) come from Pivotal Labs, where I spent four years coaching teams into this way of working. Written here as lived practice.
• The four values are set out in the Pivotal white paper Striking the Right Balance with Balanced Teams (Jarrell & Berner, 2019).