Engineering One-Liners That Save Projects: From “Camel by Committee” to “9 Women, 1 Baby”

Engineering one-liners that save projects: “camel by committee” and “9 women, 1 baby”

In a 30 minute roadmap review, I’ve watched 14 stakeholders add 40 “must have” requirements. The team shipped three months late, and NPS dropped 6 points. That’s why the one-liners matter. They pack hard-earned lessons into words people actually remember. You can use them to stop bad plans early and protect teams from chaos.

These jokes cut both ways, though. Used badly, they turn into cheap shots at PMs or “the business.” That’s not the goal. Use them as a shared language for constraints, trade-offs, and decision rights.

What “a camel is a horse designed by committee” means in product and architecture

Most CTOs I talk to struggle with the same thing: too many voices and no clear decider. The camel line points at a real failure mode. Teams treat every opinion as equal, then glue every request into one release.

ProductPlan defines design by committee as a process where many parties contribute, and the team treats all input equally, then makes decisions collectively. The result often satisfies nobody, even with good intent. See ProductPlan’s guide to avoiding design by committee.

Contentsquare uses the camel quote for the same pattern. Stakeholders say “I’m a user,” and the team reacts to every comment. The product drifts away from the real target user. See Contentsquare’s strategies to avoid design by committee.

Here’s the framing I use with my own teams.

• Feedback is free. Decisions aren’t. Collect 50 opinions if you want. You still need one call.
• A committee can review. A committee can’t own. Ownership needs a name and a calendar invite.
• Every “yes” is a “no” to something else. Scope grows, quality drops, and timelines slip.

The hidden technical cost of committee design

Committee design usually doesn’t fail on day one. It fails in the second and third order effects, the stuff you’re stuck living with for years.

• API sprawl. You add endpoints for edge cases. You keep them forever.
• Data model bloat. You add fields for every stakeholder report. You end up with null-heavy tables.
• Permission complexity. You add roles for every org chart. You ship auth bugs.
• Reliability drag. You add dependencies. Your blast radius grows.

I’ve seen this in a B2B SaaS org with 9 squads and 120 engineers. They let Sales, Support, and two enterprise customers drive “just one more” workflow. The UI became a choose your own adventure. Support tickets rose 18 percent in one quarter. Then the team spent two sprints ripping out features nobody used.

Dovetail calls out the same pattern. When no decision process exists, the next version misses user needs and quality drops. They use the Pontiac Aztek as a famous example of committee-driven design. See Dovetail’s design by committee definition and examples.

A simple rule that stops the camel

I use a rule I call the One Throat, Many Ears rule.

• One person owns the outcome and the trade-offs.
• Many people give input, with context and data.

This isn’t anti-collaboration. It’s pro-accountability.

If you want something practical, run this checklist in every roadmap review.

Anti-Camel Checklist (print this)

• Decider named. One person can say yes or no in the meeting.
• User named. The team can describe one target user in one sentence.
• Metric named. The team can state one success metric, with a number.
• Constraints named. The team lists two hard constraints, like latency under 200 ms.
• Trade-offs stated. The decider says what they will not do this quarter.

If you can’t fill these five lines, you’re building a camel.

What “9 women can deliver a baby in 1 month” teaches about schedules

The baby line is a blunt way to say “some work doesn’t parallelize.” In software it shows up as a staffing fantasy: a leader sees a slip, adds people, and expects the date to snap back.

The quote circulates widely in PM humor. See the Reddit thread that repeats the line. The joke lands because teams have lived it.

The real lesson isn’t “PMs are dumb.” It’s that time has physics.

Why adding people often makes you slower

Software has three schedule killers that compound fast.

• Onboarding time. New engineers need context. Seniors stop coding to teach.
• Coordination overhead. Every extra person adds communication paths.
• Work that is serial. Some steps must happen in order, like schema changes.

I’ve watched a team try to “crash” a migration by doubling headcount from 6 to 12. Weekly throughput dropped for four weeks. They lost the staff engineer who held the mental model. The migration finished two months late.

If you want a non-software parallel, construction research talks about schedule compression techniques like fast-tracking and resource reallocation. It can work, but it raises risk and cost, and it needs careful use. See The Impact of Schedule Compression Techniques on Construction Project Timelines.

Same idea in software. You can compress schedules, but you pay in defects, rework, and burnout.

The CTO move: separate “more people” from “less time”

When someone asks me, “Can we do it in half the time?” I don’t argue. I ask two questions and make the trade-offs visible.

What part is serial, and what part is parallel?

Use this split.

• Serial work. Architecture decisions, data migrations, security reviews, cutovers.
• Parallel work. UI variants, test automation, docs, backfills, customer comms.

Then pick one of three schedule levers.

