Highly Productive Teams and their Speed Bumps

In Civilisation, the fantastic BBC series from the 60's, Kenneth Clark is puzzled by the short burst of time in which cathedrals, spiritual movements and art styles are created. For a couple of decades (which sounds long by our standards), there seem to be surges in productivity, creativity and energy in almost the entire population. More was accomplished in these bursts than in the centuries of relative inactivity before or after.

In my experience, product development is very comparable. When looking back at some of the most important software projects in which I've played a part, there were bursts of just a couple of days where we were incredibly productive. We were energized, worked as one and were in a state of flow most of the time. The best part is this: although the experiences are very intense, they don't leave you very tired. Instead, afterwards you feel energized and you realize that you just did your best work! As a CTO, I would love my team to work like this!

Is it possible to achieve this high productivity reliably? I often fear that our competitors are consistently operating at this breakneck speed, but actually I suspect that there are very, very few teams in the world that get close. So, perhaps it is simply not possible. Maybe my memory is playing tricks on me, maybe I'm just nostalgic, or maybe it's another case of the 80% / 20% law, where 80% of the work gets done in 20% of the time and the finishing touches are actually the hardest and most boring to get right. Nevertheless, I want to learn something from these high productivity moments and create the right environment for my team to experience them.

These are the common denominators of the high-productivity bursts I've experienced, either when working solo or with a team:
  • There is a clear goal: build X or solve problem Y.
  • Everyone should be well-rested (as in, not tired or hungover).
  • The team consists just of people with a can-do attitude, no negativity. One sour face severely impacts the rest of the team.
  • The members don't have to be close personal friends, but they absolutely need to respect each other's skills.
  • Autonomy: everything that is needed to accomplish the project should be in one room and focused on the project. If more is needed, make sure that it's just one phone call away.
  • Everyone in the room can add something, if not, pair up with someone or get the team lunch or coffee, don't go browsing reddit like a zombie.
  • There is an organizer / tie-breaker that people look to for when they're stuck or have questions.
  • Leadership that acknowledges the importance of the project. Together with respect for each other's skills, this provides the necessary Psychological Safety to the team
  • A small team of max 5 people. Coordination and keeping everyone focused becomes too hard when the team is bigger.
There are also "speed bumps" that make a high productivity environment impossible.
  • No clear mission.
  • Negative team members. Although there is lots of value in criticism and being cautious, especially when dealing with high performance or security requirements, voice these concerns in a positive way, or, when the project is just a Proof of Concept, say that we'll tackle it when going to production.
  • People that like talking about the project more than actually getting to work and building it.
  • External dependencies outside of the room that are not immediately available, such as designers, the legal department or a product owner. Make sure you make everyone is available to the team. If you still have external dependencies, it can mean two things: 1) the goal or scope is actually not clear to the team or 2) the project doesn't have the backing of leadership.
  • No clear organizer, team members staring at each other waiting for others to make a move.
The most critical speed bump is "external dependencies". As soon as the creative process requires something that is not instantly available, productivity takes a huge hit. This is why productivity is so hard in larger organizations where the amount of stakeholders is very large.

Popular posts from this blog

AI programming tools should be added to the Joel Test

The unreasonable effectiveness of i3, or: ten years of a boring desktop environment

The long long tail of AI applications