A friend posted this HBR article on the transience of high-performing teams on his Facebook account. This got me thinking, and commenting… thought a blog post might be a better medium to express my thoughts.

Overall, I agree with the article, but I think it, possibly deliberately, does not consider what can be done in more corporate workplaces, where team members tend to stick around for about 2 to 3 years on average.

Keeping this premise in mind — I think the cause of complacency/comfort is doing the same thing over and over again. In many creative fields, this is recognised as an issue. I would say many more “corporate” fields are also “creative”, but not recognised as such, in particular (as it affects me), writing software. This has made real gains in those fields pretty elusive, and limited to a few select teams where the creative aspect is acknowledged, or obtained through accidental discovery then subsequently forgotten.

To me the answer to battling complacency is simple: there needs to be regular, short breaks, where you go do something different but related for a period. For example, explore some new technology, some new framework you think would amount to eliminating some pain point in your core product. Or write some experimental feature integrated into the core product even if there is no known business requirement for it. Or, write something orthogonal to the core product, a support tool. You get the idea: something that makes the employee happy even if there is no immediate business driver for it.

Digression: Speaking of business/customer drivers, it’s a good time to remember Henry Ford’s quote: “If I had asked people what they wanted, they would have said faster horses.” So customers are not the only people who gain insights into what they need. Neither is just management, nor just developers. That’s the point of a team — a collective hive mind.

Back to the core issue, ideally, these breaks need not be accounted for stringently — their purpose is intangible. To require say a short discussion of what one did is very reasonable, but to require that it produce something that adds to the bottomline directly is not reasonable IMV.

One might consider Google’s 20% time, but from what I gather (and I could be wrong here), that time is accountable and you MUST produce something which then feeds into employee performance reviews, etc. For me, that is a fallacy, and misses the point of this “productive downtime” idea I am proposing.

Complacency in my view is a form of mild boredom, and this implies being in a sort of shallow rut. To get out of ruts, people need to do something differently. Employers though are generally not creative enough, or brave enough to allow such measures, due to at least the following reasons:

1. Trust: In some places, employee/employer relationships have a trust issue, say because in the past employers were bitten by employees abusing leniency. The reaction is human… but equally human is to get over it and not let one or two experiences taint one’s outlook for life.

2. Excessive Sense of Accountability to a Board: A form of paralysis which forces management members to only ever make “safe”, mundane choices. Unfortunately, safe and mundane choices lead to safe and mundane results a lot of the time.

   I am not proposing constant risk taking — we need to ship and produce within reasonable timeframes… but there is no doubt that calculated risks and a willingness to be different in a positive way are behind some of the greatest successes.

   I would also argue one of the tasks of management is to be able to shield deserving creative people from the scrutiny of an uninformed board.

3. Excessive Adherence to Best/Established Practice: At one point in time, slavery was established practice. It was a given. That’s how things were done. Was it right? I am all for properly backed studies, but they do not always apply. I also find there’s a bit of selective best-practice adherence, i.e. some places only use best-practices that will please management, but discard others that may in fact be required for the adopted practice to work! It’s like going on a diet without exercise, or exercising but keeping to your 30 Big Macs per night diet.

4. Lack of Understanding of Staff Psychology: If employers are managing say, software projects (me biased? What bias?), it is necessary they understand the drivers and motivators of software developers. What makes software people tick exactly. I think here we have a generational gap problem too… many of us got into software because it was different, it has a joy of its own. But it is scientific, precise, and creative all at once; thus a lot of software developers suffer the same psychological issues as say artists and actors. Yet, we work under fairly corporate conditions. So there is a mismatch.

   This point is then inexorably linked to the point on Trust… how can you trust easily what you do not understand…

   Granted there are software developers that come with a sense of entitlement… just as there are managers that come with the same. That is an individual issue, the punishment cannot be applied to the whole species.

In my view, there are plenty of things employers can do to improve team morale (and thus output). It just takes some willingness, some creativity, some courage, and some trust.