n(n−1)/2
Why Your Team Is Drowning in Conversation and How Math Explains Everything
n(n−1)/2
Why Your Team Is Drowning in Conversation and How Math Explains Everything
Lisbon
An engineer’s spouse sends them to the store with a simple instruction: “Go buy a gallon of milk. And if they have eggs, get six.”
The engineer comes home with six gallons of milk and no eggs.
“Why did you buy six gallons of milk?!”
“Because they had eggs.”
If you’ve ever spent time with software engineers, you probably get the joke. It’s funny because it’s really a documentation bug hiding as a grocery list. The spouse meant: buy milk, and if there are eggs, buy six eggs. The engineer understood it as: buy milk; if eggs exist, set the milk quantity to six. Both make sense logically, but only one gets you breakfast.
This joke gets laughs at a dinner party, but it’s a lot less amusing when it shows up in your sprint planning, architecture review, or roadmap meeting. And yet, it happens all the time, not because engineers are flawed, but because our communication methods just aren’t built for the complexity we’re dealing with.
Let’s talk about why this happens. I’ll start with a formula that most engineering managers know, but few really take to heart. It’s so important that anyone who’s ever said, “Let’s just add more people to the project,” should have it written on their arm.
The formula is this:
n(n−1)/2
Where n is the number of people on your team, and the result is the number of unique communication lines between them.
Let that sink in for a second. Then let me show you what it actually means.
The Math That Ruins Everything
A team of three has just three communication lines. That’s easy to manage. With three people, everyone stays in the loop, and it can feel like you’re reading each other’s minds. This is why startup founders look back on their garage days fondly, not because the garage was comfortable, but because working together was straightforward.
A team of five has ten lines. That’s still doable, but you start to notice some friction. Meetings take a bit longer. Slack gets busier. Someone missed the update about the API change.
A team of eight has 28 lines. Now things get tricky. There are 28 pairs of people who might need to talk. Standups stretch to fifteen minutes instead of five. Three people get stuck because they missed a decision made in a conversation they weren’t part of.
A team of twelve has 66 lines. With fifteen, it’s 105. Twenty people means 190 lines. And a department of fifty? That’s 1,225 communication lines.
This isn’t a simple, straight-line problem. It’s a combinatorial explosion. Each new person you add doesn’t just bring one more line of communication; they add as many lines as there _a_re people already on the team. So, the ninth person adds eight new connections, not just one.
Here’s the problem: each of those lines can cause a milk-and-eggs situation. Every connection is a chance for confusion, missed context, or wrong assumptions. The more lines there are, the more ways things can get mixed up.
Fred Brooks said in 1975 that adding people to a late project just makes it later. He was right, and n(n−1)/2 proves it. This formula also shows that communication is the biggest bottleneck for any team, and it’s harder to manage than any system you’ve built.
The Dunbar Problem
Robin Dunbar, a British anthropologist, suggested that people can keep stable social relationships with about 150 others. The exact number is debated, but the main idea holds: our brains can only track so many relationships.
Here’s what’s less discussed: Dunbar’s number isn’t about how many people you can know. It’s about how many relationships you can maintain. And there’s a massive difference. You can know 500 people at a conference. You can maintain a meaningful working relationship with maybe a dozen.
For engineering managers, this connects directly to team size. Research from Amazon (the two-pizza team), Google (Project Aristotle), and the military (fire teams and squads) all point to the same answer: the best team size is between five and eight people.
Why? With five people, there are ten communication lines. With eight, there are twenty-eight. That’s still a range where one person, the manager, tech lead, or coordinator, can keep track of all the connections. They know who’s talking to whom, can spot gaps, and step in before a milk-and-eggs problem becomes a real issue.
But with twelve people and sixty-six lines, it’s impossible to keep up with every interaction. Things start to slip through the cracks—not because anyone is to blame, but because the system is just too complex for anyone to follow fully.
This isn’t a management failure. It’s a math problem. And you can’t solve math with motivation alone.
Why We’re All Buying Six Gallons of Milk
Let’s go back to our engineer at the grocery store. The communication failure wasn’t about intelligence; it was about having different frames of reference.
The spouse was operating in what I’ll call the shopping-list frame, a mental model where milk and eggs are separate items on a shopping list, and “get six” obviously refers to the last item mentioned. The engineer was operating in the logic frame, a mental model where statements are parsed sequentially, conditionals modify the nearest applicable variable, and ambiguity is resolved through scope rules.
Neither frame is wrong. They’re just different. And the failure happened at the boundary between them.
This same dynamic happens in engineering teams every day:
A product manager says, “We need this feature to be fast.” They mean: the user experience should feel responsive. The engineer hears: the API response time needs to be under 100ms. The PM gets confused when the engineer over-optimizes the backend but ships a UI with three loading spinners.
An executive says, “We need to be more innovative.” They mean: we need to find new revenue streams. The engineering team hears: we should adopt cutting-edge technology. Six months later, the codebase is running on a bleeding-edge framework that nobody can hire for, and revenue hasn’t moved.
A manager says, “This is a high priority.” Without context, that sentence is meaningless. High priority compared to what? Higher than the other three things you told me were high priority last week? Higher than the production bug I’m currently debugging?
Each of these is a milk-and-eggs problem. The words were clear, but the meaning was unclear. That ambiguity spread across every communication line, leading to different interpretations for everyone.
The Art of Framing
So what can you do? You can’t change the math, and you can’t change how people process language. But you can get much better at framing, the skill of presenting information so there’s less gap between what you mean and what others hear.
Here’s my framework for framing. I use it in every meeting, every document, every Slack message that matters.
1. State the Frame Before the Content
Before you share information, let people know how to approach it. This is the most effective communication habit I’ve learned.
Instead of: “We’re going to rebuild the search service.”
Say: “I want to discuss a technical investment that will slow feature delivery for three weeks but will eliminate the performance problems we’ve been patching for six months. The proposal is to rebuild the search service.”
The first version lets everyone interpret it their own way. The engineer thinks about architecture, the PM worries about the roadmap, and the designer wonders about UI changes. The second version sets the frame: it’s a trade-off between short-term speed and long-term stability. Now, everyone is looking at the same issue.
2. Make the Implicit Explicit
Most communication failures happen in the gap between what was said and what was assumed. The milk-and-eggs joke is entirely about implicit assumptions.
Get pathologically specific. Not “This is urgent” but “This needs to ship by Thursday because the customer demo is Friday.” Not “Make it scalable” but “Design it to handle 10x our current traffic within the next 18 months.” Not “Fix the bug” but “The checkout flow crashes when a user has more than 50 items in their cart; we need a fix before the holiday sale.”
Yes, this takes more words. Yes, it can feel overly detailed. But clear, detailed communication is much more efficient than short messages that get misunderstood. Every minute spent being precise saves hours of fixing mistakes later.
3. Translate Between Frames
When you communicate across disciplines, like engineering to product, sales, or executives, you’re acting as a translator. Your job is to take an idea from one perspective and explain it in another.
Technical debt to an executive: “We’re spending 30% of our engineering capacity maintaining old systems instead of building new features. Investing two sprints in cleanup will free up that capacity permanently.”
A product pivot to engineers: “The market data shows our enterprise customers care about reporting three times more than they care about the collaboration features. We’re not abandoning collaboration, but we’re shifting the ratio of investment to match where the revenue is.”
A timeline slip to a customer: “We discovered a quality issue that we want to resolve before releasing to you. We’re choosing to delay by one week rather than ship something we’re not proud of.”
Notice the pattern: each translation starts with why (the listener’s context), then gives what (the information), and finally covers so what (what it means for the listener). Context, information, and impact, in that order, every time.
4. Use Concrete Analogies, Not Abstract Principles
This is the one I care about most, and it’s at the heart of everything I write.
Abstract: “Our microservices have high coupling, which creates cascading failures.”
Concrete: “Our services are like a row of dominoes. When one falls, it knocks over the next one. We need to add space between the dominoes.”
Abstract: “We need to implement circuit breakers to improve system resilience.”
Concrete: “You know how a fuse box in your house trips a breaker when there’s a power surge, so the whole house doesn’t burn down? We need the software equivalent.”
Analogies work because they use what the listener already understands. You’re not making them build a new mental model from nothing; you’re connecting new ideas to what they know. That’s why the milk-and-eggs joke sticks. It’s not just a lesson about communication; it’s a funny story about a real situation.
In The Art of Whispering to Machines, I described a large language model as a “Stadium of Voices”, millions of patterns all shouting at once, and the model picks the loudest chorus. I could have said “LLM outputs are probability distributions over token sequences.” Technically more precise. Practically useless to 95% of the people I was trying to reach.
Precision that no one understands isn’t really precise; it’s just noise.
n(n−1)/2 and AI: The Communication Multiplier
Here’s where things get interesting, and especially relevant for engineering managers in 2026.
AI doesn’t cut down the number of communication lines on your team. In fact, it adds new ones. Now, every engineer has a “conversation” with their AI tools, prompting, iterating, and reviewing output. That’s a line that didn’t exist two years ago. And unlike talking to people, the human-to-AI line has its own, even bigger, milk-and-eggs problem.
When you give an AI a vague prompt, you get what the engineer got at the grocery store: a technically correct answer to a poorly worded request. The AI isn’t failing you; your prompt was unclear. And unlike a human who might ask, “Do you mean the milk or the eggs?”, the AI will confidently do the wrong thing.
This is why prompt engineering and communication skills are, at their core, the same discipline. The CRISP framework for prompting, Context, Role, Instructions, Style, Parameters, is really just a structured version of the framing principles described above:
Context = State the frame before the content.
Role = Tell the AI which frame to operate in.
Instructions = Make the implicit explicit.
Style = Translate for the intended audience.
Parameters = Set constraints that eliminate ambiguity.
A manager who learns to frame problems clearly for their team will also get better at prompting AI. And a manager who gets good at prompting AI will naturally improve at communicating with people. These skills reflect each other.
But What If You Can’t Stay Small?
Here’s the hard truth: not every team can be five to eight people. Some problems are just big. Some products need dozens of engineers. Sometimes, company politics mean you’re managing fifteen people, even if the math says otherwise.
So what do you do when the formula is working against you, and you can’t just “make the team smaller”?
You change your approach. Instead of trying to handle 66, 105, or 190 communication lines by sheer effort, you set up your information flow so most of those lines aren’t needed.
Strategy 1: Create Teams of Teams
This is the most straightforward way to address the math. If you have fifteen people, don’t keep them as one big team (105 lines). Split them into three teams of five (10 lines each) with clear connections between teams. Now, you have 30 internal lines and 3 between teams, a two-thirds reduction.
But here’s where many organizations get it wrong: the connections between teams have to be real. Not just “we’ll sync up in standup.” You need a real interface, a defined API contract between teams, or a shared document that spells out what each team provides to the next and how handoffs work. If you wouldn’t build two microservices without defining their API, don’t set up two sub-teams without defining theirs.
Strategy 2: Be the Starfish, Not the Spider
There’s a book called The Starfish and the Spider by Ori Brafman and Rod Beckstrom that changed how I think about organizational design. The core idea is this: a spider has a central brain. Cut off its head, and it dies. A starfish has no brain at all. Its intelligence is distributed across all its arms. Cut off an arm, and the arm grows a new starfish. Cut the starfish in half, and you get two starfish.
Most managers naturally build spider organizations. They pick one “communication node”, someone who becomes the hub for all information. Maybe it’s the tech lead who knows everything or the senior engineer who owns the key system. It feels efficient. Everyone knows who to ask, and the org chart looks tidy.
But this setup is very fragile. If that person takes a vacation, the team slows down. If they get sick, decisions stall. If they leave, all their knowledge goes with them. You’ve created a single point of failure in your communication setup, the kind of thing you’d never accept in your software.
I prefer the starfish model. Instead of picking communication nodes, set things up so they appear naturally, and always have more than one. Don’t make just one person the payments expert. Instead, use practices like pair programming, spec reviews, rotating on-call duties, and shared documentation so that at least two or three people are always aware of a major feature or product.
This is unconventional. Most management advice tells you to assign clear owners and create explicit hierarchies of knowledge. And there’s a time for that. But when it comes to communication, I’ve found that emergent, decentralized knowledge-sharing is far more resilient than appointed gatekeepers.
Here’s why it works: when multiple people can answer a question about a system, the communication graph self-heals. If Person A is in a meeting, Person B can unblock someone. If Person B is on PTO, Person C has enough context to keep things moving. You’re not routing all traffic through a single node that can fail. You’re building a mesh of overlapping knowledge that degrades gracefully.
So how do you make this happen? You can’t force organic knowledge-sharing, but you can create an environment where it happens on its own. Spec reviews help when the whole team reads and discusses a spec; knowledge spreads. Pair programming helps. Rotating who presents at demos helps. Writing things down in specs, decision records, and runbooks helps, too, because documentation spreads knowledge from one person to everyone.
A spider organization is fast until it breaks, and then it’s a disaster. A starfish organization might be a bit slower day to day, but it never fully breaks. For teams larger than five to eight people, where communication is already tough, resilience is a must. Be the starfish.
Strategy 3: Invest in Asynchronous Overlap
Here’s something surprising: having more meetings often means you don’t have enough documents, not that you have too many people.
When a team of 12 needs to make a decision, the instinct is to schedule a meeting. Twelve people in a room for an hour is 12 person-hours of investment. If half the meeting is spent bringing everyone up to speed on context that could have been written down, you’ve burned 6 person-hours on what is essentially a live reading session.
Instead, write a one-page document that explains the decision, options, trade-offs, and your recommendation. Share it. Give people 24 hours to read and comment. Then, only after that, hold a 30-minute meeting to discuss any remaining disagreements. You’ve swapped 12 person-hours for maybe 3 hours of reading and a 6-hour meeting that’s actually useful because everyone is prepared.
That’s the power of written culture. And it’s about to become the most important skill in your management toolkit.
The Written Culture Revolution
Jeff Bezos banned PowerPoint at Amazon and replaced it with six-page narratives. There’s a famous story about executives sitting in silence at the start of every meeting, reading the memo. When I first heard this, I thought it was a quirky management style. After years of running engineering teams, I now think it’s one of the most important organizational decisions any company has ever made.
Here’s why: a slide deck is a performance. The presenter controls the story, the pace, and what gets emphasized. The audience just listens and follows along. If you have a question about slide 3, you have to interrupt or wait until the end and hope you remember. Details get squeezed into bullet points. Complex ideas get cut down to five words. The presenter looks polished, but the audience doesn’t really understand.
A document is a conversation with the reader’s own brain. The reader controls the pace. They can re-read a confusing paragraph. They can jump ahead to the conclusion, then go back and evaluate the reasoning. They can sit with an idea for a minute before moving on. And critically, they can do all of this on their own time, in their own frame of reference, without needing to be in the same room as anyone else.
Documents scale, but meetings don’t. You can write a document once and have 5 or 500 people read it, with no extra work. A meeting that works for 6 people is a mess with 20. That’s why written culture works at scale: it’s like a broadcast, not a one-on-one chat. It turns n(n−1)/2 communication lines into _n—o_ne for each reader.
From Written Culture to Spec-Driven Development
Written culture is powerful. But something bigger is happening. We’re in the middle of a fundamental shift in how software gets built, and it’s centered on a simple but radical idea: intent is the new source of truth, not code.
For decades, the codebase was king. The code was what mattered. Documentation was an afterthought. Requirements lived in someone’s head, or in a Jira ticket with three bullet points, or in a Slack thread that disappeared into the void. The code was the only artifact that was always up to date, because the code was the thing that actually ran.
AI has inverted this. When an AI coding agent can take a well-written specification and turn it into working software, the specification becomes the thing that determines what gets built. The code becomes an output — an artifact generated from intent. And suddenly, the quality of your spec matters more than the quality of your keystrokes.
This is spec-driven development. And it’s not just a theory, it’s being codified into real tools and workflows. GitHub released an open-source toolkit called spec-kit that provides templates, a CLI, and a structured process for bringing spec-driven development to AI coding agent workflows. AWS built an entire IDE around it, Kiro, an agentic development environment where specs are first-class citizens, not afterthoughts. The industry isn’t debating whether this shift will happen. It’s building the infrastructure for it.
And it makes perfect sense through the lens of n(n−1)/2. When specs are the source of truth, you’re not coordinating through conversations anymore. You’re coordinating through documents. And documents, as we just discussed, turn a combinatorial communication problem into a linear one.
The Specify → Plan → Tasks Workflow
Spec-kit formalizes what good teams have always done informally into a three-phase workflow: specify, plan, and tasks.
Specify. Capture the intent. What are you building and why? Who is it for? What are the constraints? This isn’t a requirements document from 2003 with a table of contents longer than the actual content. It’s a living artifact that answers the questions a competent engineer, or an AI agent, would need answered to build the right thing. In Kiro, this becomes a structured requirements.md file that uses user stories with acceptance criteria, ensuring everyone, human and AI, understands the feature’s purpose.
Plan. Translate intent into architecture. The specification captures the what; the plan captures the how. Components, data models, API contracts, interfaces, and critically, the trade-offs you considered and the alternatives you rejected. Kiro generates a design.md that serves as the technical blueprint. This is where your team’s engineering judgment lives. And documenting the roads not taken is as valuable as documenting the road you chose, it prevents future engineers from relitigating decisions that were already thoroughly debated.
Tasks. Break the plan into small, testable, implementable units of work. Each task builds on the previous ones, with dependency management and markers for what can be executed in parallel. This is where AI agents take over. Kiro generates a tasks.md checklist, and the agent works through it systematically, writing code, running tests, and checking off items. The human stays in the loop as reviewer and decision-maker, not as the person typing every character.
The beauty of this workflow is that it separates the stable what from the flexible how. The spec doesn’t change much during a sprint, but the implementation details do. By keeping them separate, you can update the code without big rewrites, try different approaches, and let AI handle what it does best while people focus on decisions that need judgment.
The Spec Review: Your Highest-Leverage Meeting
Here’s where spec-driven development transforms team dynamics: the spec review.
A spec review is a meeting where the team reads, critiques, and improves a spec before any code is written. It’s like a table read in Hollywood, the actors sit together and read the script out loud, spotting problems and fixing issues before filming starts.
The spec review is, in my experience, the highest-leverage meeting an engineering team can have. Here’s why:
It catches the milk-and-eggs problems before they become code. When someone reads a spec and says, “wait, when you say ‘fast,’ do you mean fast for the user or fast for the backend?” that’s a milk-and-eggs moment that just got caught at the cost of a sentence instead of a sprint.
It builds shared understanding for the whole team. After a spec review, everyone has read the same document, asked questions, and heard the answers. You’ve turned n(n−1)/2 possible misunderstandings into one structured conversation. The spec becomes the source of truth, not just someone’s memory of a standup from three weeks ago.
It distributes ownership. When the team reviews and approves a spec, the decision isn’t one person’s opinion. It’s a collective agreement. This matters enormously when things go sideways mid-implementation. Nobody says, “I never agreed to this approach.” The spec, with their comments and sign-off, says otherwise.
It gives everyone a fair chance to contribute. In a spoken meeting, the loudest person usually leads. In a spec review, the document is what matters. An introvert who leaves a sharp three-sentence comment has as much impact as the extrovert who talks for twenty minutes. Written documents let everyone contribute in ways meetings can’t.
Specs as Executable Intent
Here’s what sets spec-driven development apart from just writing better documentation: in the AI era, specs are executable. A good spec is basically a great prompt. It gives context, sets constraints, describes what you want, and explains why. Give an AI a vague Jira ticket, and you get milk-and-eggs code. Give it a clear spec, and you get something much closer to what you wanted.
GitHub’s spec-kit leans into this directly. The toolkit includes what they call a constitution, a set of immutable principles that govern how specifications become code. Think of it as the architectural DNA of your project: security policies, compliance rules, design system constraints, integration patterns. Things that used to live in someone’s head or get buried in wikis now live in a structured file that both humans and AI agents can use.
Spec-kit also adds complexity gates, checkpoints that stop over-engineering by making the AI explain any extra complexity it adds. If a gate fails, the AI has to document why, which creates accountability for design decisions. This is the kind of guardrail managers need when AI is writing code: not surveillance, but built-in accountability.
Then there’s Kiro, which takes this idea further by building it into the IDE itself. Kiro isn’t just compatible with specs, it’s designed around them. The IDE uses what AWS calls “agent steering”: markdown files that give the AI ongoing knowledge about your product, tech stack, and conventions. With “agent hooks” that trigger security scans, style checks, and tests whenever files change, it feels less like a code editor and more like a system that runs on specs.
The spec is the contract. The review is the negotiation. The AI is the builder. And the result is a team that starts generating code with a level of shared understanding and aligned intent that was simply impossible when the “spec” was a verbal conversation in a meeting that half the team wasn’t in.
Building a Spec-Driven Culture (Without Becoming Waterfall)
I can hear the objection already: “This sounds like waterfall with extra steps.”
It’s not. And the distinction matters.
Waterfall says: write a complete specification for the entire project before any work begins, then build the whole thing according to that specification, and don’t deviate from it. That’s rigid, slow, and ignores the reality that requirements change.
Spec-driven development says: before you start any unit of work, a feature, service, or API endpoint, write a short, focused spec for it. Review it with the team. Then build it, updating the spec as you learn. The spec is a living document, not set in stone. If you find out during the work that the data model needs to change, update the spec, review the change, and keep going. Specs aren’t static; they’re living, executable documents that grow with the project.
The process is Agile. The main artifacts are specs. The culture is written. You get fast iteration and clear documentation. Small teams move quickly, but with well-defined interfaces. It’s the best of both worlds.
Practically, here’s how to start:
Start with one team and one project. Don’t mandate spec-driven development across your entire organization on a Monday. Pick one team, one project, and run the experiment. GitHub’s spec-kit gives you a ready-made starting point, initialize it with a single CLI command, and you get templates for specifications, plans, and task breakdowns out of the box.
Adopt the specify → plan → tasks rhythm. Give teams the three-phase structure. Specify the intent. Plan the architecture. Break it into tasks. This becomes the heartbeat of your development process, replacing the chaotic Jira-ticket-and-pray workflow that most teams run today.
Make specs easy to find. They’re only useful if people can access them. Store them in a central place, a wiki, GitHub repo, or shared drive. Tag and index them. Make it simple for someone to ask, “Is there a spec for the notifications service?” and find it in thirty seconds. AI-powered search makes this even easier.
Celebrate great specs. During team rituals, retros, demos, or any other event, highlight specs that were especially clear, thorough, or insightful. Treat spec-writing as a valuable skill, not a chore. If an engineer writes a spec so clear that the AI’s implementation plan is 90% correct, they just saved the team a week of confusion. Recognize that.
Review specs the same way you review code. This is the big cultural change. Code reviews are standard for any serious engineering team, and spec reviews should be too. Not as a bureaucratic step, but as a way for the team to build shared understanding before starting work. If your team reviews code after it’s written but skips spec reviews, it’s like checking your parachute after you jump.
Practical Moves: Taming Your Communication Graph
Let me bring it all together with a checklist of concrete actions.
Reduce n Where You Can
The simplest way to cut down communication complexity is to make teams smaller. If your team of 12 has 66 lines, split it into two teams of 6 (15 lines each) with a clear connection between them. Now you have 30 plus one line, a reduction of over 50%.
This is the math behind Amazon’s two-pizza teams, Spotify’s squads, and every small-team method that works. It’s not just a belief, it’s simple arithmetic.
Reduce the Cost Per Line
If you can’t make the team smaller, lower the cost of each communication line. Invest in documentation, shared context, and clear conventions to cut down on unnecessary conversations.
Write things down, design docs, decision records, runbooks, and onboarding guides. Each document you create is a broadcast to everyone, replacing up to n(n−1)/2 separate conversations. That’s powerful leverage.
AI makes this even better. Use AI to keep a living knowledge base that your team can search. “What was the decision on caching?” “Who owns this feature?” “What were last week’s action items?” When AI can answer these instantly, you cut out dozens of Slack messages and interruptions every day.
Adopt Spec-Driven Development
For every significant piece of work, a spec is required before writing code. Use the six-question template. Make spec reviews a team habit. Give approved specs to AI for planning. Treat specs as living documents, not just paperwork. This one practice will cut down milk-and-eggs problems more than any meeting tweak.
Create Communication Protocols
Set up clear patterns for how information moves. This isn’t bureaucracy, it’s engineering. Just like you design APIs with clear contracts, design your team’s communication with clear channels.
Put decisions in the decision log. Blockers go in the standup channel. Design discussions use the RFC process. Status updates go in the weekly digest. When everyone knows where to put and find information, communication becomes organized instead of messy. You’re swapping 66 random lines for a few clear highways.
Apply the Grocery Store Test
Before sending any important message, a Slack post, email, design doc, or spec, use the Grocery Store Test: Could someone with a different perspective misunderstand this?
If the answer is yes, rewrite your message. Add context. Be more specific. Remove any ambiguity before it spreads through your team.
Even better, ask an AI to check for you. Paste your message and prompt: “Read this as a product manager, a junior engineer, and an executive. What are the three most likely misunderstandings?” You’ll be surprised by what it finds.
The Formula as a Leadership Compass
n(n−1)/2 isn’t just about communication lines. It’s about the core challenge of getting people to work together. It explains why small teams feel great and big ones feel slow. Why startups move fast, and big companies don’t. Why your best engineer’s productivity dropped when you added three more people.
Every decision you make as a manager, how you set up teams, run meetings, write documents, or frame problems, either works with this formula or against it. The best managers I know understand this so well that they can sense when there are too many people in a meeting, when teams need a better connection, or when a message will be misunderstood before it’s even sent.
That instinct doesn’t come from management books. It comes from knowing that every person you add doesn’t just bring more skills; they add complexity. And if you don’t manage complexity, it can ruin everything.
So next time someone says, “let’s just add more people to the project,” grab a napkin and write down n(n−1)/2. Do the math together. Then have the real conversation: not about how many people you need, but about how to set up communication so everyone understands each other.
Because in the end, it doesn’t matter how many engineers you have if they all come home with six gallons of milk.
By Joshua McDonald on March 2, 2026.
Exported from Medium on August 26, 2026.
Reader discussion