Estimated reading time: 14 minutes

Managing teams invariably means that something, at some point, will go wrong. Understanding common principles to tackle engineering hurdles might be just the thing you need to pull yourself out of a hole.

If you’re a manager, you’ve most likely heard of Goodhart, Conway, Hofstadter, and Brooks – authors of principles and laws that shed light on the complexities of delivering software.

While the laws these individuals brought to the table aren’t ironclad universal formulas, these systems are a good way to understand why things go sideways and how to overcome the challenges of engineering management.

Engineering management is as much about people and priorities as it is about technology. Think of this as your crash course in 11 essential laws and principles every engineering manager should know.

The Pareto Principle (aka the 80-20 rule)

“Roughly 80% of consequences come from 20% of causes” – Joseph M. Juran

The Pareto Principle, also known as the 80/20 rule, highlights that a small percentage of causes (the “vital few”) often drive the majority of outcomes, while the remaining causes (the “useful many”) still contribute meaningfully, but at a lesser scale.

In engineering management, this principle is invaluable for setting priorities. Ruthless prioritization is paramount when crafting a technology roadmap, but it’s equally critical for product roadmaps. Time and time again, I’ve seen the Pareto Principle in action: 20% of software features typically account for 80% of user interactions, and 20% of software bugs are responsible for 80% of system failures.

Deciding which 20% to focus on is no trivial task. Managers must navigate a minefield of cognitive biases and group dynamics that can derail efforts to prioritize effectively.

Here are some common pitfalls:

• Parkinson’s Law of Triviality: teams often spend a disproportionate time debating minor issues, while more complex, critical decisions are neglected. As Parkinson’s example famously illustrates, a committee might deliberate longer on the color of a bike shed (hence the term “bike-shedding”) than on a nuclear reactor’s design. To complicate matters, this law is often heightened by Sayre’s Law: “In any dispute, the intensity of feeling is inversely proportional to the value of the issues at stake.”
• Design by committee: trying to appease every stakeholder often results in diluted decisions and weaker products. This effect is compounded by group dynamics like groupthink, the tyranny of small decisions, the bandwagon effect, etc., all of which can obscure clear priorities.

For engineering managers, applying the Pareto Principle is about more than identifying the vital few – it’s about resisting distractions and overcoming biases. Big decisions require thorough information gathering, a clear understanding of long-term implications, and the courage to focus on initiatives that truly move the needle for your organization.

Hofstadter’s Law

“It always takes longer than you expect, even when you take into account Hofstadter’s Law” – Douglas Hofstadter

Once you’ve identified the 20% of tasks to focus on, the next challenge is estimating the time and resources required to accomplish them. Despite being a critical part of planning, estimation is notoriously difficult – and almost always inaccurate.

Hofstadter’s Law perfectly captures this paradox: things will always take longer than you expect, even when you take into account that they’ll take longer than you expect. 

Several factors exacerbate our inability to make accurate estimates in software development:

• Software complexity: modern systems are vast, interconnected, and ever-evolving. There’s no ceiling to how intricate they can become, especially when dealing with poorly understood systems. The lack of visibility, documentation, and understanding also has to contend with Tesler’s Law, which states, “Every application has an inherent amount of complexity that cannot be removed or hidden…”
• Unknown effort: estimating the effort required to ship a feature or complete a project is so famously error-prone that it gave rise to the ninety-ninety rule.  “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”
• Flawed processes: agile methodologies, while powerful, are often misapplied. Rigid sprint schedules can unintentionally validate Parkinson’s Law: “Work expands so as to fill the time available for its completion.”

While there’s no perfect formula for accurate estimation, my rule of thumb is simple: add 50% to your initial estimate. By underpromising and overdelivering, you mitigate the risks of underestimation and build a buffer for unforeseen complexities.

Brooks’s Law

“Adding [more people] to a late software project makes it later” – Fred Brooks

After presenting project estimates, leadership might ask, “How can we speed this up?” Often, the knee-jerk response is to add more engineers. But as Brooks’s Law illustrates, this approach is likely to backfire: adding engineers to a project increases communication overhead and can temporarily reduce productivity.

While Brooks acknowledged that this law is an oversimplification (and less applicable to highly divisible tasks), the core principle holds.

To visualize this, consider how communication channels increase exponentially as team size grows. According to the formula N × (N – 1) / 2, ten communication channels exist for a team of five engineers. Double the team size to ten, and the channels jump to forty-five. More people means more coordination, more meetings, and more potential for misalignment.

This principle extends beyond individual productivity – it also affects the organization’s technology landscape. As Conway’s Law states: “any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

In today’s distributed engineering world, where teams span multiple locations and time zones, a poorly structured org and communication pattern can lead to siloed teams and fragmented architectures. Subdomains may drift out of alignment with business capabilities, creating inefficiencies.

It’s not always about throwing bodies at a problem. History shows us that smaller, highly aligned engineering teams often outperform larger ones. Companies like WhatsApp, Spotify, Airbnb, and GitHub achieved remarkable success with lean teams focused on clear goals and efficient collaboration.

If speeding up delivery is the goal, focus on these areas instead of simply adding people:

• Review software methodologies: ensure your processes support efficiency and alignment.
• Foster collaboration and shared understanding: build a culture where engineers have a holistic grasp of the system architecture.
• Reduce manual overhead: tools like auto-documentation or more efficient debugging solutions can significantly cut down wasted time.

In short, more hands on deck isn’t always the answer. Thoughtful processes, clear communication, and streamlined tools will get you there faster – and with less frustration.

Goodhart’s Law

“When a measure becomes a target, it ceases to be a good measure” – Charles Goodhart

So, you’ve selected your “vital few” priorities, estimated the time and effort involved, and optimized delivery. The final hurdle? Measuring the success of your project.

Measuring the productivity of knowledge workers like engineers is notoriously difficult. Developers don’t just write code – they mentor, review, design, manage releases, and much more. Reducing this complex, creative work to a single metric often backfires. This is the essence of Goodhart’s Law: “Over-focusing on a single measure inevitably distorts the very outcomes you’re trying to achieve.”

Using lines of code as a productivity metric illustrates this exact issue. Developers used to churn out verbose, inefficient code simply to inflate their numbers. The result? Bloated systems, harder maintenance, and reduced quality.

However, other metrics encounter similar problems. Consider a team tasked with reducing bug counts. At first glance, fewer bugs might signal success. But what if, in their rush to hit the target, the team prioritizes quick fixes over long-term solutions? This could result in technical debt piling up beneath the surface – turning a low bug count into a misleading metric, masking the system’s fragility.

Many frameworks attempt to tackle the challenge of measuring success in software development. While some show a naive understanding of its complexities – like the McKinsey productivity framework that sparked heated debates in the dev community – others take a more thoughtful approach, such as SPACE, DORA, and DevEx.

The key is recognizing that developer productivity is more than just what’s easy to measure – like pull requests, deployment frequency, or bugs fixed. Effective measurement requires balancing “hard” data with qualitative insights into how developers feel about their work and what’s slowing them down.

After all, improving developer productivity isn’t just about tracking numbers; it’s about empowering teams to do their best work without unnecessary friction.

Final thoughts

In engineering management, understanding and applying these principles and laws isn’t just theoretical – it’s practical wisdom for navigating the complexities of software development.

By embracing these timeless insights and pairing them with modern methodologies, you can empower your team to focus on what matters most: building great software.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.