Stop Hunting for Heroes and Villains: Start Thinking in Systems

I was listening to a podcast the other day (I'm not going to link to the specific episode because it's about current events and there are plenty of places to discuss those. I don't want this to become another one but I'll credit the creator, Andrew Heaton).

It broke people down into two categories; "Agentic" thinkers and "Systems" thinkers. The thesis was basically that agentic thinkers blame or credit the performance and actions of individual actors; eg. "Goods are expensive because merchants are greedy" and systems thinkers take a broader view of all the inputs and incentives that lead to outcomes; "Goods are expensive because of supply and demand issues, interest rates, taxes, and the general state of the economy".

Of course, any classification with two categories is going to be a vast oversimplification but it got me thinking about how it might apply to managing software teams and some of the underlying causes of scapegoating and blame culture as were discussed in last week's guest post from Lin Byrne.

Managers are often tasked with identifying the 'source' of problems on their teams. This is even more prevalent now that there exists some standardization of metrics that we can use to measure our teams (DORA, SPACE, DevEx) and available tools that monitor ticket systems and source control to try to quantify some aspects of the development process. These metrics and tools have increased the information available and thus increased the ability for leadership to draw conclusions about team performance. Importantly (and unfortunately) there's no guarantee those conclusions will be sound and the decisions that they lead to will be good decisions.

Agentic vs. Systemic Thinking and Metrics

I don't want to make the whole post about the dangers of over-rotating on metrics. That's a pretty well covered topic elsewhere. At a minimum leaders should familiarize themselves with The Hawthorne Effect (being aware that they're being measured/monitored alters people's behaviour) and the related Goodhart's Law ("When a measure becomes a target, it ceases to be a good measure"). I'm also a big fan of understanding perverse incentives like The Cobra Effect which comes from Economics and is named for a program where the British governors in India came up with a bounty program to get rid of cobras which led to people breeding cobras for the bounty and increased the number of cobras in India.

But anyways, let's say go forward on the assumption that you're measuring some stuff and you've got a good enough grasp on incentives that you're not handing out bonuses for the most PR's merged and not paying people by the line of code. Let's also say one of your metrics is trending in the wrong direction and your boss has taken notice and wants to see some action, what do you do?

If you are an agentic thinker, you might start by looking at your team members. "Who is responsible for this? Is it that one dev I already don't really like? Maybe I'll put them on a PIP. That'll fix it." It might even work. Sometimes the problem really is one person not pulling their weight but in those cases it's usually pretty obvious and the rest of the team probably knows it too. When you're certain, you have a duty to take the appropriate action but only after giving appropriate consideration as to why they have been underperforming first.

If you are a systemic thinker, you're probably going to look at the bigger picture first and consider other factors:

• Have there been structural changes that could be impacting team performance?
• Have incentives changed?
• Have new steps been added to the process? More handoffs?
• Are the priorities clear or have things changed?

People don't show up at work to do a bad job. Everyone can be rowing the boat with all their might but if they're rowing upstream and the current suddenly increases, they're going to make less progress for the same effort. A good leader should be able to recognize that something has changed and take appropriate action.

Systems thinkers use metrics to spot problems in the system

In a similar vein as my post on why AI won't necessarily result in you shipping more software. Basic metrics can tell you things are slowing down, but good metrics can help to tell you why. An agentic thinker will look at one team member's code output and conclude they're not pulling their weight without realizing they spent half the sprint educating the support and marketing teams on how the feature is going to work because the PM who would normally do it was off at a mandatory training session. In another sprint half the tickets can be blocked on approvals but if you only focus on the close rate of PRs it'll look like nothing's getting done. Once again, the code writing might not be the bottleneck in the whole process.

