The subject is autonomy within a software development team, or rather the consequences of interpreting a very broad and vague term such as the single word “autonomy” in very different ways depending on where you come from, how experienced you are or what suits you.

My first reaction once I got the idea of writing this down was to go back through the sources, my own influences over the years and the research that buttressed my own vocal support of autonomy. To hunt down the origin of the use of words like agency and self-determination. The borrowed metaphors from psychology and social sciences selectively interwoven within the discipline of software development. To present the research and quote the papers.

But I can’t really be bothered because the accumulated experience taps me on the shoulder and says “nah, that’s all theory. In practice none of this ever holds 100% true and every team you’ve been on has been a unique blend”.

So, f* it, I’ll just write what I have experienced and hope my years in this job have enriched my sample enough to bear statistical significance without really believing it will.

Observation #1: Humans are lazy

Probably by design, something about the way our brains process signals and the fact that it takes so much energy to actually run that brain of ours.

The observation is that people automatically fall back in their comfort zones. They also underperform if they find themselves outside their comfort zone for prolonged periods of time.

Remaining outside your comfort zone requires effort. The fact that it will eventually expand your comfort zone is irrelevant to the point. We reserve the expenditure of energy for things we care about.

Observation #2: Diversity is brilliant but expensive

Expensive in terms of effort and mental and psychological energy expenditure. Dealing with differences and alternate, often times opposing points of view, is outside most people’s comfort zone.

Conclusion #1

Putting the first two observations together results in something along the lines of “putting a diverse team together requires a significant amount of initial effort and will only work if the team is able to establish a comfort zone inclusive of it’s diversity”.

Consequently it is no surprise to me that most teams tend to homogenize over time: we pick the people that share our comfort zone or with which we have already developed a comfort zone.

There is a very interesting side-observation to this: The prevalent work mode for software developers in the past two decades has been the frequent switch of employer. This on first consideration would appear as a good thing as it repeatedly forces people to operate in a new team environment. It can be argued that this is a good thing as in theory it continually expands the pool of people and personalities you come into contact with. My own opinion is that this is a logical fallacy. Given our inherent laziness and the investment of effort required in maintaining diversity, temporality is an incentive for the opposite. In plain words: if you’re not going to stick around long enough and you are less productive when outside your comfort zone, it makes sense to homogenize and select for less effort required.

Observation #3: Projects depend on individuals

There is never a team where all individuals contribute equally. Depending on the size of a team we are looking for a number between one and a low single digit number of people who are invested in achieving the team’s goal.

In some cases it is very difficult to get people to bother at all, especially in the beginning.

These individuals, the ones who care about the stated goal, are the drivers. The ones, who are here to do the job and get paid, well, they are the professionals.

I will not attempt to talk about people that neither care nor do the job. Meeting this type has been a rare occurrence in my 30 years of professional experience, which is a benefit of working in a field that attracts motivated people.

To have an autonomous team with members who have agency requires the somebodies who care to relinquish a lot of the control aspects that they care about in the first place (things like how work is organized, how the team communicates, the creative and creation process etc.).

Observation #4: Success depends on collective effort

No individual contribution is enough to lead a team to success. Individual contributions can easily lead a team to failure, but success depends on collective effort.

There is too much complexity, too much creative work required and a lot of “magic” - as in “Any sufficiently advanced technology is indistinguishable from magic” - in software development for one person. Ergo, you need several working together.

Combined with observation #3 this presents us with the driver for most modern management theories: how to motivate people so that they go along towards the goal.

It is also in my view the limiting factor for true diverse, autonomous teams.

Conclusion #2: Teams require autonomy, for individuals it depends

Full autonomy for every team individual without goal alignment inadvertently leads to conflict. We can scale this up: in a complex project with multiple teams, full team autonomy within the project is not efficient.

Consensus building, which is essential for collective effort requires individuals to self-regulate and limit their autonomy within the context of a team. Learning how to do this without conflict is hard.

Hierarchical structures with clear leadership mandates simplify things immensely - at least at first glance. The “just follow orders” paradigm is not prevalent in our sector. See observation #4 for a possible reason but also because modern software systems require contribution in imprecisely understood areas that are not easily quantified or measured.

Which is ironic, because the whole sector sells quantifiable attributes and measurability as an inherent trait.

But for the time being, the level of complexity and expertise required safeguards the relative independence of the experts.

A.I.’s promise to partly to eliminate this by industrializing a large chunk of the software development aspects and platform engineering’s recent popularity are reactions to the inefficiencies of unchecked autonomy.

It remains to be seen if the swing will go past the equilibrium but given that we are once again discussing technical solutions to what is essentially a social problem I would bet that in 5 or so years I will be hearing people being overly critical of how bossy ChatGPT has become.