Knowledge is Relational Reciprocity

Knowledge doesn’t trickle down, it flows across systemic relationships: people, teams, and tools exchanging perspective and context.

Reciprocity means “how the parts working together”. It is a mechanism, the recognition that parts of a system (teams, software) should work together. It means, fundamentally, that we need to share our knowledge.

Well-designed reciprocity translates context across roles. For example, when I take an action, I understand why that action matters. I’m not simply doing what I’m told, I’m acting on something I understand.

Reciprocity leverages tacit know‑how by integrating the hands-on insights we can’t easily explain. For example, when I’m writing the code that delivers a new user experience, I can also help shape the “strategy and requirements” that governs my activity. I help the organization integrate machine thinking into business goals and human activities by integrating strategic ideas with implementation wisdom.

Without relational reciprocity, our time, energy, and attention fall into the gaps — between people, teams, software sytems, roles, and points of view. WIthout it, we are throwing the money we pay for knowledge work into a well, where it lies dormant.

Human, organizational, and technical dynamics intertwine. This is what we mean when we say sociotechnical systems. Social process and our technology systems co-create each other. Our epistemic infrastructure can co-create coherence, enable these parts to act in harmony. Or lack thereof, creating blockers, gaps, silos or a firehose of meaningless information to scan (I’m looking at you Slack channels.)

Coherence isn’t something experienced by one person, team, leader or piece of software. It lives in the relationships between people, tools, practices, and contexts. It enables parts of a system to move in relation to one another – and still make sense together.

Coherence creates resonance, enough autonomy and adaptation to operate like a jazz ensemble rather than four six-year-olds playing a kazoo.

You are cultivating coherence when you intentionally design patterns of relationship between people, tools, practices, and contexts. When meaning can travel across boundaries, when others understand why something matters, or the impact of their decisions, you are cultivating coherence.

Most systems, including human systems, thrive when meaning can travel across boundaries without excessive need for executive command and control.

An example of coherence building is developing shared language. An ontology, a set of concepts and categories relevant to your domain. For example, what do we mean by “product”, “platform”, “value”, “manager”, “Agile”, “customer”? Shared language builds coherence – many, many gaps between organizational units exist simply because the people do not, can not, speak the same language. If we can’t share the same concepts, we can’t design knowledge flow.

When we make the core concepts that structure meaning in an organizational domain visible, we can also structure relationships between them. (In Domain-Driven Design, this is called ubiquitous language.)

If you want to experiment, you can AI to analyze artifacts used by three or four diverse parts of the organization. (For example, engineering teams, product, finance or HR and operations.) Highlight the most-used terms and their relationships. Review the list as a group, are they consistent? Do some concepts cross boundaries? Do some concepts shift in ways that dissolve shared understanding?

An ontology, shared concepts, is an enabling constraints. Meaning it is not used as a constriction or commandment. It simply enables more creativity in living systems by shifting attention away from endless cat herding, towards natural cross-functional collaboration.

Consider this

In what area of work would you like a partner? Someone who thinks differently, whose skills would compliment yours?