How to keep the plates spinning in software development
How to keep the plates spinning in software development

Using deliberate action and implied intent to uplift your team

Ray Massey/GettyImages

Imagine you have seven plates spinning on top of sticks in front of you. Each is precious and it’s up to you to keep them from toppling over. The last thing you want is a floor full of broken plates (unless you’re at a Greek wedding, in which case smashed plates might be the goal).

Sometimes this is what software development can feel like. As part of the comms pod (one of the engineering pods within Xero’s platform engineering team), we own a diverse collection of products. Each has a critical role to play in the function of Xero as a whole. In this analogy, each is a spinning plate.

Keeping the plates balanced should be easy, right? Just keep them spinning. But it’s not always that simple. The plates all behave differently; they are handmade and have their own quirks and imperfections. And to ensure they keep spinning, we have to keep switching our attention from one to the other, and taking the right action to ensure disaster doesn’t strike.

The more we have to switch our attention, the greater our cognitive load. Cognitive load is how much stuff we have bouncing around in our short term ‘doing’ memory. Too much of it isn’t good, it leads to stress and mistakes — in this case, a higher chance that we’ll be distracted for a moment and the plates will come crashing down.

Reducing our cognitive load

A year ago, the cognitive load in our team was really high. This resulted in a few mistakes that led to some inevitable breakages. Around this time, the opportunity arose for me to move from my role as Senior Engineer in the pod, to taking on the responsibility of People Lead. I saw an opportunity to reduce our cognitive load, mitigate the risk of operational failures and empower our team to do great things, so I took on the role.

Luckily, a couple of years ago I had completed the M@X 101 (Managing at Xero) course. Our facilitator referenced one of her favourite leadership books, Turn the Ship Around by former Navy captain, David Marquet, who details his experiences operating a nuclear submarine. I made a note of it and when I made the decision to pursue a leadership path, read the book. Its concepts really resonated with me and I could see how they could be applied to improve the way we develop software.

Marquet was trained to give orders in the traditional leadership model, which he refers to as ‘know all, tell all’. It’s where the leader knows the answers, so gives the orders. This resulted in the crew doing things because they were told to, rather than using their own instincts and skills — and everyone suffered as a result. But what Marquet did next changed everything.

He resisted telling the crew what to do, and instead allowed them to tell him how they would solve the problem. He also began injecting what he refers to as ‘deliberate action’ into everything the team did. It meant a crew member would pause and vocalise their intended action (what Marquet calls ‘signalling intent’), to try and remove the automatic mistakes that would occur from acting on muscle memory and unconscious competence.

It’s like when you change gears in a car without having to think about it. You’re aware you’re doing something, but not really thinking the process through.

I observed this ‘automatic’ behaviour when we were deploying software. Our development pipeline was smooth and fast and we were used to releasing code to production with no problems. It became part of the pod’s unconscious competence. But it also meant sometimes team members would take action without communicating what they were doing to the team, or really thinking it through. And that was a common culprit for the errors that were happening.

How we introduced signalling intent

The first step was to introduce the concept to my team. I wanted to ensure I was doing it in the right way, at the right time, so I thought back to what I had learned in another excellent leadership book, Patrick Lencioni’s The Five Dysfunctions of a Team. It describes five common team dysfunctions and uses a pyramid to show the levels — trust being at the foundation of the pyramid.

So I asked myself: are my people at a stage where they are open to changing the way they work? And do they trust me and each other?

Having regular one-on-one sessions in place with each of my people had equipped me with enough knowledge to be confident they would be open to trying something new. We had also built up mutual trust within the team, which I hoped would bring with it an openness and willingness to improve the way we communicate with each other.

I raised my observations to the team for discussion and explained how, in my view, some recent situations could have had better outcomes if we had stopped to think and communicated our intended actions to the team. I posed the question to the team: How could the outcomes have been different if we had shared our intentions with the team, before taking action?

Better communication and collaboration

The team was quick to grasp the concept and receptive to giving it a try. Since then, the pod has been practicing applied intent as a behaviour. Not in such a strict fashion as you may expect on a submarine. But whenever the team does a deployment or makes a change, they’ll let everyone know. In practical terms, this is usually communicated via the pod’s Slack channel.

It may seem like common sense, but it is very easy to get into a pattern of unconscious action unless you are actively taking the time to think about what it is you are about to do.

In addition to helping us slow down and think about what we are doing, it has improved the way we communicate with each other. As team members began sharing their intentions, it gave others a chance to provide feedback to help mitigate any risks. This approach has also encouraged the team to think more about how they’re solving problems, rather than taking an action because they were told to.

If problems do occur, the pod dives in to resolve the issue before allowing it to become a wider problem, something that used to only happen from time to time. This means breakages happen less, which in turn helps reduce the cognitive load of the team, because we’re not dropping what we’re doing to focus on issues as they arise. Essentially, we have less plates to juggle.

Do we manage to always keep all of our plates spinning? Even with the best systems in place, accidents can happen. There are areas that we need to keep improving, and we are human after all, with our own quirks and imperfections like the plates we’re spinning. But now when something does go wrong, we’re all clued into what’s going on. This is especially helpful for people on call, so if they are brought into help with an issue, they already know the context.

It has also helped us enjoy a much more collaborative environment. Our team engagement scores are up and everyone has a greater appreciation of the contributions of individual members towards the efforts of the team as a whole.

Useful tips to get started

For anyone interested in applying this concept within their own team, here are some tips to consider:
['Mike Reid']
['Teamwork', 'Communication', 'Technology', 'Leadership', 'Software Development']