Rethinking Team Performance: Why Over-Optimized Teams Fail to Deliver Real Performance
How an underdog development team bypassed the efficiency trap to focus on what actually matters: effectiveness.
Many years ago I worked at a company where we built custom applications. We had 4 teams and each team worked for multiple clients. Our management, who also did sales, would sell ideas to clients, new or existing, and then they would pass the idea to one of the teams to work out and build in collaboration with the client.
The team I was part of specialised in backend tools. So for example, in one of our first projects we built an application that collected records from a third party and passed them on to our client’s system. Everything happened in the background, so there was no fancy dashboard or website people could work with. Just pure logic and automation. Which made for an interesting challenge to show results to the client. But that is a story for another day.
To our surprise, after a couple of successful projects, management asked us to build a mobile app. Not only did we have little expertise with front-end work, but nobody in our company had ever built a mobile app before.
What was especially surprising to us was the fact that we were to some extent the underdog team. Compared to the other teams, where they had all sorts of IT professionals, we were a bunch of self-taught amateurs, coming into programming from other pursuits. In the team we had a PhD in the Dutch language, a theologian, an entrepreneur making some side money while his start-up took off, and myself with my degree in Ecology. And one actual IT graduate, who happened to be our junior team member.
And this reflected on our work. The other teams could oversee and understand a project from the start, and were able to grab off-the-shelf solutions and give clients the kind of certainty that they loved: X scope delivered by Y date, pretty much gift-wrapped and with no surprises. With us, we mostly took our clients on a roller coaster ride with lots of questions, deep discussions of their ideas and sudden changes in direction nobody saw coming.
Whatever the case, we were happy to take up the challenge and got to work. We explored various approaches to mobile design and finally settled on React. Mainly because one of our team members had worked on a mobile project before and that was what he had used. He basically became our tech lead, spending all his time structuring the architecture, teaching us how the code worked, reviewing what we built, integrating it, and giving us feedback, lots and lots of feedback. It was strenuous, but we made progress. And we learned like crazy.
To give you an idea how fast we learned, management hired a mobile professional to consult with us, and on his first visit, at the end of the week we started the project, we hounded him for a whole day and he checked all our code and our architecture and gave us lots of advice. On his second visit, 2 weeks later, he looked at our work and answered a few questions. He stayed for a couple of hours and left.
There were no more visits from the consultant, because two weeks later we released our app to production. We delivered a fully functional mobile app, on both Apple (notorious for its demanding approval process) and Android, with which surgery patients could take pictures of their wound, fill in a questionnaire and send it to a team of doctors. There was a chat functionality in which doctors could discuss the care of the wound and even medication with their patients. With our app, we managed to reduce waiting times significantly and, more importantly, medical complications by 50%, resulting in significant cost savings and improvements in the well-being of patients.
In case you missed that, let me just repeat it:
“we built a fully usable app with a team of 5 people, in a coding stack we were completely unfamiliar with, in 6 weeks.”
Just to make my point, 2 to 4 months is considered reasonable for a simple app, and 6 - 9 months is reasonable for highly regulated sectors like health tech, comparable to what we built. But that is for a team of mobile experts, people who’ve done that kind of work before and are fully trained in mobile app development. And this is if everything goes right.
The Problem with Efficiency
At the time we had no idea what was a reasonable time to develop an app, so we didn’t give it any thought, but as I think about it now I realise that the difference between our team and other teams tells us something.
The other teams in our company focused on efficiency and used their experience and expertise to narrow the challenge, focusing on standardising the work and organising it in such a way so as to deliver fast and reliably. Optimisation based on the assumption that the plans are sound and can be fully relied on. That is what developers are trained to do, build things right.
In contrast, in our team we used our lack of expertise to widen the challenge, spending lots of time thinking and discussing, experimenting and learning, and sharing this with our clients to come up with original ways to achieve our goals. We wanted to be sure to build the right thing. It made us less efficient but the creative thinking and flexibility compensated for this. We were able to innovate and switch focus and acquire new skills, confident of finding our way. We were more effective.
The irony is that our way of work was the result, at least in part, of the fact that we were a team of relative amateurs, without any formal training. We were used to finding our own way in doing the work, learning new stuff continuously. So we organised for it. I’ve been in IT for almost 30 years now, and I’ve seldom seen mob-programming. But with that group of people it was just so much easier to support each other than trying to do things alone.
This insecurity, the need for a second pair of eyes, also resulted in the need to work together, to create synergy, including with our clients. In essence, we were able to achieve that state that companies so deeply long for: a relationship with our clients of trust and collaboration. This is the funny thing about effectiveness, and certainly performance in general, that it is so much more complex than simple efficiency.
"Experts are susceptible to a cognitive bias known as the 'entrained thinking' or the curse of knowledge... They are trained to look for patterns they recognize from past experience, which makes them uniquely ill-equipped to see truly novel patterns or radical innovations."
— Dave Snowden
Organisations have an overwhelming tendency to focus on efficiency, primarily because it keeps things simple and avoids the complexity of having to understand and deal with the whole scope of what performance really entails. Efficiency is far easier to measure and assess, and results are visible and anticipated. It fits very well with our way of thinking, focused on linear causality and logical rationality.
While there is a place for efficiency, an exclusive focus on it without regard for the whole, tends to lead to short-term strategies focused on cost-cutting and standardisation, the so-called factory-mentality, in which we view the organisation as a machine and managers as mechanics of the machine. This approach can create an appearance of high-performance, but one that systematically destroys long-term performance. No better example than what happened to Kodak, a company that was so focused on the hyper-optimisation of its film manufacturing, that even though it was one of their own employees who built the first digital camera, the company completely missed the advent of the digital camera market.
In our modern world where innovation and disruption have become increasingly common, it is a recipe for disaster. In fact, the origin of Agile lies precisely in this need to look further than efficiency. The epiphany at Toyota was realising that effectiveness, in the form of Jidoka, Just-in-Time and Kaizen, is more important than efficiency. So much so, that by focusing on effectiveness as a whole, they were not only able to offer better quality compared to competitors, but they actually became more efficient too. How ironic.
Performance
Once you start looking beyond efficiency and discover the full scope of performance, it turns out that it is a complex web of interacting elements. In the diagram below I provide an overview.
I have chosen to organise performance into 4 phases, each containing a number of related elements. The arrows indicate the weight of the relationship, so for example there is an arrow running from Effectiveness to Efficiency, indicating that although both elements influence each other, the influence of effectiveness is much larger than the other way round, as we saw in the Toyota example.
Phase 1 - Inputs & Causal factors
Phase 1 has everything to do with collecting and managing everything that we need to produce our product, raw resources, software, and also the people doing the work. This is where IT managers operate, managing the software tools and the infrastructure we use, and where HR takes care of hiring new colleagues and their continuing development. The culture of the company, its vision and goals and the way it is organised is also part of this phase.
Phase 2 - Strategy
Phase 2 involves our understanding of the product and the goals we are trying to achieve, as well as preparing and planning development. It is all about the why and the what. This is where Product Owners and Product Managers live, but also other roles like UX And UI and design. Marketing is also involved here, fully focused in how the product will end in the market. This is where my team excelled, the roller coaster of questions with our client to figure out what our clients actually needed.
Phase 3 - Transformation Process
Phase 3 is the actual building of the product, and is all about the how. This is where the developers, the actual people delivering the product are involved, in their natural problem-solving perspective. The why and the what, which is the most important input from the previous phase, are crucial to give direction and provide constraints. This is where our team might have been weak at the individual level, but where we compensated by focusing on our teamwork and collaboration.
Phase 4 - Impact
The final phase is the actual impact the product has and feels a bit passive, as it is harder to actively work on. However, it is in this phase that we see the fruition of all the previous phases. It is the phase in which we see the results of all our hard work.
Conclusion
Performance is something we talk about a lot, especially in the context of high-performance teams. However, I feel that often there is very little awareness of what performance really entails. This is visible in the focus on efficiency that we discussed previously, but also in the way that efforts to improve performance are usually focused exclusively on the teams. Nowhere is this more visible than in the practical interpretation of the role of the Scrum Master, who according to the Scrum Guide must ‘Lead, train, and coach the organization in its Scrum adoption‘, but who is often not welcome when they stray too far away from the team.
The reality is that a lot of the factors influencing performance exist outside the actual teams, and that often the bottlenecks limiting performance are found there. It explains how small changes in for example leadership or the role of business can have a huge impact on the performance of the teams.
With this in mind, and supported by my overview of performance, I encourage you to first find your place in this complex spiderweb, the phase (or phases) where you are currently active. From this center, find phases that you can influence or that affect you. The goal is to discover where the bottlenecks to performance exist, and how you might be able to influence them. It is a way of broadening your perspective to become more aware of factors which may have been hidden to you before.
For example, for me as a Scrum Master my focus lies mainly on the transformation phase (phase 3), working with the team to find improvements there. However, I am very aware of the impact the strategy phase (phase 2) has on the effectiveness of my teams - as Maarten Dalmijn puts it, drive value (a measure of performance) with goals. In fact, this is often my starting point when I start off with a new team.
This broadening of perspective has made me a very effective Scrum Master, able to focus better on the things that really matter - bottlenecks. I hope this perspective helps you too in your work!
As a project manager who works with developers or on SaaS project delivery where there is suddenly no BA on the team, I read this with a smile! People who have to mobilise to think logically, get out of their daily jobs and think critically- what is it what we need, what needs to be built, how does this platform/app work, what features are covered and which ones we wanted aren't covered and how can we ask the developers to schedule the features in? Or maybe they weren't that important now that we know exactly what they would cost 🙃 I really relate to your post ! 😄 those teams come out the strongest and sometimes you make actual friends!
The real insight here is that over-optimisation creates a local maximum. When teams treat the brief as fixed and focus purely on execution velocity, they lose the ability to question whether they're solving the right problem.