An aphorism you'll hear often in this type of gig is "if you don't measure it you can't manage it", which I don't even think is true 100% of the time. Some things are in the "I know it when I see it, even if I can't quantify it" category and you can totally manage those. In any case, just because you can measure it, doesn't mean you must (or should) manage it. Besides, there are lots of things you can't quantify. How would you measure the fact that you treat your team respects you more than their previous manager who wouldn’t shut up about their team's 'time-in-code-review' metric? Where's your 'impact metric' for being a good boss that people like working for?
Metrics are a sharp sword. Be careful what/who you cut with it.

The No-Stats All-Star and the High Functioning Team

The author Michael Lewis (of Moneyball and The Big Short fame) coined the term 'No-Stats All-Star' in a piece about NBA player Shane Battier. He was a player that never put up big numbers "And yet every team he has ever played on has acquired some magical ability to win".

Battier’s game is a weird combination of obvious weaknesses and nearly invisible strengths. When he is on the court, his teammates get better, often a lot better, and his opponents get worse.

I've had the extreme pleasure of having some "no-stats all-stars" on my teams over the years. I've found this concept to be a very valuable one when thinking systematically about how a team operates. They're usually pretty senior (think Staff+ level, they've seen some shit), have been at the company a while, and have great interpersonal skills.

Some incredibly valuable things these no-stats all-stars bring to the table:

• The ability to steer a Product Manager and their feature plans towards something achievable.
  • They understand the constraints of the existing code base and what's easy vs hard.
  • They've made choices that have bogged down projects before and know how to avoid making them again.
• Acting as an effective communication bridge and translation layer between product, design and engineering.
• Re-framing a project's goals in ways that resonate with the engineering team and get them energized about the work.

This type of work can be really high-leverage, but it's not going to appear on any dashboard anywhere and, in fact, it probably makes their individual metrics look bad while nevertheless making the team's look better. It would be tragic to look at a team's metrics and see a person like that as a weak point rather than the MVP they truly are.

Takeaways for Managers

Assume the system is the problem first.

My advice to new leaders is to assume that when you're not getting the outcomes you expect or want, some aspect of your system is going to be the culprit almost all of the time. Individual performance issues happen and sometimes you make a bad hire or put someone in a role they're not well suited for. Ask yourself if you're really confident that swapping out one person on the team for a randomly selected engineer would solve your problem, if not, look at the bigger picture.

W. Edwards Deming, who was an electrical engineer who went on to study and write about business process said things like:

Eighty-five percent of the reasons for failure are deficiencies in the systems and process rather than the employee.

The role of management is to change the process rather than badgering individuals to do better.

Expect that the system will fight back

Change is hard and whatever system you're faced with didn't arise on its own, unbidden, from nothing. It was put there by people operating under the incentive structure that was in place at the time. People don't like change in general and they really don't like change that messes up their incentive structure. Changing a system is not an easy task even when the problems are clear and the better way seems obvious.

There are aspects of it which are under your control and aspects of it which are not. The Chaotic-Good Manager will change the things where they can and find ways to route around or compensate for the things they can't fix. The latter is varsity-level management though and can easily get you into trouble or at least make you enemies if you're not careful. Nevertheless, it's your responsibility to bend the system where you can to get the outcomes that you and your team want to achieve. Your team will notice and they'll respect you greatly for it. They feel the ways the system gets in their way every day.

Recognize and reward the things the metrics miss

Do not underestimate the value that those who act as cultural glue, who are skilled at unblocking the team or who are single-handedly keeping everyone and the stakeholders in strong alignment. These can be your unsung heroes but it's better if you recognize that work for the value it provides as much or more as you recognize your high-output performers.

Finally

Leaders who master systemic thinking build organizations where individuals succeed without needing to be heroes and where villains are rarely the root cause. Nobody likes working for finger-pointing managers who can't help themselves but to place blame. It ruins psychological safety and reduces trust to the point that it becomes counterproductive.

I'll leave you with one more Deming quote to close things out:

Put a good person in a bad system and the bad system wins, no contest.

"Tufts, Head of the Charles" by crschmidt is licensed under CC BY 2.0 .