I once paused while reading someone’s resume. It described how they attempted several large-scale technical changes involving multiple organizations but failed each time, diagnosing the root cause as “a collaboration method that failed to define problems together.” My eyes stayed on that paragraph for quite a while.
Wow, this is how a true senior tackles this problem.
When I thought of the word “senior,” what came to mind first was technical depth. Abilities like solving complex problems, spotting architectural flaws others miss, and the deft touch to stabilize systems during crises. Of course, those things are important too, but as organizations grow larger, I started thinking that a true senior’s real capability lies in designing interfaces between organizations with different interests.
Things That Can’t Be Solved by Orders
As company size grows and more organizations become involved, driving work forward becomes really difficult. What’s important to our team might not be important to them, and since everyone has their own circumstances and KPIs, creating a common goal and a collaborative atmosphere is not easy.
The easiest solution would be an order from a higher-level executive who oversees all those organizations. But you can’t do everything that way, and even when you do, many things end up going more difficultly. Work driven by orders usually makes it hard to incorporate diverse opinions with appropriate weight, and there’s a high chance of creating “work for work’s sake” beyond what’s necessary.
Ideally, it would be best to beautifully obtain consent and cooperation from all players with stakes involved, but that’s also not easy. Especially technical changes tend to come with the destruction of existing work methods, making them prone to resistance. It’s too easy to object to a new proposal with “this is realistically difficult for this reason.” Conversely, it’s too hard to collaborate while sharing scarce resources with each other. Saying No is free, but saying Yes is costly.
What Conway’s Law Says
This issue seems related to Conway’s Law.
Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.
The software structure ends up resembling the communication structure of the organization that developed it. In the end, although what we create is software, it stands on top of organizational structure and human psychology.
Even the same collaboration has completely different textures depending on whether it’s with a colleague sitting next to your desk, a teammate on a different floor, or someone from another organization whose name and face you don’t even know. With people on the same team, you naturally talk frequently, and as a result, the modules they’re in charge of become tightly coupled. On the other hand, communication itself becomes rare with teams that are work-wise distant, so boundaries between modules naturally become pronounced, and coupling becomes loose or even disconnected.
Organizational structure determines the distance between people, and that distance in turn determines the software’s modular structure. In other words, code flows along the organizational chart.
What this law suggests is not simple. You shouldn’t complete the technical solution (How) first and bring it in. Our perfect blueprint reads as “already decided matters” to the other organization, and this naturally triggers defense mechanisms in human psychology. That’s what inertia is.
Why We Need to Think Together
Through a senior’s resume, I learned one approach to solving this problem. In the end, agreement on Why must be reached first. Before How, there must be a process of thinking together about Why this work needs to be done.
To draw out agreement on the necessity of work, one method could be to bring our unnoticed pain points to the surface and make them pay attention.
For instance, visualizing the cost of silence that hasn’t been spoken aloud until now. People don’t move easily for abstract risks, but once quantified, they may pay more attention. We need to show the tangible and intangible costs we’ve been paying while not doing this.
When you receive a “notification” of an already completed plan, it’s easy to react critically, but if you “participate” in the design process, you can make them feel a sense of comradeship. One technique often used as a device to induce this attitude shift is to intentionally leave blank spaces in the design. In front of a perfect plan, people naturally look for reasons why it won’t work, but in front of blank spaces that are obviously meant to be filled, they look for the last piece to complete it. The former leads to thinking in the direction of denying the plan, while the latter leads to thinking in the direction of affirming it.
Redefining the Senior’s Role
Looking back, I realized that seniors within organizations should be people who are good at this kind of work. Technical depth is fundamental, but on top of that, the ability to understand the characteristics and circumstances of each organization, adjust interests, and create problem definitions that everyone can accept together.
I think that’s ultimately the work of designing interfaces between organizations. In other words, it could be called influence.
Reading that sentence written in the resume made me think for a long time. Perhaps I had been interpreting the word senior too narrowly until now. The thought that just being good at technology might be an idea that only works when the organization is small.
A problem that isn’t defined together won’t be solved together. This sentence has remained in my head for a long time.