This newsletter is sponsored by Unblocked.

[Webinar] How to stop babysitting your agents

Agents can generate code. Getting it right for your system, team conventions, and past decisions is the hard part. You end up wasting time and tokens in the correction loops.

More MCPs, rules, and bigger context windows give agents access to information, but not understanding. The teams pulling ahead have a context layer to give agents exactly what they need for the task at hand.

Join live on Sep 23 (FREE) to see:

• Where teams get stuck on the AI maturity curve and why common fixes fall short

• How a context layer solves for quality, efficiency, and cost

• Live demo: the same coding task with and without a context layer

If you want to maximize the value you get from AI agents, this one is worth your time.

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

It’s important to realize that a lot of the problems teams face today are not new. We’ve been struggling with coordination, missing deadlines, bad metrics, adopting “shiny new technologies” for quite a while now.

That’s why understanding the laws like Conway’s Law, Brooks’s Law, Goodhart’s Law, Hofstadter’s Law, Amdahl’s Law, and Amara’s Law are so important and truly timeless.

And what’s important to mention is that in today’s AI era, many of them are becoming even more relevant. With the speed of building increasing, the bigger bottleneck becomes coordination, communication, and good leadership.

In today’s article, Dr Milan Milanovic will be sharing the most important laws you need to know for leading engineering teams. He’ll also be sharing examples of these laws from his personal experience.

Let’s introduce our guest author and get started.

Introducing Dr Milan Milanovic

Milan is a CTO, Microsoft MVP, and also an author of the book Laws of Software Engineering. He has more than 20 years of experience both as an engineer and engineering leader, working across many different industries.

I know Milan for quite a while now, and we chat occasionally on various topics. Today, he’s been kind enough to share some of the important insights from the book adapted for this article.

Over to you, Milan!

Understanding the specific software engineering laws is crucial for leading engineering teams

Throughout my 20-year career in tech, especially working at big companies and on large projects and teams, I noticed some specific patterns. Back then, still a young engineer, I couldn’t define them well.

Later, when I worked on some other projects and in new companies, I noticed the same patterns again. It became obvious to me that the same mistakes happen in almost every company.

This was the first time I researched a bit more about them, and it was immediately obvious that they are not new and some are old, like 20 or 30 years or more (Brooks 1975 and Conway 1967).

What also surprised me was that most of my colleagues back then didn’t know about them.

The second time I came across them was when I was writing an article on why engineering teams’ estimations and plans fail. It became obvious that a lot of these laws play a big role and are crucial for success of engineering teams.

So, my recommendation if you want to lead a high-performing engineering team, is that it’s really important that you know and understand the laws I am going to share today.

What’s also important to mention is that, with the emergence of AI in the last few years, a lot of these laws are even more important than before because we have shorter cycles, smaller teams, and a lot of these laws can be violated much faster.

Let me start with the first law!

1. Conway’s Law

This one is probably the most well-known of all laws, and it can be harder to grasp and understand, especially if you’re just starting in the industry.

It says that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

Let me share an example.

If we have small distributed teams of a few engineers working in different places, the architecture of the system will probably be Microservices. Why? Because it reflects the organizational and communication structure of the team. On the other hand, if we create one large team, we will probably have one big monolith.

I remember once working on a big banking project with a large team; the system was one big monolith, and it was really hard to maintain.

Then we sat down and created a new organizational structure with subteams, and split our monolith into modules, so it became a modular monolith.

Each subteam became the owner of one module. It was not possible to split the architecture into modules before reorganizing teams first.

It’s important to note that we should not copy someone else’s structure, e.g., the Spotify model, because this model solved their coordination problem, not ours.

2. Brooks’s Law

This one is also very important for leading engineering teams, and the reason is that we are often in a situation where our projects are late.

There are a few things we can do in this situation, and I’m sure that every leader has tried to solve this problem by adding more people to the team (or teams).

This is exactly what Brooks’s Law warns us about which states that adding more people to a late project only makes it later.

It looks a bit contradictory at first glance, but if we think a bit more about it, it is not. When we add more people to the late project, we do 2 things:

1. We increase the number of communication and coordination channels in the team.

2. And we take time from the existing team members to do their job, because they need to take part of their time to work and onboard new people.

The math is simple, e.g., with 8 people in the team, we have 28 communication paths, while if we have 6 people in the team, we have 15.

Let me share an example from my experience next.

In one of our projects, we had 8 team members, and we were always late for our deadlines. We tried different things, such as making estimations with buffers, hiring new people, etc. But we always ended up being late on our commitments.

What happened after was that 2 people left our team, and all of a sudden things became more efficient, and we managed to deliver on our commitments.

