jmoiron plays the blues

Defensive strategies in football fall into two main categories: zonal marking and man marking: ¹.

In zonal marking, defenders guard territory. By spreading out, they can react to a variety of plays more quickly, and when they win the ball back, their team will have a better shape from which to launch a counter attack.

In man marking, defenders mark opposing players. If all of the defenders do their jobs, then the attacking team will have trouble finding a player in enough space to score.

In open play, teams have marked zonally for a long time. The pitch is just too large to prevent a player from having space by following them around, and it's trivial for the offensive team to manipulate the defensive team's shape when man marking is used extensively.

At set piece time, the story is more complicated. In the early 2000s, an influx of continental coaches brought zonal marking at set piece into the English game. Statistically, it was about on par with man marking, but the reaction from British pundits was uniform disgust. It was so maligned and misunderstood that one of the top english language tactics blogs named itself zonal marking.

These days, most top teams have adopted zonal marking, or some hybrid, on set piece. Thanks to the influence of Moneyball, data collection and analysis has since saturated sport at the top levels, so literally everyone has the statistics that show zonal marking's effectiveness. But pundits continue to hate on it. Why? What's happening here?

One of the big reasons is the way that zonal marking fails.

No defensive tactic is going to work 100% of the time. When man marking fails, it's easy to identify an individual who is at fault. The system of man marking itself can escape culpability, because you can point at someone and say "you didn't mark your player".

When zonal marking fails, individual responsibility is invisible to observers. You can't see a communication breakdown, but you sure do notice the vast space it leaves for the attacker to score from. The attacking team scored a goal, so surely, something failed? There's nothing left for an onlooker to do but to blame the system.

Successes get overlooked, too.² Successes are easy to overlook in any system; you don't see the failures that don't happen. When zonal marking works, credit is reserved for the defender and not the system.

Since you don't see its positive effects, and its failures are disproportionately attributed to the system itself, over time a perception builds that zonal marking fails more often than man marking, even when the data says otherwise.

I first heard this explanation from Raphael Honigstein, but I noticed aspects of this effect applying to a lot of software engineering systems ever since. Sometimes, a system is like zonal marking; it obscures individual blame at the cost of its own reputation. Other times, it's like man marking, and being able to blame individuals for mistakes can blind everyone to its obvious systemic problems.

The most recent discussion where I brought this up was about an engineering twitter favourite, monorepos vs multirepos. In this situation, a monorepo trades off individual flexibility for collective benefits, and the multirepo makes the opposite tradeoff.

Suppose you are already using a monorepo. You check in some code, but there is a failure in your CI/CD system unrelated to your changeset. Maybe it's a failing test in some foreign code, or a long build time, or a mystifying merge conflict. It's often hard to find a single person at fault, so the monorepo approach itself gets the blame. After all, if you could have a separate repo, you could avoid the problems related to other people's work entirely.

Meanwhile, the successes of the monorepo are easy to overlook. If the failure was a test in some code that imported your component, the tradeoff was a success and a bug you introduced was caught. But nobody does a fistpump and thanks the monorepo. Instead, you curse your personal oversight and fix the bug.

Conversely, the multirepo failure scenarios are easy to blame on individuals. If you fail to run the tests for all of your dependents, you failed, and not the multirepo system. It's right there, in step 7c of the merge and deploy process! You apologize and fix the error, but the structure of the multirepo is not perceived to be at fault.

Both the monorepo and multirepo failure cases are real systemic failures and legitimate criticisms. If you run a repo, chances are a lot of your tooling is designed to mitigate these types of failures.

I've made zonal marking sound like the connoisseur's approach taken by "top level" teams that gets dogged on by people who don't understand it. This is.. kind of true³ where zonal marking is concerned, but this doesn't mean that the collective system will always produce better outcomes. The worlds best futsal and beach football teams employ man marking heavily.

You cannot blindly apply the favoured approach of other highly successful teams out of context and get optimal results. You need to understand how their tradeoffs map to your local conditions. The zonal marking effect doesn't invalidate criticisms of these systems, it only amplifies the impact of collective failures and dampens the impact of individual failures on perceived systemic weakness.

Just as it's important to realize that a zonal marking system is copping extra blame, it is important to realize that a man marking system is failing while escaping scrutiny. There are plenty of man marking type systems in software engineering, and they can be so effective at shifting blame onto individuals that there is decades of evidence that memory safety issues are the major cause of problems in the entire industry, but C and C++ programmers will often defend these languages by blaming errors on "unskilled" practitioners.

Think about how this would be perceived in train or airline safety. If casual negligence by one individual can cause catastrophic failure, the system is dangerous and needs to be fixed.

What can we do to neutralize this effect?

Frustratingly, it's not as simple as trying to identify and avoid man marking type systems. The popular ones are popular because their tradeoffs are sound engineering in some contexts, and thus defensible.

A shift in how we consider failure will help. I think software developers can learn a lot from how operations has been evolving. Most companies have more computers than developers, so an organized approach to producing good operations outcomes happens earlier in a company's lifetime. It is also difficult to assign personal blame to computers.

There is a ton of literature about data collection and measurement of operations success, and applying it across different organizations seems more straightforward. No book will perfectly outline a strategy for your org, but they work to reframe our problems in terms of systemic failure, and allow us to measure and iterate effectively. Our ops strategies are more mature, data driven and systematized than software development strategies.

The rennaisance in ops strategies has coincided with the rise of the blameless postmortem. The blameless postmortem does not try to obscure individual error. Instead, it reframes the discussion around that failure, and in the process it exposes the truth that all failures are system failures.

Hopefully, this mindset is rubbing off on developers as more companies have decided to assign operations responsibilities to their developers. The next step is to adopt this consistent "systemic framing" to our practice failures. Consider doing a blameless postmortem next time the damn build fails, and see if you can unpack the ways the system as a whole failed. You might find something about it you can fix!

1. It's universally called "man marking" as far as I can tell, even in the many other sports where it's employed. I couldn't find a non-gendered term for this with any significant usage.

2. On corner kicks, it's common to place a player near one or both posts of the goal, freeing the keeper to guard the middle of the goal and to potentially attack the ball. This comes at a cost of one or two defenders, which is a big tradeoff! When a goal is scored near the post, invariably the lack of a defender is blamed, but when a goal is scored despite a player being positioned there, it's unusual for pundits to blame the post player tactic for making the space that allowed that attacker to put a shot on goal in the first place.

3. The overwhelmingly negative reception of zonal marking is in no small part due to the parochial mindset of the British punditry and their skepticism about continental football despite it being clearly more successful.