Art of Controlled Burn in Engineering Management

Estimated time reading: 5 minutes

Firefighters across the world have been using the Controlled Burn to control forest fires. The idea is super simple; create a small fire that you fully have control of to prevent a much larger disaster from occurring. The assumption is that were you to do nothing, a much larger disaster would occur.

In agile, it’s very much accepted that no team likes disruptions; to achieve the best experience, everyone would love to work like a well-oiled machine. Exceeding all expectations and absolutely demolishing sprint after sprint. But, like the firefighters, can we apply a strategy that looks very similar and utilized controlled disruptions rather than actual fire (don’t set your co-workers on fire, please)?

Application of a small controlled disruption with an expected outcome can yield amazing results and carve you out as a much more proactive manager rather than a reactive one.

If you are having issues convincing the stakeholders of your intentions, try using the Triple-A Method.

Acknowledge that you are causing a disruption

Admit that you will take the blame for causing it

(Axe)plain what you are trying to achieve and why. Describe the forest fire you are trying to prevent. If they still do not budge, drop the axe on them. Let them know that in the event of a forest fire, they will be on the hook.

Scenario 1 (success)

Jon is a Senior Developer. He’s been on the same product for almost a year. He’s become super comfortable and can crank out any feature thrown at them by the product team. You ask him if he’d like to move teams, but he’s become too good at his job, and he knows he will not be nearly as effective as he is currently. The product team also lets you know that all deadlines have been set based on Jon’s ungodly output and that without him, they will not hit their commitments. You know how 2 options. Do nothing. Or deploy a controlled burn; move Jon to a different project, similar enough to allow him to utilize his skill check but challenging enough that it is not the exact same thing.

Controlled Burn: You decide to replace Jon with a more junior developer, Steve. But have Jon train him.

Acknowledge: Removing Jon will cause quite a bit of a slow down to the team. The delta in velocity is going to put a much larger strain on the release timeline.

Admit: You realize your action has a potential negative business impact. You know Jon’s team will not be as effective as they are now, and it will take time to reach that same effectiveness again. If there are concerns, all stakeholders should come to you directly.

(Axe)plain: By giving Jon coaching experience and a brand new project with brand new complex problems to sink his teeth into, you are trying to keep him engaged. The forest fire, which may occur at some future point in time, will be caused by Jon leaving completely. The loss of institutional/domain knowledge will cause a far greater disruption overall. As his manager, you will remind your superiors that you were prevented from mitigating this.

Scenario 2 (success)

You are in charge of a team that does not write Unit Tests. You decide to introduce this concept to the team and ask for them to adopt it. After a few sprints, the product manager lets you know that your team has drastically slowed down in completed work. Deadlines are upcoming, and he is wondering why such a drop in performance. After listening to your explanation, he tells you to stop your developers from writing unit tests. Again you have two options; Stop your team from writing unit tests. Or deploy a controlled disruption and let them keep going.

Controlled Burn: Allow your developers to keep going with your mandate to keep the code base unit tested.

Acknowledge: By introducing unit testing, features take longer to write. Pull requests take longer to merge in. All estimations increase in size, causing the project plan to inflate.

Admit: The drop in team performance is directly related to your introduction of an additional constraint on the team. The team is also very new to unit testing, so the learning curve is having a negative impact as well.

(Axe)plain: You are attempting to add to your team’s overall Developer Satisfaction. Well-written Unit Tests force developers to write better code by design. And while they do add to the overall work, the long-term effect of having a clean codebase with a sense of accountability for keeping it that way will have an exponential effect down the line. The forest fire will occur at a point in time when the codebase becomes unmanageable, and all performance and velocity grind to a halt. If that does occur, the way to put out this forest fire would be to mandate rewrites of large portions of the code base, a far greater disruption. As the manager, you will remind your superiors that you were prevented from mitigating this.

While these scenarios are a great thought experiment, they do not in any way represent the real world. These are too black and white and too perfect. It is entirely possible that a controlled burn can turn into a forest fire if you do not deploy it correctly. No matter everyone’s best intentions. Let’s go over the previous examples through the lens of failure.

Scenario 1 (failure)

While Jon is far happier with his new work and direction, his absence has a much larger effect on his previous team than you expected. His replacement does not even come close to Jon’s performance, and the team suffers greatly as a whole. By missing key deadlines, the business takes overall hits to the bottom line. Your controlled burn is now a forest fire, and you are to blame.

Scenario 2 (failure)

While the team is far happier with the codebase and their overall performance, your mandate has made your team a bottleneck in the delivery pipeline since no other team writes Unit Tests. With your team now being a bottleneck, they are forced to work much harder and longer to meet both the deadlines and your expectations. Developer Satisfaction has actually decreased overall, and the team is now mentally close to burnout. Your controlled burn is now a forest fire, and you are to blame.

Caution, burn hazard

As you can see, Controlled Burn is a very risky tactic, and you must be able to fall on the axe yourself as you deliberately create a disruption that may very well not yield a positive result. So use caution, as when you play with fire, literally and metaphorically, the chances of getting burned are bound to go up. But the risk might well be worth it, especially if fanning the flames now will help to avoid a full-on blaze later on.

P.S. A controlled burn, like moving a person around, cuts right against the advantage of Stable Counterparts. So don’t go around shuffling your direct reports like your favourite playlist.

P.S.S. After I wrote this article, I also came across an interesting quote by a Canadian ethnographer about this concept being used on a scale of villages and years.

The Shushwap region was and is considered by the Native people to be a rich place: rich in salmon and game, rich in below-ground food resources such as tubers and roots — a plentiful land. In this region, the people would live in permanent village sites and exploit the environs for needed resources. They had elaborate technologies for very efficiently using the resources of the environment, and perceived their lives as being good and rich. Yet, the elders said, at times the world became too predictable and the challenge began to go out of life. Without challenge, life had no meaning. So the elders, in their wisdom, would decide that the entire village should move, those moves occurring every 25 to 30 years. The entire population would move to a different part of the Shushwap land and there, they found challenge. There were new streams to figure out, new game trails to learn, new areas where balsamroot would be plentiful. Now life would regain its meaning and be worth living. Everyone would feel rejuvenated and healthy. Incidentally, it also allowed exploited resources in one area to recover after years of harvesting…

— Richard Kool

This article was originally published on Vitaliy’s Medium.

Vitaliy Kondratiev

Engineering Manager

Vitaliy is an Engineering Manager specializing in Android Development at Connected. He’s worked on small and large teams and has always been looking at joining 0 to 1 projects.

Vitaliy is currently interested in creating and maintaining the ideal developer experience through technological and human perspective.

More Posts