This was surprising, but as communication paths dropped from 28 to 15, obviously this had an impact.

What I found is that there is also a way to measure this, and is called Little’s Law, which comes from queuing theory.

Little’s Law (L = λ * W) refers to work in progress, throughput and lead time. For example, If your team completes 5 tasks per week and you have 20 in progress, the average lead time is 4 weeks. Increase WIP to 40 with same throughput, lead time is 2x now.

So when you add people to a late project WIP goes up and throughput stays flat. The outcome? Longer lead times, not shorter. Reduce work in progress (WIP) before adding people if you want to get things done faster.

3. Goodhart’s Law

This one is probably the most relevant for managers and leaders. And it’s becoming even more important due to AI.

This law states that when a measure becomes a target, it stops being a good measure.

Many companies make a mistake where they measure certain metrics and treat their direct outputs as goals.

Some examples of this are:

• lines of code written,

• test coverage percentage,

• tickets closed, etc.

The main problem with this approach is that when we attach our goals to outputs, people will find a way to gamify these metrics and become good at increasing them, while not actually increasing business value.

I remember when, in my early days, our manager considered better engineers those who produced more code, although we knew this was not true.

Once, one of our best colleagues decided to remove 1,500 lines of code and simplify one of our modules in payroll. The system became simpler and faster, yet our manager rated that as an example of a not-good job.

Now, with AI, we see similar trends with spending AI tokens (tokenmaxxing). Engineers who spend more tokens are considered more valuable, and some companies even created leaderboards for that.

So, how to solve this problem? Focus on outcomes, not outputs. Define metrics, but use them only as proxies, not targets or rewards.

The focus should be on producing meaningful results. Here is an example:

The metric “Cycle time” alone just tells us that something is moving, but cycle time + what we shipped this month, and whether it provided value for the users, tell us a more complete story.

In our team, we saw a good example of this when we decided to move from Scrum to Kanban and completely remove story points and estimations.

Before, we always tried to achieve our velocity and measured everything by it, yet we spent a massive amount of time on estimations, discussions, etc.

When we removed them, our team became much more efficient, and we could produce more value for our users.

Sidenote: The Bus Factor

The Bus Factor states the minimum number of team members whose loss would put the project in serious trouble.

A bus factor of 1 means one person holds critical knowledge; if they disappear, the project is essentially ‘doomed’ or stalled. A higher bus factor (e.g., 5) means the project could lose any one of 5 specific people before stopping work.

It’s basically a measure of knowledge distribution and risk. A high bus factor is good (knowledge is shared among many), while a low is bad (single points of failure in expertise).

Teams should work to increase their bus factor by sharing knowledge, documenting critical systems, having code reviews, and rotating responsibilities.

Let me share an example from my experience. Once, we had an engineer on our team who was the only one who knew our billing system, and he was preparing for a long vacation.

This was Bus Factor 1, and it’s very problematic. We decided to pair him with another person who would take over some important parts of the system, moving Bus Factor from 1 to 2, and he was no longer a single point of failure.

The question we should always ask for every member of our team is: If person X leaves us tomorrow, can we still operate? If no, then there needs to be more exchange of knowledge.

4. Hofstadter’s Law

As we worked in Scrum for years, we had all the regular estimation sessions. After some time, we figured out that we actually missed each of the deadlines we set.

We knew this, and we tried everything we could to improve, but still deadlines were mostly missed.

This was exactly what Hofstadter’s Law defines: it always takes longer than you expect, even when you account for Hofstadter’s Law.

And when we tried to analyze this (didn’t know about the law then), we figured out that there are many moving parts in our work. API integrations depend on someone else; one engineer got sick, some of our designs didn’t match reality, and more.

Also, there is something called the Ninety-Ninety rule, which says that the first 90% of the project takes 90% of the time, and the last 10% takes the other 90%, and this is true.

When engineers think about the project, they mostly think about the first 90%, and this is actually the core of the implementation, e.g., business rules.

But the last 10% could take the same amount of time, as they didn’t account for integration delays, authentication, edge cases, and more.

Taking all of this into account, I have a few simple rules to follow. First, if I need to estimate some work, I say:

• If it takes 2 min, do it immediately

• If it takes a “few minutes”, estimate it at an hour

• If it takes a “few hours”, estimate it as a day.

Another important thing is communication with stakeholders. We need to be open and honest with them, and what this means is that we don’t accept any roadmaps longer than a quarter to give any kind of estimate.

And for all the estimations, we should always add buffers to cover the Ninenty-Ninety rule.

Here we need to mention also Parkinson’s Law, because it says that work will expand to fill all the time available for it. So, if we can finish something in a day, but we estimated 3 days, it will probably take the full 3 days to finish.

