Category: Technical Management

Organizations need both Implementers and Integrators.

Implementers are those who specialize in nuts and bolts execution work. Migrating a database, making color and font choices for a landing page, and managing event logistics are all examples of implementation. By contrast, integrators observe disparate pieces of a system working in tandem, and discern ways of helping them function better together. This could mean noticing where teammates have a pattern of talking past each other and intervening to resolve confusion before the wrong thing gets built, or recognizing that two people want to develop similar skillsets and pairing them up to take a course together.

In tech, we index heavily on Implementers. I believe part of this comes from most companies initially facing an existential chasm as a matter of course, which gets crossed by getting V1 out the door. At this point, implementing your way forward is really your only option. After you’ve implemented successfully enough to see another day, that experience stands as a powerful object lesson among your early team. The time you crossed the chasm becomes the stuff of shared legend.

As organizations age, the technical and human systems being maintained grow in size and complexity. The more pieces you have, the more different ways there are for them to malfunction. This is when the need for Integrators who can recombine or fine tune the pieces so they run together more powerfully, or reliably, or humanely, really emerges.

Recognizing and responding to this shift is tricky. Integration work can be a lot harder to account for, therefore harder to set up as a function. Effective Integrator work also requires observation before action, and then action often takes the shape of nuanced adjustments which are only felt throughout the system later on. Sometimes, an org under strain from growth will respond by adding Implementers, without realizing what they need is more Integrators. This is rational. We use our past experiences to inform our present strategies, and based on the past, adding more Implementers is the way to move forward. Unfortunately, this old strategy applied to this new problem can exacerbate the strain. An uptick in Implementers creates more complexity which needs to be managed, further increasing the need for Integrators. Contributing to the force of this tightening ratchet is the fact that Implementer work, with its tangible outputs, is vastly better understood, and almost always more rewarding in the immediate-term. Properly establishing Integrator work within your org requires a lot of faith, and interpersonal trust, and moving through uncertainty.

You might know Integrators under a different name: managers. Good management is more than bossing people around. A good manager bridges the divergence in people’s frames of reference, creating shared meaning so that more than one person can do productive work on same problem. Inevitably flat organizations realize they need management once they hit a certain scale. Without designated Integrators, it becomes unclear where individual contributors can make the most impact—to say nothing about where they go when the friction becomes too great. Meanwhile, managers who do just boss people around leave their direct reports feeling helpless and blindsided as a matter of daily course, as they lack a sense of the bigger cohesive picture and their role in influencing it.

Developing this new lens and upgrading your toolset at a point when you’re facing high stress and high stakes is exceedingly difficult. It can be hard, in the flow and the mess, or worse, when it feels like nothing is working and the pressure is weighing on your chest, to stop to ask yourself and your collaborators why things feel so off, or whether you’re all solving the right problem. Yet this sort of virtuous non-complementary behavior may be the best way to ensure integrity in the systems you’re all maintaining.

Conway’s Law states that:

“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

In other words, the communication patterns in your team are duplicated in your software. I recently had a chat in which my counterpart made the point that if we take Conway’s Law to be true, it should stand that the mental state of the individuals doing the communicating is having a great affect on your software.

When dealing with networks, we most often focus on the edges between the nodes. Without computers talking to each other, there is no network, so it makes sense to focus on connection and uptime. Yet when dealing with networks of humans, I believe Conway’s Law calls on us to start by examining the state of the nodes themselves.

In contrast to inanimate interactive entities, like servers, human nodes are neither uniform nor neutral. Much the way DNA contains a set of plans for how an organism’s development unfolds, humans are carriers of their own design patterns. The way these design patterns are expressed in an organization (aka within the network) will vary based on things like their past lived experiences and identities, whether or not they perceive that their contributions are respected, or whether they’ve gotten enough sleep or calories, just to name a few. An individual human node will respond to stimulus differently based on the state of these factors, which shift how they will communicate on a given day. Conway’s Law postulates that this is reflected in the software system they’re building. Then, there’s a concurrent process running where they interact with other humans in your organization, each with design patterns of their own. This dance of interrelation produces the state of your software.

While preemptively controlling for every possible aspect of the communication between the humans designing your system is unlikely, it stands to reason that optimizing for the well-being of the individuals doing the work can be a sort of resilience engineering. Things like proper compensation, respect for boundaries, a blameless culture, and clear opportunities for advancement create circumstances most likely to engender an open, well-regulated, constructive mental state in your individuals. If Conway’s Law is right, maintenance on the state of the human nodes in a network paves the way for more constructive communication patterns, and better software.