top of page

People Are the System

2 hours ago
14 min read

One of my previous bosses once told me a metaphor about organizational leadership that stayed with me for a long time. He compared it to gardening. You cannot really build a garden by designing every plant individually and then expecting the result to behave according to your drawing. You prepare the soil, decide what you want to grow, give things enough room and resources, remove things that are getting in the way, occasionally move something somewhere else, and then mostly pay attention to what is actually happening. You water the plants and fertilize them. Every now and then you cut a branch, or swipe a path. Some plants will thrive. Some will shrivel despite your best efforts. Some unexpected thing will grow where you didn't plant anything at all.

It took me years to understand why that metaphor felt so good. What I have been missing was a way to describe what I was actually looking at when I looked at an organization. I tend to see organizations as networks of people and relationships between them. These connections are the substrate that allows the organization to thrive.


Image generated by ChatGPT based on hand written notes
Image generated by ChatGPT based on hand written notes

I don't think this is the one true ontology describing an organization. I don't particularly believe there is one. An organization can be understood through its teams, its processes, its incentives, its products, its reporting structures, its architecture, its finances, its customers and probably several hundred other useful lenses. None of them is objectively correct or incorrect. Each of them can be useful at a different time. The one I want to talk about today has helped me in being a better gardener.

The boxes we normally draw around people to represent teams are useful, but they are not the thing I am primarily interested in when trying to understand the company dynamics. Alice being in Team A tells me something. Alice knowing Bob, being able to safely challenge Carol, regularly solving problems with Dave, avoiding conversations with Eve and being the person Frank asks when he does not know who else to ask tells me considerably more about what the organization can actually do.

Relationships are not merely communication channels though. Two people who know each other exist in a different system from two people who do not. Two people who have worked together successfully for years can do things together that two otherwise equally capable people cannot simply do on their first day of working together. They can anticipate each other's behaviour, recognize when something is wrong, compensate for each other's weaknesses, challenge each other's assumptions without starting a fight, know who should make a particular decision and often solve problems without having to explain the entire context first. These are emergent capabilities that do not belong entirely to either person, but exist between them.

There are simpler relationships as well. Someone can know that another person exists. They can know what they do. They can know which problems that person tends to deal with. They can know that they are competent, or difficult, or trustworthy, or someone to avoid. They can know who that person knows. They can have a shared history. They can be friends or something else altogether. These things do not all behave the same way when the organization changes.

If Alice moves from one team to another, the organizational chart has changed immediately. From the perspective of the boxes, there is very little left to discuss. The headcount moved from one place to another.

Some connections barely notice the move. Some weaken. Some remain intact but become more expensive to maintain. Some disappear because the reason for maintaining them has disappeared. Some relationships were tied almost entirely to the person's role, while others existed independently of it. Some new relationships will need to be formed because the new environment makes them useful. Others will not form at all. The capabilities that depended on those edges changed as well.

The diagram is obviously a terrible approximation of the real thing. I am not trying to reconstruct every interaction two people have ever had. I don't even think that would be particularly useful. I am trying to make something visible enough to inspect that is otherwise largely invisible. I do not use this model as a decision algorithm. It does not tell me what to do with Alice. It tells me what questions to ask.

I am not trying to optimize the network. I care about what the organization needs to be capable of doing, and ultimately whether it produces something valuable. I have to decide whether the expected value of intervention justifies its costs and risks, across relevant time horizons. If I am considering moving Alice, I first need to know why I am moving her. What problem am I trying to solve? What capability does the system need that it does not have today? What is preventing that capability from emerging? What would happen if I did nothing?

Perhaps Alice is exactly the person who can connect two groups that currently have no meaningful relationship. Perhaps moving her would destroy an important capability somewhere else. Perhaps Bob is actually a much better candidate because he already has relationships on both sides. Perhaps neither of them should move and the better intervention is to give the two groups a shared problem to solve. Perhaps the missing connection is not a people problem at all. Perhaps the correct response is to change the work, the incentives, the responsibilities or something else entirely.

