Primary Sociotechnical Design Heuristics
There are thousands of ways we can shape the software systems we build and organise our teams around them. Yet there is no flowchart we can simply follow to find the optimal design. Sociotechnical systems are complex systems formed of complex systems.
We have the unpredictable nature of markets. Consumer expectations are in a constant state of flux as new technological advancements arise and new competitors emerge, yet the goal is to continuously deliver products that satisfy market demand.
The organisations that build those products are themselves immensely unpredictable. Mini societies of people with competing goals, aspirations, and preferences, all running on pure emotion and caffeine.
The products themselves are software systems which grow harder and harder to reason about as they scale and age.
These three systems are highly interdependent and highly complex. It’s so easy to get design choices wrong and make things worse instead of making them better.
In order to effectively design sociotechnical systems, I recommend using design heuristics. Heuristics help you to build rich mental models and make decisions that offer the best solutions in your context.
One day the robots will do all of this for us but we’re not quite there yet, although I have been contacted by a few companies working on very exciting products in this space.
The problem is that there are hundreds and thousands of heuristics, and nobody has time to scan through a thousand heuristics every time they need to make a design choice.
Heuristics are hierarchical though. I believe if you want to make the best possible sociotechnical design choices, there are just 5 primary heuristics you need to consider when making key design decisions.
Remember that heuristics are more like clues. They are not universal truths and it is dangerous to use them without considering context and challenging them with other heuristics.
In upcoming blog posts I will be providing anonymised case studies demonstrating the the context-specific use of these heuristics.
💰Primary Heuristic 1: Align with Business Value
Different parts of a system will have different levels of ROI at different points in time. The more time and effort we invest in core or differentiator capabilities, for instance, the greater the payback will be.
When architecting sociotechnical systems, our initial focus should be to align with business value for optimal system-level ROI. However, this is usually impossible to calculate perfectly.
Some parts of a system only provide value when combined with others. Some parts of a system may be key revenue streams now but have little potential for growth, whereas others may even be making a loss now but have tremendous future potential.
Sub-heuristics in this category include:
- Align with existing revenue streams
- Align with investment strategy
- Align with high-leverage shared capabilities
- Align with future potential
- Align with evolutionary stage
- Delineate engagement and revenue
The Highest Value Trap
Taken to the extreme, aligning by value leads us back the traditional project mindset, where we form new teams each quarter or year to tackle the most important problems, resulting in a lack of incentives to create sustainable software.
Lack of accountability leads to unmaintainable software that grows harder and harder to change. As our legacy systems become less maintainable the negative spiral begins: the code is hard to evolve, nobody enjoys working on it, features take ages to deliver, politics ramp up….
Additionally, when we architect our organisations in a purely top-down manner, we are susceptible to high levels of interdependence in software resulting in dependencies between teams which negate our ability to move fast on our core business capabilities.
So how do we maximise ROI and create sustainable systems and minimise dependencies?
🔀 Primary Heuristic 2: Align with Business Domain
Unless we’re a startup that is constantly pivoting, macro parts of our business processes will remain stable over long periods of time.
If we align our software architecture and teams with these enduring business capabilities, theoretically we’ll have stable, long-term boundaries within which to create sustainable software and minimal dependencies between the teams that run them.
However, modelling domains is not easy. As your experience of modelling domains grows, you learn that there is so much variety across different domains and every domain itself can be modelled in hundreds of possible ways and your design should constantly evolve as your knowledge of the domain improves.
You’ll come across countless heuristics which are useful in some domains and less so in others. Here are just a handful of the many:
- Align with rate of change (volatility)
- Align with source of change
- Align with transactional boundaries
- Align with domain experts
- Align with historical domain boundaries
- Minimise cardinality
- Marry-me heuristic (if two things need to know about each other’s internals they should be one thing)
I’m starting to convert all of my private notes into a catalogue of heuristics and patterns over on my website.
With a combination of value and domain-related heuristics, you can start to think about trading-off short and long-term business goals. But these two categories of heuristics alone do not cover all of the important aspects of designing sociotechnical systems.
❤️ ️Primary Heuristic 3: Optimise for Social Needs
If you’re architecting a software system or designing the structure of teams and you’re not thinking about the impact on the individuals within those teams you are more likely to have unhappy people and political conflict.
Sociotechnical design means thinking about how each design decision affects the autonomy, mastery, and purpose of the people working in the system. I believe someone has named this ‘The Dan Pink Heuristic’.
Choice of boundaries can affect how overloaded people are, how much context switching occurs as a result, how likely teams are to become silos, and how motivated people are based on the objectives of their team.
Here are a few social-focused heuristics you should be mindful of:
- Minimise social complexity
- Organise around skillsets
- Minimise layers between teams and end users / customers
- Optimise for intrinsic motivation
- Organise for unscripted collaboration
- Align with social cohesion (teams that are naturally closer together own parts of the system that have a higher coupling)
- A single team should be fully accountable for each deployable ‘service’
🖥 Primary Heuristic 4: Respect Technical Constraints
Technology imposes constraints. If we ignore those constraints when organising our teams we can introduce high levels of social interdependence (due to to technical couplings), hard to evolve software, or unreliable systems.
For example, if parts of our system are tightly coupled and we decide to form multiple teams all working in a shared codebase, and those teams all have their own backlogs and aggressive deadlines… the technical constraints are unlikely to facilitate the high levels of team autonomy required and these teams will be causing a lot of pain for each other.
Sometimes, we may have very well maintained software but the architecture doesn’t align with how we’d like to set up our teams. If we ignore the existing architecture and insist on imposing our desired team structure, the high levels of co-change across architectural and team boundaries has an elevated probability of ruining productivity and morale.
A few of the technically-focused heuristics are:
- Align with existing architecture
- Isolate legacy
- Design for replaceability
- Isolate by security concerns
- Isolate by risk / reliability
- Isolate by performance/scalability needs
😍 Primary Heuristic 5: Optimise for User Experience
For almost all of the clients I’ve worked with, user experience has been a key aspect of how they differentiate themselves, and the design of their organisations has had a big impact on the quality of their user experience.
Aligning teams with user journeys gives us the best chance of a consistent user experience but in doing so we move closer to an activity-oriented architecture with higher levels of interdependence and hand-offs between layers (e.g. frontend, backend, DBAs).
The lack of an ability to rapidly implement simple changes, like adding a text box to a web page, that require front and back end changes, can be equally as damaging to the user experience as inconsistent styling.
Some heuristics within this category are:
- Organise for UX consistency
- Align with products
- Organise for end-to-end responsiveness
- Align with user journeys
- Align with market verticals
The structure of our systems isn’t our only lever for balancing autonomy and UX. We can use design systems, for instance.
Putting Heuristics into Practice
We still don’t have a flowchart yet for designing sociotechnical systems but we’re bringing more structure to the process. We have identified the common challenges , we’ve started to understand the common design patterns, and we are learning about the ways systems evolve based on economical, technical, and social factors.
Heuristics are a key element in the design toolbox. Design heuristics help us to look at a problem from many different angles so that we can broadly explore the problem space and have a far greater chance of making better decisions in the solution space.
When designing sociotechnical systems, there are 5 top-level heuristics you should consider for every major decision: business value, business domain, social needs, technical constraints, and user experience. If you cover those 5 angles, and you rigorously use them to compare and challenge multiple design options, you’ve given yourself a tremendous chance of creating a design that will work for you.
Don’t forget that design is a continuous activity. Even if you could find the perfect design, it wouldn’t stay that way for long.
In future posts I’ll be documenting a few anonymised case studies showing how different organisations favoured different combinations of heuristics to align with their unique business and product strategies.
If you’d like help sharing your case study or would like to arrange a hands-on session to model your sociotechnical architecture, please contact me.
Upcoming Public Workshops
If you’d like to attend a strategic design workshop where we cover the modelling, design, and evolution of sociotechnical systems, we are running one-day workshops at the following events:
Explore DDD (this September in Denver)
KanDDDinsky (this October in Berlin)
