Andrew Rice
Libby Pier
For decades, efforts to modernize organizations’ operations have leaned on a familiar triad of "people, process, technology." More recently, many have added data to the mix, recognizing that it fuels and connects the other three. In our work with K-12 education systems, we’ve applied this same data-first lens by working with our partners to help them establish data governance first, and then aligning people, processes, and technology around it.
Over time, though, we’ve seen that treating any one of these elements as the first step—and sequencing decisions linearly—creates a Gordian knot. Every attempt to optimize one strand tightens the others, stalling progress and creating friction. Just like Alexander the Great finally “solved” the Gordian knot by slicing through it with his sword, leaders often feel forced to cut through their knots with rigid, top-down mandates that stifle creativity and innovation.
This sequential approach made sense when technology was limited. For decades, organizations had to manually link data across systems or lock themselves into closed software ecosystems that restricted flexibility. But now, machine-based interoperability can exponentially reduce the need for human intermediaries. As systems automate connections, the tensions among data, software, people, and process domains become more visible—and they need to be managed iteratively rather than sequentially.
From Linear Governance to Parallel Collaboration
To avoid getting tangled into a Gordian knot of operational stagnation, organizations need a new mental model that manages interdependence as a source of productive tension rather than a problem to work around. The key to maintaining this productive tension is people.
A parallel, people-centered model of governance puts data, software, and process on equal footing. People manage these dimensions iteratively through creativity, collaboration, and conflict resolution. This approach has helped us internally at EA start to untangle our own Gordian knot and rapidly accelerate our modernization efforts.
Making Governance Work: The Governance Triangle
Each of the three vertices of the governance triangle have their own scope of authority:
Imagine an HR team implementing a new payroll system. Data governance defines how employee information (e.g., IDs, pay rates, vacation balances) is structured. Software governance approves the selection of the tool that meets both data and process requirements, and ensures the tool has the functionality needed for both organizational and HR team needs. Process governance manages how workflows like time tracking and leave requests adapt to the new system. Separating these governance bodies allows each to set priorities and constraints within their domain while making tradeoffs transparently across them. It isn’t easy work, but it makes the inevitable tensions visible and tractable.
From Triangle to Prism
In reality, organizations don’t operate a single triangle. Each system—HR, finance, contracts, customer relationship management, etc.—is its own triangle. Together, they create a prism of interconnected systems. What “counts” as a single triangle will depend on where in the organization you need to assert and preserve local control. Then, across systems, decisions and tradeoffs can be made following consistent philosophies, such as:
- Sequencing enterprise-wide changes
- Maintaining shared definitions (e.g., employee ID, student ID, contract ID, assessment ID)
- Flagging redundant or incompatible tools
- Enforcing workflow coherence
- Establishing decision rights among stakeholders
A prism, rather than a two-dimensional triangle, emphasizes that leaders need to manage interconnected systems iteratively and simultaneously, surfacing trade-offs upfront rather than rediscovering them later. The prism governance model supports local complexity within systems where necessary while ensuring greater overall clarity and coherence. With people at the center, the prism reinforces that governance is ultimately about managing change for those affected.
To make this prism work, leaders create the parameters for how systems operate, while functional teams implement and maintain those individual systems. Governance roles may align to functional roles like Chief Data Officer, Chief Information Officer, or Chief Operating Officer. But what matters most is authority, not title. In our experience, you do need a single governor of each domain with similar levels of institutional authority to maintain independence of each domain. If one domain dominates, or one person is in charge of more than one domain, tensions stay hidden and tradeoffs go unpriced.
The governors of each domain must come together in a committee empowered to resolve tensions, not just document them. Their shared roadmap should be visible to individual system owners, so that pain points can be prioritized coherently rather than reactively.
Resolving Tensions Rather Than Yanking Strands
Two examples illustrate how the tensions among data, software, and process often show up: one example from our own operations, and another example reflecting our work in K-12 education.
Example 1: Contracts and Performance Obligations
Consider a company translating contracts (legal documents) into performance obligations (a distinct promise to transfer a good or service to the customer). Performance obligations may or may not be listed in a contract explicitly, so they need to change the contracting office’s workflows so that when contracts are entered into the software tool, they can be decomposed into performance obligations that can the system can map to deliverables. When deliverables are completed, then revenue can be recognized for those performance obligations.
Where are the tensions?
- Data & Process: Data governance needs granular data elements to enable accurate revenue tracking; the contracting process must now include a step to record these data elements
- Data & Software: The existing software lacks a field for performance obligations; the organization must decide whether to customize, replace, or supplement the software in use
- Process & Software: Using an additional tool for tracking performance obligations outside the contracting software adds complexity and reduces efficiency
If approached sequentially, the organization might first design a data model assuming that performance obligations can be extracted automatically from contracts, only to later discover that contracts are rarely written in a way that makes this possible. Then, after adding a process step to translate contracts into performance obligations, perhaps the contract software in use can only track at the contract level, not the performance obligation level, forcing inefficient workarounds or additional tooling.
The governance prism surfaces these tensions in parallel and iteratively, before the semantic layer is finalized, the contract management tool is selected, and the process is rolled out to staff. The implications of each decision get surfaced at the outset, allowing the tradeoffs to be weighed and worked through. This integrated, parallel approach takes more time initially before implementation, but it significantly reduces the exhaustion of repeated change management that comes downstream. It also ensures that the compromises made are deliberate and transparent, rather than accidental byproducts of which decisions were made and rolled out first.
Example 2: Statewide Strategic Planning
A state education agency is developing a statewide strategic planning system for all of their districts. They experience similar tensions:
- Data & Process: Districts define their strategic goals and performance metrics differently, which prevents aggregating or comparing results across districts without a standardized process for defining and collecting these data elements.
- Data & Software: The state’s planning portal may not be flexible enough to capture all of the strategic planning elements required by their district policies. The state’s IT team must select or adapt tools to accommodate flexible data definitions, while ensuring that standardized data schemas are maintained for state reporting and compliance.
- Process & Software: Districts need flexibility to define creative, locally relevant strategic plans, so the state’s software tool must be usable for a wide variety of different district processes.
If approached sequentially, the data governance owner might design the data model assuming that all strategic planning metrics can be standardized, only to later discover that local definitions are too varied. Or the agency may realize the software interface doesn’t allow for flexible formats that the districts use, forcing either rigid standardization or cumbersome workarounds. The governance prism positions people to surface and address tensions between flexibility, standardization, technology, and change management across both district and state levels.
Both examples are intentionally oversimplified, but it’s easy to imagine the many other workflows, software tools, and data elements intertwined with each of them. The Gordian knot emerges when these interconnections across local systems arise without global governance. The governance prism offers a way to detangle them.
Conclusion
Every modern organization grapples with tradeoffs among software, process, and data. No single vertex of the prism can untangle the knot alone. Rather than trying to wish the complexity away through an oversimplified linear workflow, the key is embracing the global complexity through iteration and collaboration while delineating the local authority to govern from each domain.
The governance prism offers a practical starting point. An organization can begin with one single, thorny system to demonstrate how balanced governance reduces friction, then expand from there. As K-12 education systems seek new and sustainable funding sources to support ongoing modernization needs, we think funders should require grantees to articulate this kind of governance structure. Without it, even well-intentioned efforts risk becoming yet another one-off initiative that can’t scale or take root within an organization’s operating system.