Forming functional character-diverse teams

LinkedIn asks frequently if we have “Thoughts?”, well voilà. There will be no answers in here, just some tinkering with highly personal observations about the functioning of teams and the interplay amongst the individuals in it.

The basic conditions of a functional team

A team, say a couple, has not two but three entities: person 1, person 2, and the duo in itself. To have a functional team, you need therefore to:

• • Maximize individual pleasure (freedom and flexibility in how to perform your work);
  • Maximize collective pleasure (creating a sense of “team” and minimizing conflicts);
  • Maximize individual and collective output.

This is a far from easy optimization exercise. Collective pleasure and output are a function of individual pleasure and output, with positive (or negative) feedback looping. Pleasure and output equally go hand in hand. Doing something fun induces a greater output, but a fine output also results in satisfaction. 

Agile working is everywhere…

Agile working seems to have become the most common aspect shaping project management these days. It promises to improve productivity, innovation, and ultimately bottom-line results.

Many teams and companies are applying agile principles in their functioning. Be it organizing work into two-week sprints, updating Jira tasks, having a Kanban board, or holding regular ceremonies, teams repeatedly pat on each other’s back that they are “agile”. If this trend continues, all organizations wide and large will eventually be employing agile working in some fashion.

Having worked (and still working) in agile environments myself, I definitely witnessed the value agile working can bring. Yet, I doubt it is for everyone, and I doubt it always brings the best out of teams and especially individuals. Care is needed.

… but it does not work for everyone

Your favored workstyle depends on your personality. Agile working (at the execution level), with its many ceremonies which are often no more than bureaucracy in disguise, is just one particular approach of doing things. It is a bit bizarre that many people have to abide by it while it is not the way for them to thrive.

Some people like to plan every second of their calendar. Others do not. In general, for imagination and creativity to bloom, at least some degree of slack is necessary. To cope with unforeseen circumstances, a planning buffer is needed. An agile rhythm allows to quickly change gears if needed, true, but it also tends to force work in structures they are not meant to be in. For example, I barely see tasks finished within the original sprint scope, which hardly serves the credibility of agile.

Not everything should be shiny and cool and fun. Project management and achieving something in general sometimes comes at the cost of boring but useful structures and habits. I do hope that the boring is kept bearable, so we don’t get annihilated by administration (yes, this is an exaggeration), or worse, that agile is seen as the goal instead of the means. Almost all managers I know understand the need for a healthy balance, and leave sufficient freedom to deal with work how you see fit. In spite of that, if an agile hierarchy is superimposed, it will bark at you once in a while. Just bark back.

There are two main types of roles in teams

Your favored workstyle also depends on your role. This article makes a spot on distinction between being on the manager’s schedule or on the maker’s schedule. The article was written in 2009, but I only found out about it now. I highly recommend everyone, manager or not, to read it in full.

It is striking how I can boil down much of my understanding about work frustrations to this distinction. I am on the maker’s schedule (usually analyzing data hours on end), and find it annoying when I have to interrupt my work to attend a meeting (or something else) with limited added value. (I used to postpone lunch to be able to stay in the zone, but I learnt this is just stupid.) The main advice given in the article is to cluster meetings at the end of your day. My advice is to first question whether the meeting is absolutely necessary.

Then how to form an optimal team?

I wish I knew, but I don’t. Both individual and team output fundamentally depend on two factors: who you are as a person, and what your role is. I strive to know someday though, and create a team in which individuality is maximally exploited. One that often finds itself in “flow” state as Mihaly Csikszentmihalyi would describe.

The rising acceptance of remote working is amazing, but actual innovation (not another task management tool…) in this sphere would be better. Asynchronous working is an interesting reaction to some of the issues posited. I will keep collecting my thoughts about this and related topics. To be continued.