Cognitive load & team composition (Part II)

 

In Part I of the series we have talked about an obvious but deeply overlooked thing -- a natural physical limitation on any individual cognitive capacity. We mentioned how easily it can be overlooked in the working environment and how much it decides about the success of the project.

On the diagram above I tried to sketch a very much simplified 'developer story' diagram of a Natural Language Processing (NLP) team. Please see it as an illustration to the teamwork, but pretty much any IT segment would have same challenges visible more or less directly. What I attempted to highlight is the parallelism of the teamwork itself, as well as touch-points between the roles.

All of us (hopefully) know what is our most productive/creative state -- when we work within a well-defined familiar process-tunnel and we have good amount of focus time to really get into the problem. And all of us (certainly) know the opposite -- continuous interruptions from work, the passive pressure in the air of meetings, having to make compromises without another soul to consult (as the project area happened to be indirectly designated as "my" area by the outside).

In this article we shall talk about somewhat the obvious -- why manufactures and factories took over artisians, or why getting the team composition right is stratigically essential.

Hierarchy, Structure and Armies

People don't want to die, so in human's history of killing each other, armies and army structure was built around the recognition of that simple fact. If in the corporate environment there might be a space for an illusion of "person X didn't do this and that because they didn't want to" -- in military it is an obvious thing that nobody wanted to make a mistake which through the chain of cause and effect led to their death.

It is somewhat unfortunate, somewhat ironic, that human ability to truly observe and to listen is so weak that without others dying the underlying cause is not identified. 

What is in it for our small analysis? Well, the smallest and the simplest infantry organisation unit (platoon) has a well-defined roles [like this one for the US army]. Those role has a finite and prioritised set of "stories" a person in the role is to fullfil. In the case of casulties, some roles/"stories" are sacrifaced to maintain the platoon fighting capacity. This is quite interesting in our context -- everybody in the platoon is interoperable (meaning has sufficient skills to do any job), but in any given time wears only one hat / knows well what "stories" to focus on and which ones to drop.

Even more interestingly, unlike an American career of choice, the same applies to the Russian conscript army roles are also well defined [see here]. The first one is a voluntary choise, conscript army is by definition involuntary. If you find it is difficult to organise a group of people paid to do their jobs, imagine oranising a group of people hating to guts the fact of being there in the first place. And even for such situation, of having little choice on physical/intellectual of people -- well-defined roles manage to create something of an army.

What we see is that regardless of the initial level of professionalism/motivation of recruits, what makes army an army is a hierarchal structure. That structure defines zones of responsibilities and roles for different levels in the hierarchy in a way which aims to de-facto limit the occurence of cognitive overload: instead of expecting a single person to keep too many details in mind, there are well-defined simple much-practiced interactions orchestrating incredibly complex operations. Those roles become lego-blocks, from which the organisation is constructed. If there are inefficiencies detected or warfire evolved -- roles are reviewed or created.

Now think about your respective IT organisation and the context of your team/department. Almost certainly the surface "title" side of things is in place, but what about the clarity of roles definitions? Do people holding big titles understand the structure side of the organisation respective to their role, or they simply hold the title and "expect results"? Does the number of "stories" associated with roles around you feasibly matches the working memory of an individual without stress? (nowadays companies kitch that they care about the mental health but being ignorant about the cognitive overload being the primary cause of mental ware).

Processes over Blame

A well known Google's post-mortem philosophy states: "For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior". Please note that it is aligned with what we talked about the cognitive load and armies -- an army as the whole with the way it works allowed the incident to happen; instead of finding scapegoats, the army as a whole needs to learn from the experience and adapt to a better understood reality.

I haven't met any organisation stating on paper that they are a "pro-blame" culture -- it simply looks and sounds bad. But in many places I worked at it was about "having a talk", or "line manager chat", or "passing constructive feedback" -- different forms of pinning it back to an individual what they are expected to do. Compare this to a position of a leader actively observing/listening to why the situation had place, "having a listen" instead -- with a mindset focused on knowing that people do what they can in their situation already.