I was on teams where estimations took more time than the implementation itself. So, we as leaders need to take both laws into account when working on projects. It is always better to have short deadlines with clear objectives than longer ones.

5. Amdhal’s Law

This law defines why AI productivity is not the same for everyone. For example, if half of our workflow is sequential, the maximum we can get from speedup is 2x.

If that workflow is 90% parallel, then we can get a 10x improvement.

The main thing here is that often we think that Software Development Life Cycle (SDLC) = coding, but it is not.

It includes many other parts of the job we need to do, such as deciding what to build and how, communication with the product team, reviewing code, waiting for different kinds of approvals, and more.

Coding is now much faster, but the other parts stayed the same. What I found is that teams that were able to increase their productivity more are those that made the human-in-the-loop part smaller.

It is the same on the organizational level as well. If we have an ivory architect or a CTO who needs to approve every decision, adding more resources to the project will not speed it up; you will just get a longer queue.

So, in order to improve your processes first measure the sequential part, because only adding more resources to the parallel part will not do miracles.

6. Amara’s Law

This law is also known as the Hype Cycle and is something we have seen for decades in tech.

We tend to overestimate the effect of technology in the short term and underestimate it in the long term.

We saw this starting in the 1960s and 1970s when work on AI systems started; it promised general intelligence, but the results were modest.

We also had a few long AI winter periods. In the meantime, research continued to work on AI (e.g., Prof. Hinton and his work on neural networks when everyone thought it is a dead end), and now, with all the tools from the past few years, we have seen remarkable changes in our industry.

Usually, the loudest voices are those who don’t use technology so much. So, the short-term promise was not true, while the long-term promise is something we could not imagine.

The same thing we had with Microservices. It was marketed as a one-size-fits-all solution for any scaling problem, but then we had many replicated projects that had more services than users.

I remember seeing only microservices architecture on many projects I worked on, often asking myself if it was really needed. In most cases, it was not.

For leaders, it is important not only to be right with decisions, but to be right at the right time too. If we miss the timing, then it is the wrong decision.

If we adopt it at the top too early, this could cost us later when everything changes (this is actually a Dunning-Kruger effect).

If we completely fail to adopt it, then we are late to adopt something everyone is already using.

What we should do is to treat innovation as a budget. Most of our track stays on proven technology (see Lindy Effect after), while we take small tries on hyped things. If it proves successful, then we expand it; if not, remove it.

Sidenote: The Lindy Effect

Together with the Hype Cycle, we should mention the Lindy effect, which says that the longer something is in use, the longer it will stay in use.

E.g., take an example of SQL from the 1970s or COBOL, which is used in half of the world’s banking transactions. On the other hand, we have all seen many libraries and frameworks that are not used anymore.

So, our main selection should be around the things that are proven and have been around for many years. AI changed one thing, and that is that it is much easier to replace certain legacy software.

A big COBOL codebase was not touched because no one fully understood it. Now, with agents, it’s much easier to do so. Yet, the fundamentals like algorithms, system design, architecture, and data structures are still very crucial.

So, now we should not ask anymore how long this technology will be with us, but whether it is the best way to solve the problem, and if AI can more efficiently replace it.

For me, I invest in things that AI cannot easily replace, such as fundamentals and judgement.

Using the laws together

We should know that no problem involves only one law, but usually a few of them. If our delivery is slow, there are 2 or 3 laws impacting this. The wrong turn would be to fix it before we know which ones exactly.

This is a checklist I run when I have an issue in a team:

1. Conway’s Law

Does our team structure match the system? If this is not true, we are probably losing too much time in coordination activities.

2. Brooks’s Law

Did we add any new people recently? If yes, then this could lead to a stall in the project.

3. The Ringelmann Effect

If our teams have 8 or 9 people or more, the output for each of them will probably drop.

4. Goodhart’s Law

If the team meets goals but our product is not better, nor are users satisfied, then the metric has become the target.

5. Broken windows theory and Tech Debt

This one is usually forgotten. If the codebase is in the state where no one bothers to fix issues, then this is a big problem. Even with AI, this doesn’t improve.

So, to conclude, we don’t need to know all the laws. If we have an issue with our team, we should do the following: 1) name the forces, then 2) rank them by importance. If you have a deadline, Hofstadter is more important than Amdalh.

Also note that in some cases, there are different laws that contradict each other; e.g., Brooks’s Law and Linus’s Law are both true, but in different contexts.

Last words

Special thanks to Milan for all the insights with us! Check him out on LinkedIn, and also check out his book Laws of Software Engineering to get to know all the important laws in software engineering.

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Check out my book “The Multiplier Mindset” coming out later this year, here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.