The empty space is often more interesting than the edges. Two teams may seem well connected on paper, but then you realize there are only two people who are doing all the talking and should one of them leave, no one knows how to continue the conversation. Or sales and engineering teams that have no direct connection at all. It does not automatically mean there should be one. Perhaps there is a perfectly sensible boundary there. Perhaps engineering is deliberately insulated from constantly changing customer demands and product management is doing its job of translating those demands into something engineering can work with. But if customers are being promised things engineering cannot deliver, requirements are being misunderstood and problems take weeks to travel between the two groups, then the same empty space has a very different meaning.

Organizations contain an enormous amount of information that people routinely throw away because it is difficult to count. A team can be "well connected" while only two people in that team actually talk to anyone outside it. A department can appear completely independent while one particular engineer is quietly holding half of its relationships together. A manager can appear to have excellent cross-team collaboration because everybody attends the same meetings, while the actual work travels through one trusted person who translates everything between the groups.

Relationships hide many different capabilities, and when severed, they do not decay at the same rate. If I know that Alice exists, I am likely to remember that for a very long time. If I know what she does, that knowledge can survive a surprisingly long separation, although it will slowly become stale as both of us change. If we have worked together closely, the ability to cooperate effectively is much more dependent on continued interaction. If we are genuine friends, the relationship may survive years of professional separation almost untouched because its foundation was never the work in the first place. I might not remember exactly what Alice worked on three years ago, but I may have a solid mental model of how she behaves in a particular situation. That kind of knowledge tends to decay much more slowly because it is based on patterns rather than individual memories.

Reputation behaves differently again. In some ways it grows as people move through an organization. Someone who worked with Alice five years ago can carry information about her into a completely different part of the system, even if Alice herself has no relationship with the people there. 

There are also relationships I would rather not preserve. People can distrust each other, compete with each other, undermine each other, protect each other for the wrong reasons, or form alliances that are actively harmful to the system. The absence of a connection can matter, but so can a connection that produces the wrong behaviour.

The relationships are not necessarily symmetrical either. Alice may trust Bob considerably more than Bob trusts Alice. Carol may go to Dave for technical advice while Dave goes to Eve for organizational context. Frank may be the person everyone asks for help while he might be struggling to find someone he trusts enough to ask for help himself.

The useful idea is not "Alice has a relationship with Bob." It is something more like "there are capabilities between Alice and Bob, of various kinds and strengths, and those capabilities have consequences for the larger system."

A company has countless systems interacting with each other. If the organization were an animal, the relationship network would be its nervous system. It would tell us a great deal about how the animal senses, coordinates and reacts, but it would be absurd to claim that the nervous system is the entire animal. There is no nervous system without blood supply, digestion, muscles, organs and all the other things keeping the creature alive.

People and their relationships are the base from which an enormous amount of organizational behaviour emerges. If we want an organization to be capable of doing something, eventually some people have to be able and willing to make it happen, and the relationships between them determine what they can accomplish together that none of them could accomplish alone.

I do not have the best experiences with organizational problems described exclusively in terms of processes or structures. I have heard "people don't talk to each other" used as an explanation for an enormous number of problems. It is usually an oversimplification, but I think it points at something real. The problem is not the literal absence of conversation, but the absence of some capability between people: they don't trust each other enough to raise a problem early, they don't know who has the context, they don't understand each other's constraints, they cannot challenge each other safely, they have no shared language for a particular problem, or they simply have no reason to interact until something has already gone wrong.

At one point in my career, I removed the test management software my teams were using. It produced wonderfully reassuring red and green reports, but those reports were not what I wanted. I wanted better quality at the moment an idea was being conceived, rather than a better looking report. I wanted testers involved in the conversation between product people and the people actually using the product. I wanted them helping teams explore examples and expectations early enough for those conversations to influence what was being built.

