Project Governance & Architecture: A Federated Model

By Ethan Eggert

Background

This article is in reference to OSU's CubeSat program and its governance model.

When working with an engineering team to build a complex system--especially one where standards are so important, such as in aerospace--most teams seem to default to a more rigid, top-down hierarchy. We reject that model because it can kill creativity, meaningful discussion about alternative solutions, foster a compliance-only mindset, and funnel burnout onto a single project manager.

In other FOSS environments, some projects adopt a "do-ocracy" governance structure, where those who take initiative and actually do the work are responsible for decision-making around their parts. While do-ocracy creates initiative and a sense of ownership within its participants, problems around coordination arise when decisions around critical systems are made completely autonomously without consideration of standards, the broader system, or the rest of the organization; this is why we also reject a pure do-ocracy environment.

This is why we propose a system of Federated Decentralization.

Federated Decentralization

Federated decentralization is a governance model that describes how authority and decision-making move toward the "edge" (in this case, individuals and teams working on subsystems), while still maintaining a strict, shared set of process and standards at the center that ensure interoperability and safety at the systems-level.

This model is built on several layers:

Autonomous Edges: each subsystem (e.g., power systems, communications, etc.) operates as a semi-independent team. The contributors here have full autonomy to select parts, write code, design boards, and iterate without permission from a central authority, so long as their solutions and process follow the shared model. This also doesn't restrict peer-discussion around important topics like part selection or trade-studies. Alongside the federated standards, teams can choose to bring in other subsystems, team-members, and subject-matter-experts (SME) to discuss important requirements--again, as long as they meet the standards.
The Federated Boundary: this is where the autonomous edges meet the federated system (standards, process, mission context, etc.). Instead of controlling how the work is executed, the system only controls how components interact, defined through transparent standards and boundaries (e.g., Interface Control Documents, budgets, toolchains, design-review standards, macro-level process, etc.). When edges meet--like subsystem-subsystem communication or system integration--they must conform to the defined protocol. As long as the protocol is followed, the internal mechanics of those edges are its own business.
The Meta-System: at the very top level, there is a coordination framework/process--in our case, it's a core set of central and final reviewers who validate against the federated standards, as well as a branch protection ruleset and design review process on our GitHub repository that prevents unvalidated changes going into production. This last defense is only to manage risk, manage disputes, and ensure changes meet the defined standards.

Leadership vs. Stewardship & Project Roles

Under several similar engineering teams at OSU, sub-team leads act as intermediate leaders between people contributing to subsystems and the team lead(s). We find there are several problems with this design:

Large burdens are placed on sub-team leaders: leaders are often individual contributors themselves. They are expected to create and assign tasks to contributors, fulfill administrative tasks, write reports, contribute technical writing to communicate to non SMEs, onboard members, and perform meaningful work, all on top of student responsibilities. This creates huge cognitive load that leads to sleep deprivation, rushing, and missed mistakes that create points of failure if not caught.
Communication flows from the bottom up through the hierarchy, which is lossy. Each time information is passed up the chain, context is lost that can lead to misunderstandings or missing information, which adds up and can influence future misinformed decision-making. Combined with a top-down authority approach, solutions or ideas can be stifled or squashed.
Erosion of voluntary association: people choose to contribute to complex mechanical, hardware, and software projects because they are driven by curiosity, ownership, and intrinsic motivation. When sub-team leads act as project managers who create and assign work from the top-down, contribution turns into compliance, which in-turn demotes them from autonomous contributors to ticket-takers, killing the core reasons they join in the first place. We've seen this first-hand while operating under this model--there's lots of interest early on, but retention drops significantly once tasks are assigned.
- This compounds with the responsibilities sub-team leaders have--contributors need guidance, especially in such complex systems, and when sub-team leaders already have huge burdens, leads to under-explained or missing guidance altogether. We noticed that when people felt lost, they lost interest and left.
- In a model that distributes autonomy to contributors evenly (not a top-down approach), onboarding, guidance, and work are more evenly shared among peers.

To fix the structural failures of the sub-team lead model without falling into chaos, we propose a shift to teams being organized around stewardship, rather than a top-down approach.

The alternative model operates through several key changes:

Functional Stewards: Sub-team leads are no-longer present. Instead, they are replaced by functional stewards. Stewards don't assign tasks, dictate how problems are solved, or manage day-to-day work. Their role is solely gatekeeping and maintenance; they are responsible for moving designs and solutions through peer-review, ensuring changes adhere to federated standards, and protecting the broader body of work.
- The important distinction to make is that while stewards cannot assign work, they can still help lost or unguided contributors find work. They can curate good first issues (e.g., making sure the project board is populated with well-scoped, low-risk, and small issues), match--not assign--people to work that meets their capabilities and interests, and point contributors to knowledge-bases for guidance.
Peer-to-peer Communication & Shared Onboarding: by eliminating the game of telephone up to the top, communication and onboarding is horizontal and transparent. Technical discussion and design-reviews are held openly in public (e.g., Discord, GitHub issues, documents) so anyone can have access to the full context. Furthermore, onboarding is no-longer handled by a single over-worked person. New members can onboard by reading documentation, self-associating with curated issues, receiving membership directly from peers, and referencing existing work.
Top-layer Standards Body & Final Review: despite day-to-day decisions being decentralized, a complex system of this nature requires a central point of interaction, integration, and standardization that ensure every component meets and survives the functional requirements and constraints. This layer doesn't act as a management body or dictate overall visions, instead acting as a guarantor. Its responsibilities are as follows:
- Verifying that all merged and integrated subsystems adhere to the system constraints, budgets, interactions, and standards.
- Act as a component of the Meta-System that exists to be the final check to hold subsystems accountable to requirements and standards
- Determining the federated standards and processes used in the program such as toolchains, design rules & standards, processes, and more

Pipelines & Decision-Making

Every change goes through a transparent and open-source pipeline / workflow:

Open Proposals / Design Reviews: ideas, solutions, and proposals are all conceived and discussed publicly. Anyone can contribute or critique regardless of seniority. These then move through design reviews to address open questions, risks, and approve work to start.
Peer Review & Simulation: designs are checked against the federated standards using publicly available processes, checklists, and design standards. Additionally, automations are in place to enforce strict standards: code is built & tested using CI/CD, hardware designs are checked using ERC/DRC, and structural components are simulated using FEA, CFD, etc.
Boundary Check: stewards verify that the designs meet the system standards.
Merging: Once a consensus is reached between contributors, designs meet standards, and checks pass, the change is merged. The final reviewers then ensure that everything matches.

How This Affects (New) Members