Balancing flow and responsiveness in data teams

09 Sep 2016

Premise: data teams need both individual-level flow and team-level responsiveness to be effective
Argument: these two good things exist in tension because flow reduces (by definition) responsiveness; it is the job of data team leaders to make this trade-off more palatable to both individuals and the organisation; unfortunately we are much better at improving individual-level factors than team-level behaviour (classic prisoner’s dilemma)
Recommendation: leaders of data teams need to ensure every individual can achieve a useful amount of flow, while avoiding the trap where responsiveness becomes only some people’s job; create structures that make responsiveness to the organisation a team activity

One of the most important factors in the success of any technical team, data included, is that individual members reach a state of ‘flow’. What this is, its importance, and what blocks it, are outlined in this great post by Quincy Larson: Live asynchronously. To summarise, ‘flow’ is the state of mind in which technical people do their greatest work, it’s the only way the ‘real work’ gets done, and almost everything about modern organisations (from open plan offices to Slack notifications) gets in the way.

Larson presents some practical recommendations to relieve these problems as an individual: turn off notifications, dodge meetings, ask for a private/home office. These are tricky but can pay off enormously. As a consultant, their common thread (disconnection from distraction) has been critical to delivering my projects on time.

Imagine, though, if every member of a technical team achieved this. In the short-term they finish what they need to faster. When that runway ends, what is next? As I often say, most of the work is deciding what to work on.

The little functionary in all of us might long for a world in which our perfectly-informed manager feeds us just the right task, right on time. I’ve seen technically talented managers attempt to provide this impossible service for their team, while taking concrete actions to improve individual-level flow. This doesn’t work in the long run because the manager faces the same distractions from the organisation that they valiantly shield from their team, only multiplied.

I believe the cause of this dysfunction is that creating a team where individuals are free from distraction also reduces their responsiveness. Life and work are about trade-offs: with imperfect information and many good things to pursue, there is no optimal solution for all cases. One ‘quick fix’ when confronted with this trade-off is to make responsiveness to the organisation the job of a sub-set of the team. Bad move! While responsiveness will naturally vary by team member and their specific work, it must be everybody’s job to listen to your clients.

There are two good reasons for this. If individuals can avoid this responsibility using the excuse of flow, the organisation will push back, intensifying the very distractions that were pushed away in favour of flow. And, perhaps an even better reason is that the ability to deal with organisational demands and balance responsiveness with flow is not just the leader’s job, but something every individual needs to learn.

So what to do? First, ensure every individual can achieve a useful amount of flow, which will vary by context. This is just basic hygiene; sufficiently technical work cannot be delivered without flow. At the same time, create structures in the team that pool responsibility for responsiveness to the organisation. A technically brilliant solution the organisation didn’t need will make nobody happy! This is especially true for data teams: if you don’t support better decision-making you fail.

Stay posted for my evolving ideas and concrete techniques for achieving this balance in your team.