A ten-principle checklist for socio-technical design
by Albert Cherns, quoted by Jackson in Critical Systems Thinking
paraphrased by me, with commentary for software teams 🧵
Compatibility
the process of design is compatible with its objectives. Want democracy? use participative design.
The means match the ends.
You don't get autonomous teams by specifying Scrum.
Minimal Critical Specification
of the who and how of carrying out the work, only the essentials are decided up-front.
Figure out the basics, and plan on figuring out more later, within the team. Keep detailed decisions near the work.
The Socio-technical Criterion (why is it called that?)
fix errors at the point where they arise, or as near as possible.
This is unit tests, trunk-based development, and continuous deployment #devops
The Multifunction Principle
for flexibility and equifinality, each individual can perform more than one function.
"equifinality" means "depending on what comes up, this may play out in a lot of different ways, but the result is the same."
People can cover for each other.
Boundary Location
Control of team activities is with the members; the manager concentrates on boundary activities
The manager makes sure the team gets what it needs, and knows what the org needs.
Information Flow
information systems get the info to the work teams who need it.
Get the software to alert us when it needs help, and answer our questions for "what is wrong?" and "did it work?" #observability
Support Congruence
social support should reinforce the org structure. If you work in teams, give bonuses to teams--not individuals.
Promotions and reviews reward teamwork, not heroism.
Design and human values
Emery's six principles. roughly: the work is hard enough, lets us learn and make decisions, gets us respect at work and outside, and has a good future.
Software has the variety and learning, the prestige, and many paths "upward" besides promotion.
Power and Authority
the resources you need to do the work--you have authority to take them and responsibility to use them well.
Hooray cloud! Hooray allocating my own compute! Give us access to all the observability and let us deploy, please. #cloud
Incompletion (my favorite)
design is an iterative process
We are never "done," not at writing the software or designing how we work. The world is changing, we are changing, the learning continues. #symmathesy
• • •
Missing some Tweet in this thread? You can try to
force a refresh
How do you take a legacy system toward fast flow of change? @suksr takes us through an evolution
using wholistic approaches including DDD, Wardley Mapping, and Team Topologies #QConLondon
The Wardley Map is only part of Wardley Mapping. There’s a whole strategy cycle
It’s not about how fast the team can program.
It’s about how fast the team can find solutions to each problem, uncover organizational secrets for how the domain works and should work.
There’s a conflict between cross-functional teams and the organizational hierarchy.
Enforcing the same JIRA workflow doesn’t make developers interchangable.
“It takes me weeks to develop rapport with teammates, months to learn domain and code, a few hours to learn a JIRA workflow.” @ntcoding#QConLondon
Smooth devex, sustainable flow:
“This is working in the government, six years ago.
No one else has an excuse anymore.” @ntcoding#QConLondon
They found best practices like: wrap each unit of work; report errors in a standard field; use span names that are specific enough to tell you what’s happening but general enough for useful grouping.