Software design principles for teams: The Principle of Aligned Autonomy.
Consider design norms outside your team at your leisure. Ignore them at your peril.
Background
This is an elaboration of one of the principles I originally published in the following article…
Principle
Consider design norms outside your team at your leisure. Ignore them at your peril.
Disclaimer: The phrase “aligned autonomy” is generally used with a broader definition that encompasses larger concepts than just software design. In this instance, I’m using the term only in terms of software design decisions made within a team compared to those made by other teams.
Engineer: This is the first story where we’ve needed to handle sensitive data in our logs… do we have an approach for doing that?
Tech Lead: I don’t think so. I do know the Identity team has crossed this bridge… although I don’t know how they solved the problem.
Engineer: Do we have to involve them? They’re never available, and - between you and me - I’ve seen some of the stuff they’ve written and haven’t been impressed.
Firstly, here is the straw person argument for not looking outside your own team when making design decisions:
“It’s hard enough making a decision just within our team - looking beyond our boundaries is going to make that job even harder. Also, those teams are not our team and their people, experiences and context may well be different. And while I’m at it, hasn’t the industry emphasized pushing decision making down into teams for the last decade or so?”
Let’s tackle the key parts of that argument:
1. Considering other teams adds to the complexity of the decision
This is a valid point. Certainly there is the well established idea of how increasing the number of people in a conversation increases the complexity and effort of the discussion. Opening the scope of a design decision to involve people from other teams could increase the time needed to make the decision.
However, if the other team has recently made this decision, they can serve as valuable subject matter experts on this decision. Hopefully, they’ve documented the options they identified for the solution and you can leverage their thinking to accelerate your own decision making process.
2. Insufficient contextual similarity between teams
It is true that no two teams are exactly the same, but - especially with the uptick in distributed systems development - there is a good chance that you will find other teams with enough common context to warrant more collaboration. Examples of this common context would be:
Common stakeholders, for example architecture, security, compliance, etc.
Common customers, where multiple teams are collaborating to build common features
Common codebase(s), where teams are sharing ownership over services, libraries, etc.
Common tech stacks, where teams don’t share ownership, but do work using a common set of languages, frameworks and libraries.
Within larger engineering organisations, most teams probably share two or more of these characteristics, meaning there is typically far more common context than initially assumed. Encouragingly, the more you make decisions informed by other teams, the more context teams will share for future decisions.
3. Focus on decentralized decision making
The recent push towards decentralised decision making hinged on the premise that decisions should be made as close as possible to where the impact of the decisions is most keenly felt. In this context, the team is where most choices around design decisions are felt. This principle is absolutely not about abdicating responsibility for making a decision within a team. It is not about asking a higher power to make the decision on behalf of the team. Is is about making the decision within the team, but looking left and right to other teams to see whether their experiences might assist to make a much higher quality decision, albeit with a little more effort.
But what if we don’t bother consulting other teams?
Unfortunately, I have all too much experience with teams over-indexing on making decisions in a complete bubble. The impacts can be felt/seen in numerous areas:
Longer decision timelines as the team misses the opportunity to build off knowledge in nearby teams.
Rework after the decision has been made when it becomes apparent that different teams have made decisions are local optima but don’t work in a broader context. After all, the handling of sensitive data in logs (especially in a microservices world) is a cross cutting concern that will almost certainly need to be configured centrally.
Higher switching costs for people moving between teams as they have a steeper learning curve caused by a corresponding lack of uniformity across tech stacks and approaches.
Higher consolidation costs should disparate services need to be combined.
Conclusion
This principle is one of the more culturally-specific and advanced ones I’ve mentioned. For teams that are struggling to make decisions in a local context, expanding that context is a double edged sword. Adopting a neighbouring team’s approach to X for lower priority decisions can reduce stress and increase decision making speed, at the cost of lower engagement and learning. Ignoring similar/same decisions outside of your team is likely to become an exercise in Hyperbolic Discounting.
Like many other “muscles” in software design, considering other teams gets easier and quicker the more it is exercised.