Facilitating Software Architecture book cover showing a green female and a red male European White-Winged Crossbill.

About the Book

About the Author

Supporting Material

Community


Get the book (& more)

Bookstores

Amazon

O'Reilly Platform

Typical Saboteurs of the Architecture Advice Process, and Decentralized Deciding in General

I hedged my bets as to the motivations of saboteurs in Chapter 15 (in the section “Types of Sabotage”) and if you did too, well done. Despite everything, it is still possible that someone could be unwittingly sabotaging the transition to the advice process. It’s impossible to tell if this is the case, but there is one other factor I have noticed that can help you be as sure as possible that something is true sabotage as opposed to unconscious bias or naivete.

This deciding factor arises because there is a criteria for identifying those more likely to be engaged in sabotage. These criteria define where traditional power comes from, and so those who have these power bases undermined are more likely to fight back.

Anthropologist David Graeber and Archaeologist David Wengrow propose in their book “The Dawn of Everything” that for a power imbalance to persist, two of the following three sources of power need to be present:

In our context, having “control of punishment” refers to those who specify the means and mode of organizing and deciding. This includes those who had the power to bring in the advice process in the first place, but it also includes those who used to hold power over the means of organizing and deciding prior to this change, such as other architects, management, project managers, etc. It is those for example who have the power to hire, fire, and recognise contribution, (in terms of remuneration or position).

Having “control of information” sounds a lot closer to home. Code is information. But to control information, it needs to be unequally accessible and unequally distributed. If this description brings to mind that individual or team who are looking after that component that everyone else is scared to touch then you’re on the right track.

Individual charisma is the source of power that is hardest to pin down. But it’s the joker in the pack. Recall I said for a power base to become established and persist then at least two out of these three need to be in play.

In the traditional ways of practicing architecture the architects had control of most of the “punishment”, but the development teams had control of almost all the “information” (the code). Stalemate. Unless individual charisma is mixed in too. Individual charisma can result, for example, in a star architect, who all the teams love working with. They move effortlessly from team to team, actually managing better than most to pair with teams, and when things go wrong in prod they’re with the teams in question fixing it. Individual charisma can result in a star developer: The classic “10x” dev, who can code all day and all night and recall the contents of obscure changesets and pull requests from years ago.

You can tell if charisma is at play when people are scared to make decisions, any decisions, without the charismatic person’s advice and input, even when they have nothing additional to offer.

And so these are your most likely saboteurs. Those with access to at least two of these three sources of power.

It is also distinctly possible the people who meet this criteria are the ones who are the biggest supporters of the power transition. Remember the story in Chapter 12 (in the section “When others are taking the decision”) the one where I wanted to exercise the power and overrule a team. Pete had access to all three of these power sources. He was the Head of Development with the ear of both the founder and CEO. He also wrote a significant amount of the code in the current systems. He was also highly loved by his teams, he was fun to hang around with, and was masterful at building trust and shared commitment. Despite this, Pete was the one who reminded me how the advice process works.