Agile, Teams

Efficiency and Effectiveness in Software Development Teams

Efficiency and effectiveness. These two concepts  are quite often mixed up. Each with their own strengths and weaknesses. Understanding these concepts will increase the impact of a software developers work.

They come to play in the following quote  from former Apple CEO, Gil Amelio who said:

Amelio:  “Apple is like a ship with a hole in the bottom, leaking water, and my job is to get the ship pointed in the right direction.”

Smith/Jobs:  “But what about the hole?”

Before we take apart that quote, let’s dig into some definitions!

Efficiency: Doing the thing right

Effectiveness: Doing the right thing!

Amelio is focusing on doing the thing right: “…get the ship pointed in the right direction“. But he isn’t focused on doing the right thing: “But what about the hole?“. So he’s focusing on efficiency, and not effectiveness.

Software Development

Now that we have a grasp of the concepts, let’s look at how this maps over to he realm of software development teams.

Efficiency

As a single developer, working in a team (or alone). It’s easy to get caught up in a cycle of efficiency. Where the mindset and focus is on getting yourself up to a high level of productivity. Such as streamlining how you write code through patterns, practices and looking for repeatable processes. It could also mean having a strong focus on writing quality code. There may also be a tendency to take this too far and optimise code for terseness and not readability..

Effectiveness

The cycle of effectiveness entails more pragmatism and being aware of your context. An effective developer understands the context of the tasks they are working on. They are then able to make decisions in code based on that context. Such as when and how to make compromises when it comes to code quality / abstractions and implementation details. Sometimes whats needed is to take a step back and solve problems without code. Or even removing features.

Teams

Pair & Mob Programming

Most developers have heard of the concept of pair-programming, and even mob-programming. Both are considered as good practices for many reasons. At the same time these practices are also scorned upon by others as inefficient and a waste of time.

Pair-Programming involves 2 people (dev, tester, business etc) working on the same screen. There are many variants, including strong-pairing, driver /navigator, TDD-driven variants and some others. Eric Elliot has a great breakdown on pair-programming styles.

Mob-Programming is an approach that involves the entire team working on the same screen, and delivering the code in a similar way. The recommended approach is a driver / navigator style where the team serves as navigator and the driver writes what the navigators tell them.  I wrote a little about it here.

These approaches sound wasteful and inefficient, especially mob-programming. Yet people argue that these are great way to deliver more value by being more effective. Why? How?

The premise is more eyes on the code written, more knowledge sharing, and a shared sense of ownership. There’s also a cross-pollination of disciplines, ideas and shared ownership. Understanding others’ limitations and strengths will allow a team to grow even more.

The fundamental drive for these approaches is about being more effective.

Slack and the Utilisation Trap

Henrik Kniberg has produced many articles and videos about the balancing act of delivering value through teams. He’s presented two concepts that illustrate the power of an effective mindset; Slack and the Utilisation Trap.

Slack is the absence of work. Where people have  the opportunity to decide how they want to spend their time for themselves. What may seem counter-intuitive is how much value there is in unplanned time. The idea is that this is where people have the opportunity to “do magic” or innovate. Basically, being effective. Check out Henrik’s video on the topic.

The Utilisation Trap relates to slack. It depicts the notion of achieving a highly efficient team, which always has work to do. The focus is to achieve as close to 100% utilised as possible. By lowering the efficiency rate and introducing slack a team can achieve an optimal state of flow. Here’s Henrik’s video.

Organisations and development processes tend to have a focus on efficiency in their systems. So it’s very natural to get stuck in a mindset of efficiency, when what you want is effectiveness. In the rush to be over-effective, it’s also easy to bypass efficiency, leading to poorer systems.

My reflections

Focusing on efficiency alone can lead to poor solutions that don’t meet the needs of our systems. Focusing on effectiveness alone can lead to inefficient systems that are technically flawed.

As I have grown and evolved as a person and a developer I’ve felt that my maturity / seniority level matches my focus on effectiveness. In my younger days, it was all about being as efficient as possible, where now I’m focused on being as effective as possible. As I further progress, understanding where and how to be both efficient and effective is where there is the most value. Growing a proactive mindset has been a way for me to realise my impact in the greater context.

As earlier stated in this article, both are valuable, but there’s a natural tendency to lean towards efficiency. Instead we should spend more time on practices that make us more effective. As developers, teams and organisations.

What are your experiences with personal or team efficiency and effectiveness? Do you struggle to balance? Leave a comment below, and share this article with someone  💚

This post is inspired by my conversations with Tomas

Cover photo: Daniel Mennerich via Visualhunt / CC BY-NC-ND

  • “It’s easy to get caught up in a cycle of efficiency. ”

    Very easy indeed.

    I think this is because of the way we measure our work. Ask a programmer what his perfect day at work will be – a full day of focused coding is what you will usually get as an answer.

    Great post as always, thank you for sharing 🙂

    • Tomas Ekeli

      Even though I can be much more effective by going to meetings I still hunger for the feeling of flow and efficiency of a day of heads-down coding.

      • Exactly!

        At the end of a meeting somebody will say: “Now let’s go and finally do some real work”?

        We love working with others and sometimes doing that “extra mile” so work is done and progress is achieved. But it is not what we are most comfortable with. We just want to code (or whatever we like to do)

        No wonder being effective is hard 🙂

        • Great insights here @kostadingolev:disqus and @tomasekeli:disqus!

          I feel there’s something about feedback loops and instant gratification. Zooming out, and gaining perspective allows you to be more effective. So does patience.

          So the point here is the ability to zoom into the 10 ft view to get work done, and zoom out to the 10000 ft view to gauge where you are.

          So the real trick here is to master both.

  • Pav, Great post, as always. I love it, especially the importance of slack in your schedule (I usually use the word “space” to mean the same thing). Relevant to this too: local vs systemic optimization. Also, you didn’t link the Eric Elliott post you mentioned and I imagine you intended to. Perhaps this: https://medium.com/javascript-scene/stop-wasting-time-pair-programming-rocks-4a99604cb09d#.li2ye0dfe

  • Tomasz Majewski

    “Efficiency: Doing the thing right
    Effectiveness: Doing the right thing!”
    I like those definitions, but wondering how to name “Doing the right thing right”? 😉

    • That’s a great question @disqus_DgOsg2FPkO:disqus! I wish I had an answer for you.
      But doing the right thing, right is the sweet spot we should be aiming for. Now, let’s find a name for it… 😀

  • Great post, Pav! It’s really great to get reminded of these things. It’s SO easy to get stuck in a loop where all you think about is efficiency. At a certain point it’s like running on a treadmill – you can run real fast, but you get nowhere (and get really tired!).

    Thanks for the great content, as usual 😉