1. The Pareto Principle: Focus on what truly matters
In business and engineering, effort doesn’t always scale with results. Most of what you do doesn’t move the needle. The Pareto Principle—better known as the 80/20 rule—states that 80% of outcomes come from just 20% of inputs. It applies everywhere: a fraction of your customers generate most of your revenue, a small portion of your product features drive the majority of user engagement, and a handful of bottlenecks cause the most system failures.
Engineering managers who grasp this principle can radically improve efficiency. The challenge then is knowing which 20% to focus on. And that’s where things get tricky. Cognitive biases and group dynamics make prioritization difficult. Teams often waste time on low-impact decisions, a phenomenon known as bike-shedding (from Parkinson’s Law of Triviality). This happens when people obsess over minor, easy-to-understand details (like picking a UI color) while neglecting complex but important issues (like system architecture).
Then there’s design by committee, where too many stakeholders dilute decision-making, resulting in bloated, mediocre products. The more voices in the room, the less decisive leadership becomes. This is compounded by groupthink, where consensus-driven choices replace sharp, independent thinking.
So, what’s the fix? Brutal prioritization. Use data-driven decision-making to identify high-impact areas. Cut distractions. Trust the numbers, not opinions. The best leaders focus on the work that truly moves the business forward. If you’re optimizing everything, you’re optimizing nothing.
2. Hofstadter’s Law: Everything takes longer than expected
Planning is an illusion. No matter how much experience you have, no matter how many times you’ve been burned before—everything takes longer than expected, even when you expect it to take longer. That’s Hofstadter’s Law in action, and it’s a fundamental truth in software development and business.
Why is estimation so hard? Because modern systems are absurdly complex. Every software project is built on layers of dependencies, unpredictable interactions, and unseen technical debt. You have to write code and integrate it into an ecosystem where one wrong move can break everything.
There are a few well-known culprits behind underestimation:
- The Ninety-Ninety Rule: “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for another 90%.” This explains why projects crawl at the finish line—bug fixes, integration, and edge cases consume more time than expected.
- Parkinson’s Law: “Work expands to fill the time available.” If you give a team six weeks to deliver a feature, they’ll take six weeks—even if it could be done in four.
- Hidden complexity: Every application has an irreducible level of complexity (Tesler’s Law). Some things can’t be simplified without breaking functionality.
So how do you work around this? Add a buffer. Take your most optimistic estimate and add 50% to it. That’s realism, not pessimism. Underpromise, overdeliver. Be prepared for unknowns. If a project looks like it will take six months, assume eight. And never assume a deadline means something will be finished. Deadlines are just hopeful guesses and reality always wins.
3. Brooks’s Law: Adding people to a late project makes it later
Most executives assume that if a project is behind schedule, the obvious fix is to throw more people at it. Logical, right? More hands, faster output. Except that’s completely wrong. Brooks’s Law, named after Fred Brooks (author of The Mythical Man-Month), states that adding people to a late software project only makes it later.
Here’s why:
- Communication overhead: Every new team member increases coordination complexity. In a five-person team, there are only 10 communication channels. Double the team to ten people? Now there are 45 communication channels. The more people you add, the more time gets spent in meetings, syncing knowledge, and avoiding misunderstandings.
- Onboarding delays: New engineers need time to ramp up. They ask questions, need guidance, and slow down senior team members. Instead of speeding up development, they introduce friction.
- Task divisibility: Some tasks can’t be split among more people. If a software module requires deep architectural understanding, throwing more engineers at it won’t help—it might even make things worse. You can’t speed up a pregnancy by hiring nine women to each carry the baby for one month. Some things just take time.
So what’s the alternative? Instead of increasing headcount, optimize for efficiency.
- Streamline workflows: Remove unnecessary blockers and redundant steps.
- Improve automation: Use tools that cut down on manual tasks.
- Enhance collaboration: Well-aligned small teams outperform large, fragmented ones.
“Companies like WhatsApp, Airbnb, and GitHub scaled massive businesses with lean engineering teams. They focused on working smarter, not just working bigger. Throwing bodies at a problem is a lazy way to avoid fixing deeper issues. The real challenge is making sure the team you already have is working at full potential.”
4. Goodhart’s Law: Metrics alone won’t fix your problems
What gets measured gets managed. When a measure becomes a target, it ceases to be a good measure. That’s Goodhart’s Law, and it explains why performance metrics, when used blindly, can backfire.
Executives love metrics. They want simple numbers to track productivity, efficiency, and success. The problem? Software engineering isn’t a factory line. You can’t measure knowledge work the same way you measure output in a manufacturing plant. Developers have to solve problems, refactor code, and prevent disasters before they happen.
Take lines of code (LoC) as an example. If you judge engineers by how much code they write, they’ll write more—but more isn’t necessarily better. More code means more bugs, more maintenance, and more complexity. A great engineer might delete thousands of lines of bad code and improve performance, but if you measure productivity by LoC, they’ll look unproductive.
Or look at bug count reduction. If a team’s performance is judged by reducing the number of reported bugs, they might start playing the system:
- They fix easy bugs first (instead of tackling real problems).
- They avoid reporting issues (to keep numbers low).
- They push quick, temporary fixes (that create long-term technical debt).
So what’s the solution? Smarter metrics. Industry leaders have moved away from naive measures and embraced holistic frameworks like:
- SPACE Framework: Considers Satisfaction, Performance, Activity, Communication, and Efficiency to get a balanced view of engineering productivity.
- DORA Metrics: Measures deployment frequency, lead time for changes, mean time to recovery, and change failure rate—real indicators of high-performing software teams.
- Developer Experience (DevEx): Focuses on removing friction from developer workflows rather than forcing artificial productivity goals.
At the end of the day, metrics should guide decisions, not dictate them. Measure what matters, but never let numbers replace judgment. The best leaders know that great teams aren’t built by chasing the wrong targets. Instead, they’re built by creating an environment where people can do their best work.
5. Conway’s Law: Your organization’s structure shapes your software
Your software architecture reflects your org chart. That’s Conway’s Law, and it explains why your systems end up just as fragmented, slow, and bureaucratic as your teams.
Melvin Conway’s insight is simple: The way teams communicate determines how their software is built. If your teams are siloed, your architecture will be too. If different departments barely talk to each other, expect mismatched APIs, duplicated work, and inefficient workflows.
“The software doesn’t shape the company—the company shapes the software.”
Look at big enterprises with rigid, bureaucratic structures. Their systems are often bloated, slow, and full of inefficiencies—just like their decision-making process. On the other hand, companies with small, autonomous teams build faster, more modular, and adaptable systems.
Amazon figured this out early. Jeff Bezos enforced the “two-pizza rule”—teams should be small enough that they can be fed with two pizzas. That structure led to microservices—small, independent software components that communicate with each other, just like Amazon’s lean teams.
So, how do you apply Conway’s Law to your advantage?
- Align teams with architecture: If you want modular software, structure your teams to match. Break monolithic teams into smaller, focused groups with clear ownership.
- Encourage cross-functional collaboration: Great systems aren’t built in silos. Foster communication between engineering, product, and business teams.
- Reduce organizational friction: Simplify decision-making, cut unnecessary layers, and make sure teams can move fast without waiting for approvals from ten different people.
If your software is a mess, don’t just blame the developers. Take a long look at your company’s structure. Fix the communication bottlenecks, and your systems will follow. The best tech companies design great teams that make great software inevitable.
Key executive takeaways
- Prioritize high-impact tasks: Focus on the 20% of tasks that drive 80% of the results (Pareto Principle). Identify and prioritize the most valuable projects to maximize team productivity and avoid wasting resources on low-impact work.
- Plan with realistic timelines: Embrace Hofstadter’s Law—projects will almost always take longer than expected. Add a buffer to your time estimates to account for unforeseen complexities and ensure more accurate delivery timelines.
- Avoid scaling teams as a solution: Brooks’s Law shows that adding more people to a late project often makes it later. Instead of expanding teams, streamline processes, improve communication, and foster collaboration to maintain efficiency and reduce delays.
- Use smart, holistic metrics: Don’t rely on one-dimensional metrics like lines of code or bug counts. Adopt frameworks like SPACE or DORA to evaluate productivity more effectively and drive meaningful improvements without distorting outcomes.