Removing the tool was only one part of the intervention. I also introduced three-amigos sessions and asked the testers to collect feedback directly from users. I did not know exactly which relationships would emerge from that, but I knew what capabilities I wanted. I created conditions in which developing the necessary relationships became a useful thing for the people involved to do. Some relationships appeared naturally. Later I helped shape them a little, particularly when there were too many possible users for a tester to work with and we needed to find the representatives who could provide the most useful feedback. However the network mostly adapted on its own because the environment made a new pattern of interaction useful.

I have also used absence deliberately. There was a person in one of my teams who was very capable of influencing another colleague in ways that were becoming destructive. They had a professional friendship built partly around shared experiences that nobody else in the team could really relate to. I did not discover what was happening through one dramatic incident. It was a long accumulation of small anomalies. I would leave a conversation with one of them having agreed on a course of action, only to find the other person had changed their mind completely the next day. I would get both of them to agree to try something, he would stop doing it, and she would suddenly arrive with a surprisingly similar argument for why it was never going to work.

There was coaching. There were difficult conversations. I changed how their work was structured. I tried to solve the problem without removing either person, first, but eventually I decided to terminate his contract.

His removal did not magically solve everything like waving a magic wand. But the system slowly reorganized itself around his absence. The other person slowly became more effective without any dramatic intervention on her part. New connections were built and a relationship that had been enabling a particular pattern of behaviour was gone. Looking back, I wish I had made that cut earlier.

This is where the gardener metaphor becomes more useful to me than a metaphor of organizational architecture. An architect wants to specify the structure. A gardener is trying to create conditions in which something can grow, while accepting that the resulting garden will contain things they did not design.

The gardener can still cut things down. They can remove a plant, move one somewhere else, change the soil, add water, remove a source of shade or introduce something new. Some interventions are tiny and some are substantial. What matters is not how dramatic the action looks, but what behaviour it is intended to change.

Removing a person can be an intervention with enormous consequences. So can removing a tool, changing an incentive, or introducing a problem that two groups now have a reason to solve together. Even leaving something alone can be a valid strategy. That last part is especially easy to forget. Absence is not neutrality. If a person is removed, the system will adapt to their absence. If a relationship is never created, the system will adapt around that gap. If a dysfunctional relationship is tolerated for years, other people may build compensating mechanisms around it. Eventually those compensations can become so normal that nobody remembers there was ever another possibility.

Those compensations can be particularly interesting. An organization that appears to function perfectly may be doing so because one exceptionally capable person is working absurdly hard to compensate for several deficiencies elsewhere. From the outside, the system can look healthy. The person may even be celebrated as a hero. But the network has become dependent on an unusually dense concentration of capability and relationships.

An anomaly is not automatically a problem. Some of the strangest looking structures in an organization are signs of something working extremely well. Sometimes the weird person who talks to everybody is exactly what allows a complicated system to function. Sometimes an apparently isolated team is isolated for very good reasons.

Most of the anomalies are evidence of something interesting happening. The useful ones tend to congregate, have unusually large consequences, or simply are strange enough that the obvious explanation does not quite satisfy me. Sometimes the most interesting anomaly is that something is unexpectedly quiet. The map makes those things easier to notice because it externalizes something that would otherwise have to remain in my head. My mental map is incomplete. Naturally I will not see every lunch between people. I will miss relationships that happen entirely outside my awareness. I will mistake familiarity for trust and friendliness for cooperation and I could choose the wrong intervention.

I could project my own understanding onto somebody else's relationship. The observer is part of the system, and therefore the observation is necessarily biased. I am comfortable living with that limitation because I am not trying to produce a source of truth. I am simply trying to make the system more inspectable by explicitly modelling it on paper.

If I keep the whole thing in my head, I can quietly explain away discrepancies. I can forget that some relationships exist. I can unconsciously assume that two teams communicate because I know that one person from each team talks to each other. I can remember the dense part of the network and completely fail to notice the empty space around it. Putting some representation in front of me makes those assumptions considerably harder to hide from myself.

