Software Elders

The new role of Architects in agile environments

I recently wrote a post arguing that the role of software architects, if not dead, is definitely transforming drastically. Grygoriy Gonchar, a Software Architect at eBay, responded and mentioned his own post in which he argues elegantly for the transformed role that Software Architects are playing in a modern tech environment.

I want to continue this conversation of the role of Software Architects by introducing the (maybe clumsy) notion of “Software Elders”.

Elders in Indigenous cultures

I should start by stating that I am not an anthropologist so some of my ideas might be a bit fanciful. But I strongly believe that indigenous societies tend to be less command-and-control centred, and less influenced by the idea of “scientific management” or Taylorism. There definitely are unwritten rules and practices that a community follows but often these norms can be challenged.

In these situations Elders, much like Supreme Court Judges, convene to understand if the reality of today’s context validates a reinterpretation of existing norms.

Elders are not managers, they are not directors; rather they are a group of people that help the entire community think differently and adopt to new circumstances. They are interpreting signs and omens and are using these to plot a new path, which may or may not work out. They are fallible, they can disagree, and they can change their mind in light of new information.

Architects as Elders

An aspect of an elder is not to violently shake the status quo and demand top-down change. Rather, they are receptive to bottom up conflict and help resolve these through enabling change.

Architects as Elders will preserve the current wisdom and will look at the development teams to bubble up new ideas. They will consider these ideas and look at the global technology roadmap (signs and omens) to spot trends that they introduce as new wisdom to the community as a whole.

As wisdom keepers they will tell other teams of these trends and ideas, dig deeper to find the points of failures, and gently usher in new standards into the development community.

Complexity breeds uncertainty

When software was simple and development expensive failure was undesirable and avoidable. Failure today is inevitable, and rightly should not be called failure. A soccer team loosing a game is not failure. It is only failure if the team systemically cannot find ways to improve.

For architects to be elders the idea of fallibility needs to be accepted at an organizational level. Risk needs to be mitigated — or rather the software development process needs to be managed in such a way that risks become acceptable.

In complex systems that are constantly adjusting and evolving (like humans), certainty is hard but the cost of change is manageable.

Software Elders can guide teams through such uncertainty to slowly write better code, deliver better results, and recover from adverse situations faster. Software Elders will lead from behind, nourish the weakest to make them stronger, and ensure that the entire pack is working together.

What makes an Elder

The question is how is this different from the work a Senior Engineer or Architect is already doing?

Senior Software Engineers often do not stretch their expertise beyond the work their immediate teams are doing and are more hands on engaged in helping Junior Engineers think through problems. Engineers are more involved in what is happening now, and what needs to be solved now. By that I mean the Senior Engineer is more consumed with the need to write really good Java code now vs the strategic value of adopting Haskell for certain sets of solutions.

Elders need to look out for the community and project what the future holds and if we are prepared in the present to handle the things we should expect in the future.

Architects on the other hand are looked on for first comment when starting a new project — whether Enterprise Architects to inform us of Enterprise patterns, data collection, privacy, security, and licensing concerns or Software Architects to tell us about existing patterns and flows. In an agile environment we are always at brink of tearing everything down to handle this very new thing and architects who lecture, for lack of a better word, are a hinderance rather than enablers.

Software needs to be developed greedily — i.e. build fast, and verify (not necessarily in production) instead of theorizing grandly in the hope that all our ideas hold true in production.

Software Elders are enablers in this that they don’t inject themselves into the flow of work, neither as bottlenecks nor as policemen, but remain deeply engaged consultants. Instead of talking about patterns of the past, Software Elders can help us understand how to verify better. They do this by keeping an open ear, while allowing the product teams to retain their autonomy when creating software.

The term Elder might not rub well. But it captures the idea of leading from behind, providing confidence instead of instruction, and support instead of direction.