• Reduce scope. Cut features, not quality.
• Change the method. Use a safer migration pattern, like dual writes.
• Add people to parallel work only. Don’t add people to the critical serial path.

APM makes a related point in their agile myth piece. Strong delivery still needs governance, clear purpose, and transparent decision-making. Speed comes from decisions close to the team, not from pretending plans don’t exist. See APM on agile myths and governance.

How CTOs can use these one-liners without turning cynical

I’ve watched these lines poison relationships. An engineer drops “camel” in a meeting and a designer shuts down. A CTO jokes about “9 women” and a PM stops raising risks.

You can keep the humor and still lead like an adult.

Use the joke as a flag, then switch to a tool

I coach teams to treat one-liners like a smoke alarm. It tells you something’s wrong. It doesn’t tell you what to do next.

So when someone says “camel,” switch straight to a tool.

• “Who is the decider?”
• “What user are we building for?”
• “What metric are we moving?”

When someone says “9 women,” switch to a different tool.

• “Show me the critical path.”
• “What is serial?”
• “What can we cut without breaking the goal?”

That keeps the tone respectful. It also trains the org to move from vibes to decisions.

A quick decision matrix for committee pressure

Here’s a link-worthy element you can reuse. I call it the Committee Pressure Matrix.

The point isn’t to avoid input. It’s to match the decision style to the risk.

Practical playbook: what to do in your next roadmap and delivery cycle

This is where CTO craft shows up. You set decision rights and you protect the critical path.

Here are actions you can run this quarter.

Immediate actions (next 30 days)

1. Name DRIs for top bets. Put one name next to each Q3 initiative. Put it in the doc and the calendar.
2. Run a scope kill meeting. Ask each DRI to cut 20 percent of scope. Keep quality bars fixed.
3. Map the critical path. Draw the serial steps on one page. Include data migrations and approvals.
4. Stop “everyone review” PRDs. Limit required reviewers to 3 to 5 people. Let others comment.

If you need a place to track this work, use Command Center at /command-center to log initiatives, risks, and incident load. It helps you see when “just one more feature” collides with capacity.

Policy framework (set the rules once)

1. Decision rights policy. Define which decisions need an architecture review, and which do not. Document it.
2. Feedback policy. Require feedback to include a user, a scenario, and a metric. No metric, no change.
3. Schedule compression policy. Allow fast-tracking only with a written risk list and rollback plan.

This is also a good time to standardize how you document architecture. Our ArchiMate Modeler at /tools/archimate helps teams keep diagrams current, so new hires ramp faster.

Architecture principles (keep systems buildable)

1. Small interfaces. Keep APIs narrow. Reject “future proof” endpoints without a user.
2. Reversible changes. Prefer migration patterns you can roll back in minutes.
3. Limit dependencies. Every dependency adds failure modes and coordination.

If you’re debating a vendor tool to reduce delivery time, use our Build vs Buy Matrix at /tools/build-vs-buy-matrix. It forces a real trade-off discussion, not a committee vote.

And if your org claims it needs more engineers to hit dates, check the data. Our Engineering Metrics Dashboard at /tools/engineering-metrics-dashboard helps you track lead time, deploy frequency, and change failure rate. Those numbers tell you if headcount helps or hurts.

Bigger picture: committees and schedule fantasies are governance failures

Engineering has dealt with this for over a century. Standards bodies exist because some decisions need clear rules, not endless debate. ASME formed a Boiler Code Committee in 1911, and published the Boiler and Pressure Vessel Code in 1915. Many jurisdictions later adopted it into law. See ASME’s engineering history. That’s governance in action.

Engineering education also treats design as “design under constraint.” The 1956 Grinter report pushed integrated study of analysis, design, and systems. Later work described engineering as “design under constraint.” See Burian Associates on engineering education history.

Software teams forget this under pressure. They treat design as preference and schedules as wishes. The fix isn’t more process. The fix is clear decision rights and honest plans.

If you want to go deeper, this connects to other work we cover at The Art of CTO: our guide to architecture governance that doesn’t slow teams down, our playbook for incident postmortems that change behavior, our notes on platform teams as internal products, and our field guide to engineering planning and capacity.

So here’s the question I ask in exec staff meetings: are you running your product like a system with constraints, or like a committee with opinions?

Sources

1. ProductPlan: How to avoid design by committee
2. Contentsquare: Strategies to avoid design by committee
3. Dovetail: Design by committee definition and examples
4. ASME: Engineering history and BPVC timeline
5. Burian Associates: Engineering education history and “design under constraint”
6. Open Civil Engineering Journal: Schedule compression case study
7. APM: Agile myths and governance
8. Reddit: “9 women can deliver a baby in 1 month” PM joke thread