Growing effective teams requires a lot of experimenting. As people join the team and grow they’ll change the team dynamic. New ideas will be suggested and new difficulties will appear. Adapting to proposals and challenges naturally leads to changes and it feels productive, and positive to introduce new ways of working.
When we look back on situations we tend to focus on what was missing. Missing requirements, understanding, or more practical things like missing alerts or monitoring. We add in extra technology, or meetings, or process to try to fix the problems we see.
It can be easy to forget that sometimes we need to be removing things to be more effective.
Measuring Change
When we introduce processes or tools we usually bring them in after considering the options. We agree on a trial period and consider who needs to be involved in the trial. Usually we’ll have something to measure, or assess to give a measurable assessment of the change.
If we don’t see the hoped benefits, or especially if we experience new discomfort from the introduction, we’re happy to abandon our experiment. Abandonment doesn’t necessarily mean we give up entirely, instead if the pain is bad enough, we might seek out a new change or tool to achieve our goals.
Critically assessing our current tools and process in the same way could bring similar benefits to team effectiveness.
Learning By Doing
I once worked on a team that was having difficulty releasing our code. Building and testing each release was painful, the actual release itself took much longer than expected, and we often had unexpected problems once we got the code into production. Each time we hit a problem we discussed what had gone wrong and usually added another safeguard to the process.
Over time we Introduced sign offs from the design team, the product team, and the test team. We become more cautious about who could release and when. Releases became less frequent to reduce the impact on customers. Eventually we ended up with a slow and inflexible process that made releasing anything at all painful and stressful.
It would have been easy to keep tinkering with the existing process and most likely adding more safe-guards and checks to try to improve the quality of releases. Experience tells us that when things are going badly we’re missing something and we keep on adding steps and tools to our process until things work.
Luckily a new team member came in with fresh eyes and forced us to step back and re-evaluate. Instead of trying to improve our current process we went right back to the beginning and evaluated what we wanted to achieve. We defined the values that mattered to us, and we worked out what success would really look like. Afterwards we designed a new, totally different, process that met our values. Surprisingly it removed almost all of the safe-guards that we previously thought were needed to make releasing safer. The result – a process that actually did what we wanted it to do, and ended up being more effective than our original one too.
Take An Intentional Step Back
Taking the time to step back and consider exactly what you hope to achieve with your process is a great way to start cutting it back. A daily practice like standup can become a habit without necessarily achieving the goal of improving team communication. Realising this is the first step towards experimenting with alternative communication styles. Take the time to define your values and then assess your current approach against these values. Are you meeting them? If not, why not?
Focus On The Small As Well As The Large
Not all change needs to be large to have a significant impact. Sometimes a number of small changes can have a far bigger result and will almost certainly face less resistance than a single big-bang change. Skimming off small but unnecessary tasks will save you time and lead to a streamlined, effective culture.
I once produced a weekly, company-wide, email newsletter to summarise all the changes that were going on in the Technology department. I described the experiments we were running, translated the technical release notes into English, and explained why these changes were important for our users. The newsletter took a lot of time and effort to produce. Often the technical description of releases was meaningless, and missing the critical ‘why’ explanation. for each one I had to track down the original author to find the answers I was trying to give to others. Once I had the details I had to write the email, create and attach screenshots, and email it out.
People were reading the email but there was no real feedback. Even more significantly I couldn’t see any change in behaviour as a result of the email. I still had to hunt for the information I wanted, and the recipients still asked questions about things that I had covered. The email didn’t appear to have the impact I had hoped so I decided to run a reverse pilot and simply stopped sending it.
A week later and nothing. No one asked about it. The questions about technologies changes were the same. I took that as a positive result to my own experiment. If the email wasn’t missed then it clearly wasn’t adding enough value to justify the time I was putting in.
Several years later someone asked me why I didn’t send the emails anymore. They remembered the email and had found it useful. Not useful enough to follow-up when I stopped writing it, but useful enough to remember it having existed. Together we found an easier way to produce a shorter email that provided ‘enough’ value without taking so much time to create.
In Summary
Finding the ideal tool or process takes time and will likely require us to add or remove a number of steps to get to the ideal place. The “reverse pilot” provides an easy way to test out whether you can remove things from your process. Approach it in the same way you would an introduction of a new tool or process and be prepared to reinstate the change if results show that you should.
Amy Phillips 