A viable system continues to function in a changing environment. We want our companies—and some teams—to be sustainable this way. How does your team contribute? Does your team have all the components of a viable system… and should it?
Stafford Beer (1926-2002) coined the Viable Systems Model to describe what it takes.
A Viable System has five types of subsystems.
(This is summarized from Critical Systems Thinking). See whether you can spot where you fit in your team and in your company.
Systems 1: where the work gets done. These are business units. In a software company, they’re development teams.
System 2: support subsystems and coordination. They exist to help all the Systems 1 do their work effectively, legally, without stepping on each other. HR, Legal, IT support, security. In a software company, platform teams are here.
System 3: coherence in execution. Someone has to get all the business units to work toward the same goals. This is management.
System 4: environmental interactions. The environment is changing; someone has to notice, and bring that information back to the system. Here are marketing, sales, user research. Here I find Developer Relations, because we’re all about bringing our product to the attention of the world plus bringing modern realities and trends to the attention of internal teams.
Systems 3 and 4 are often in conflict. System 4 is like, “We need change, we must adapt!“ System 3 is like, “We need stability, so we can produce efficiently!”
System 5: policy. This is where we decide: who are we? what are we trying to do here? In companies, this is the executive team and the board of directors. But it can be everyone, it can be a collective decision.
Where does your team fit? If you’re a developer on a product team, then you’re part of System 1. There can be many Systems 1 in a viable system, and each System 1 is also a viable system.
The Viable Systems Model is recursive.
On a software product team,
Systems 1 (doing the real work) are people. Each developer (including people who focus on design or testing) is a viable system as a human.
System 2 (support) is the glue work and coordination. Who does that on your team? Probably the manager does some of it. Maybe you have a coach, or an infrastructure specialist. Whoever is a stickler about writing docs or test plans, they’re being System 2.
System 3 (coherence in execution) is usually the team’s manager, supported by a tech lead and team members.
System 4 (external focus) is Product, and the tech lead and everyone on the team who worries about the impact of changes on other teams.
System 5 (policy) is everyone. If the team has its own agency, then the members collectively work out what makes this team what it is, why it exists, how it works, and what it values. If this is set outside the team, the team is not a viable system, and therefore the larger system is unhealthy.
The Viable Systems Model is only recursive on Systems 1 (the real work).
Here’s the thing: the other subsystems, Systems 2-5, must not be viable systems.
If HR becomes its own viable system, it’ll start preserving itself, creating bureaucracy. The rest of the larger system suffers. If the platform team is focused on being the best team it can, producing an extraordinary and general infrastructure product… well, maybe it’s time to spin it off as a startup, because our company is about something else. System 2 exists to serve Systems 1, not for itself.
Similarly, there are middle management teams that become a force in the organization. Marketing organizations that need development teams to fail in order to protect their own reputation at meeting deadlines; sales teams that don’t communicate customer needs back to product or development. Boards of directors that listen to influential shareholders but not employees.
When support systems become forces in their own right, the larger system suffers.
Viable systems have their own agency.
This tells me that if a development team (System 1) wants to go off the paved path provided by the platform team and operate their own infrastructure, OK. They’re a viable system.
If a business unit—say, the magazine division of a publishing house—wants to hire a few software developers to automate its internal systems, or an external firm to build its web site, OK. They’re a viable system; they can take advantage of provided System 2 support, or not.
These teams still need to work within parameters, and System 2 (coordination) needs to help them. Legal, security, and design teams advise.
If Marketing, on the other hand, wants to hire its own IT support firm or get its own legal advice, WTF. Something is wrong here.
Developer Relations is System 4 (environment focused).
Currently, I’m part of the Developer Relations (DevRel) team in Honeycomb. DevRel is a new function, only a decade or so in the mainstream. Where does it fit? Is it development? Is it product, documentation, public relations?
My team does some engineering work: a little in the product, some proofs of concept, a lot of demonstration. We do writing, podcasts, educational presentations for customers, promotion at conferences. And we do a lot of listening. We have office hours with anyone who wants to chat about observability. We listen to industry trends, to people who like our product, and to people who hit snags. We bring all that back to internal product and development team.
DevRel is definitely System 4.
We’re part of Marketing. When I started at Honeycomb, I was suspicious of this. I identify as a software developer who speaks at conferences. Do I belong in marketing?
Yes. Yes, as DevRel, we belong in Marketing. Our function is distinct from the rest of the department, but it fits, because they’re both System 4.
My team is not a viable system.
This means that my team exists to serve the rest of the organization. Each DevRel team member has relationships in product, in engineering, in sales and marketing. We help each other, but we are not a unit in the same way the product development teams are. We don’t need a team motto or color; it is not about us.
I’m OK with that. Someday maybe I’ll be part of an engineering team again, and have that feeling of camaraderie that comes from being in a small, viable system together. Meanwhile, I enjoy helping a system that’s bigger to survive in a world that’s changing.