It also makes the observation discussable. There are people who can see an organization from a useful level of abstraction that others cannot. They tend to be experienced engineers, staff-level people, managers, or simply people who have accumulated enough context to move between different parts of the system without being trapped entirely inside one of them. They become the people you ask when you don't know who to ask. That meta-knowledge is itself a capability. And involving somebody in understanding the system can change the system. Showing a tech lead that there is literally no meaningful connection between their group and sales can produce a conversation that would never have happened if the observation had remained inside somebody else's head. Asking a manager why two groups never interact can surface a legitimate boundary, an accidental silo, an old organizational scar or a problem nobody had noticed before.

I am reluctant to turn this into a methodology because the observation is not necessarily separate from the intervention. I have no interest in producing a standardized scoring system where somebody draws circles around employees, assigns relationship strength from one to five and then announces that the organization should move Alice from Team A to Team B.

The map is useful to me because I am the person operating it. It is one lens among several, and I am constantly changing abstraction levels and bringing other lenses into the picture. The map can tell me that a connection exists. It cannot tell me why. It can show me an empty space. It cannot tell me whether that emptiness is a pathology or a feature. For that I need to ask questions.

What capability do we need? What problem are we actually trying to solve? Why does that problem matter? What does the system currently do instead? Which relationships enable the behaviour we have today? Which missing relationships make the desired behaviour difficult? What would happen if we did nothing? What is the cost of that failure? What is the smallest change that might allow the system to reorganize itself in a better direction?

Sometimes the answer will involve moving a person. Sometimes removing one. Sometimes hiring somebody new. Sometimes changing the work. Sometimes creating a shared problem. Sometimes changing an incentive. Sometimes doing absolutely nothing and watching for another month.

The point of understanding the network is not to forcefully turn it into something it is not. I don't think a complex organization can be controlled in any meaningful sense without either reducing it to a much simpler thing or pretending that the parts we cannot see do not matter. Both approaches can produce impressive-looking diagrams and surprisingly poor systems.

Whether I intervene or not, people compensate for missing capabilities, find workarounds, form new relationships, abandon old ones and gradually change the way work gets done as the environment around them changes. There is a kind of dynamic homeostasis to it. The question is not how to design the organization into a desired final shape, but how to change its conditions so that the adaptation we want becomes the easiest thing for the system to do. Sometimes that means introducing a new connection or responsibility, sometimes removing something that keeps producing the wrong behaviour, and sometimes doing nothing at all because the system is already adapting in a useful direction. When I intervene, the organization reorganises itself around the new conditions. I want enough understanding to do this deliberately. The distinction is subtle but important. I am not trying to design the perfect organization and then make people conform to it. I am trying to understand what the organization is capable of today, what capability I need tomorrow, and what environmental change might make the desired behaviour the simplest and most natural adaptation available to the people already inside it.

Sometimes the system will surprise me. As it should. If every response to an intervention were perfectly predictable, I would probably be dealing with a machine rather than a living system. People bring agency, creativity, resistance, mistakes, ambition, curiosity, an enormous amount of tacit knowledge that nobody has written down and so much more. Those things are not noise around the organizational model. They are part of what makes the organization capable of doing things that were never explicitly designed into it. Much of the value comes from here. I could probably manipulate an organization into becoming a very polished version of whatever I personally believe an organization should be. I could select the people, shape the relationships, control the incentives and remove enough undesirable variation that the whole thing would look remarkably coherent.

But such a system would be limited by my own capabilities and imagination. A living system can develop capabilities I do not possess. It can find relationships I would never have designed. It can produce solutions I would never have thought of. It can become strange in ways that are useful. That is one of the reasons I prefer influence over control. I can plant an idea, create a condition, remove an obstacle, ask a question and see what people do with it. If I have done the job well, the resulting system should contain more intelligence than I could have put into it myself.

The gardener does not get to decide which way every branch grows. They do, however, get to decide what kind of garden they are trying to cultivate, what they are willing to tolerate, what they need the garden to produce and which weeds have become too expensive to keep around. Some plants will still shrivel. That is not evidence that gardening failed. But it is really important to remind myself to pay good attention to notice what is actually happening before I reach for the shears.

 
 
bottom of page