And now imagine that a team as a group takes on such stance together. It is much better than having a "shepherd" Daddy/Mommy manager, as it naturally applies the ownership of what we do. Makes us clear on what we can and cannot do. Makes it simple to communicate in a clear and well-argumented way why it takes as much time to do things we do, what roles team can assume in the cost of dropping what other roles. Blame alternative on the other hand, does not allow organisation to truly learn -- rather it makes it numb and static.

Another way to look into it is why manufacture/industrial revolution happened. Artisians were creating goods already at that time. However organising a group of people to do the same final product but in a simpler well defined steps made the efficiency higher. As the mindest of dividing a big task into smaller sub-tasks among people took hold, it became visible that some of the tasks were simple enough for automation with technology (and delegating a machine creation/maintenance to engineers as further steps of this divide&conquer approach).

We are already there in IT -- using programming languages, frameworks, tools ("machines") developed by other engineers. We also have all of those roles within the team and the organisation. However the point I'm trying to make is that just having roles is not enough. For the factory-like efficiency of the team to kick in, the following needs to hold: (1) each team role is simple enough to understand and to hold in working memory, (2) team roles cover the whole workload without gaps, (3) there are processes in place to identify unknown gaps and translate it into roles, (4) it is to be alive rather than formal.

How many roles are enough?

Often the question raises -- how many roles are enough for the team? Do we need a dedicated QA or Devops? Do we need a Data Analyst? Data Engineer? Frontend developer?

My answer is -- it depends, but if you are asking yourself this question than likely you need one.

Lets start with a typical "software developers write automated tests, we don't need a tester". This statement confuses skill with role responsbility. Having skills to write tests doesn't mean that all of the neccesary tests are written or that the team adaptively develops quality strategies in response to changing working environment. QA specialist is a classical example of a role being in healthy conflict with other roles, somebody who is responsible for the wider velocity-quality slider in the team. In big organisations there might be highly technologically focused same-skill teams. Such teams will benefit less from a QA role compared to a crooss-skill cross-technology team, where the problem of quality becomes multi-dimensional and more difficult to grasp.

Importantly, a dedicated role provides the team with a certain constant angle of view and takes on responsbility for work. It means that the rest of the team can free their cognitive space from that aspect and utilise their cognitive space for their respective tasks.

Lets have a look on devops infrastructure-as-a-code as an example. We can say that since it is a code, software developers can be made responsible to do it. However a closer look would highlight to us that more often than not it is a pretty bad idea because of the specificity of the knowledge involved. While a dedicated role might not be needed for tiny enterprises, once a few heavier-weight cloud services are used -- software developers fail to keep all the needed details in mind, tech debt with potential security breaches starts to linger on the horizon. Simply reflect how much time software developers as a group in the team spends on infrastructure related topics and multiply it by two (as they most probably cut corners where they shouldn't be) -- if it is a job, than it is a job for somebody to take. Suddenly developer performance would increase as well as the result of reduced cognitive load.

Unlike an infantry squad, IT professions are so specialised that they are not completely interoperable. This means that naturally there is a need for a role which can aid communication in the team. Usually it is an assumed responsibility of the Team Lead role of some shape or form, however due to the hierarchy position of that role it might introduce background bias in solving conflicts in the team (post-devops TL would understand devops concerns better that DS). So it is recommended, especially for cross-skill teams, to have a dedicated Psiops role. I found it remarkable how much technical time gets lost in tech-mumble, when the underlying issues were those of basic psychology, well-being, security and communication.

In other words, the more clearly defined roles you have in your organisation, the easier it is to decouple the culture from "heros" who do the impossible and built an "army" which scales. Scaling means that it is easy to identify gaps and to know what roles would fill in the gaps with predictable results.

Afterword

So what is the good team composition?

There is no template to copy paste, as IT projects vary in size, technology and complexity.

But there are common-sense criteria. Criteria focusing on "what stops individuals/teams" rather than "how do I fix individuals/teams". Criteria telling if things are working or not, if people are happy, creative and productive or not. There is no need for questioneers, it is enough just to carefully listen and to constructively apply the learnings.