Your lack of system thinking is tanking your efficiency plans
A story of how I started to perceive a different way of working
A few years ago I was working in a team that was under a lot of pressure to constantly deliver an increasing amount of features. Many of us were working together for years and most of us were familiar with the domain we were working in.
Despite this, the team was feeling stuck. Pull requests (PRs) kept piling up and not being reviewed fast enough (with fast enough being a blurred indication defined by management). New features and projects were on the horizon while the ones in progress struggled to get momentum. Many people worked in several projects and features even though in different capacity depending on what was considered priority for each one of us. People had performance goals set which were mapped on certain projects being delivered. And obviously people like to keep their jobs so once there is a certain goal set they will work toward it if their paycheck depends on it.
Each one of us working hard but getting traction (feedback and approval) on your PRs was a challenge. When code was reviewed often it led to long threads of discussions. Reaching an agreement or at least a mutual understanding was often a challenge.
Management was obviously annoyed and blamed developers for not doing their job.
Managers dragged all developers into a meeting in order to define a solution to guarantee PRs were reviewed regularly and in a timely manner so that progress on project could be made. The discussion was heated, as you can imagine, since blame was moved around people and there was a general sense of resignation for a situation out of their control.
During that meeting, being a group of software engineers, we focused on engineering a process that would guarantee the PRs to be reviewed. The result was a process in which people would have to review PRs at least once a day and if one PR did not receive any feedback in 24 hours, then the developer had the right to ping people to get a review.
Frankly, I remember leaving the meeting with a bittersweet taste from this solution. It felt we were just imposing more rules and work on top of a situation that was already tough on everybody. This, in my mind, was not a solution that was worth the amount of time and energy we spent on. It felt a patch on a sinking ship.
But I couldn’t see how to do anything better. None of us could even though we probably all knew that we were just pushing the problem more down the line.
But there were projects to deliver so the sense of action took over.
After an initial improvement, the situation did not evolve in a more sustainable way of working. Good intentions of reviewing code in time left the room once we turned on the pressure to deliver.
Never mistake the finger for the moon
After some time from that meeting, I was leading one of the two sub-teams and I was armed with all the best intentions to solve the miserable condition we were working in.
Struggles like the one I described before were just one of the many problems that were affecting the team. The misery induced by this situation pushed me deep into study-mode because I could not believe there wasn’t a better way.
This is where I started exploring the Theory of Constraints (TOC) and System Thinking principles. At first all that seemed so abstract but eventually it clicked.
Instead of providing me with answers, I ended up having even more questions. But this time they were good questions. The types that help you go deep into understanding reality and its subtleties.
Being a good inquirer is often seen as an expected quality for engineers but when it comes to these socio-technical aspects, asking questions can touch open nerves or challenge the way of working management has designed for the team (intentionally or not). This can lead you to become an annoyance for management. Learning to do it well is something that takes time to perfect. In the meantime, the risk on stepping on someone else’s toes is high, just be aware.
But I was loyal to the truth, not to management. Even better, I was loyal to my team which deserved better than that situation.
I realised we were looking at the finger when pointing to the moon. What we were trying to solve was high Work In Progress (WIP) and low collaboration.
Seeing the structures holding you down
It didn’t take much time to understand where to focus once I asked the right questions.
Almost each developer was working on a different projects or features. We had more projects and features than developers and upper management was under pressure. It was obvious that they had to parallelise the work. In all fairness, our management had to work inside a system where projects had to be started to calm the anxiety of higher management which tried to juggle several initiatives at the same time.
If you have any familiarity with Systems Thinking you are already aware that often the obvious solution is also the wrong one on a long term. On the other hand, counterintuitive solutions can be surprisingly effective.
In our case PRs were not reviewed because people had no incentives in looking at them because they often involved functionalities they were not familiar with or projects they did not have enough context of. Even when trying, it was hard to give feedback or approve something you don’t fully comprehend. One could also argue that doing code reviews is not efficient but unfortunately that was a company mandate that was hard to bypass.
When I looked at this it was crystal clear that without a drop in WIP no process could compensate for the limited cognitive capacity that people can have when multi-tasking.
Our desire to be productive was holding us down.
The solution was simple but required a leap of faith that in many corporation is hard to push: do less things at the same time. In other words, reduce WIP.
I started small by just focusing on the team I was leading and convinced management to make us work together on one project at a time and switching only after having achieved the desired next milestone.
The result? Looking at reviews became part of our routine because we needed to unblock each others and the code changes were more understandable because we all shared context of what we were building. Collaboration was high because it became a necessity for the job, not an impediment on the path to improve your own performance. Standups also became faster and more people were more involved.
One side effect of reducing WIP is that it forces you to prioritise. For real. Pick just one thing, the most important one, and work on it. That’s it.
We also delivered earlier than expected and we all felt more energised because we knew it was a team effort. It was a magical moment.
Even my manager was amazed by how such a small change had a tremendous effect. From that day, normal management practices seemed so naive and ineffective; a new perspective on a different way of working was born in me.
A different perspective on efficiency
Since then I have seen several other situations where similar problems were stemming from high WIP and my approach to it has been refined over the years but that meeting, with the over-engineered social process and the faces of resignation from developers, is still with me. I keep it in a drawer of my mind and look at it every time I find myself in a situation where all the energy is spent to design a process in order to control team’s behavior. It reminds me to look deeper, at the structures that hold this behavior in place.
Efficiency focus, as it is considered in most corporations, is now something that triggers me at many level as well. Often it involves changes to processes built on top of wrong assumptions and wrong metrics. Some of the common traits involve parallelising work and measuring and improving performances of individuals. Parallelisation as we saw does not bring necessarily an efficient system unless you are measuring vanity metrics (e.g. number of projects in progress).
On the obsession for measuring and improving individual performances I will have to dedicate another post because it is a concept that demonstrates lack of understanding of how complex system works. The focus for optimisation is actually about local optimisations which do not translate to a global optimisation on the system.
But again, this is material for another time.