Building a Leadership Team

The Method

Edith A. Hughes, D.Sc.  ·  Adaptive Value Design LLC  ·  2026

I. The Missing Discipline

An observable pattern has emerged from federal agency transformations. An agency identifies the need for change. A framework is brought in. The framework is adopted — or more precisely, its vocabulary is. The agency reorganizes around the new vocabulary. And the underlying structural problems remain unaddressed.

Matthew Burton, writing for the Niskanen Center, describes a related dynamic in Information Technology as vendor capture.¹ It is the moment when a government agency becomes functionally dependent on a contractor or set of contractors to the point where the dependencies extend into what should be inherently governmental domains: knowledge, execution, continuity, and decision-making. As described in Article 2, a large federal agency’s operating model transformation provides a good example. McKinsey proposed a “product and platform” operating model — a consulting-firm framework distinct from the practitioner-grounded body of work built from case study-based research. Without the foundational work that would have given the executive team a shared understanding of any model and its requirements, the transformation defaulted to the function with the most direct connection to its vocabulary. Because the initiative language linked the model to the acceleration of technology delivery, the CIO stepped into the vacuum. A business transformation became an IT initiative. The agency’s technical architecture, rather than its mission domains, became the organizing principle.

One key antidote to vendor capture extends beyond better procurement or more skeptical contracting officers. It is an executive team that has done the foundational work to understand what value it exists to deliver, who its customers are, and how value flows through its system. An executive team with that foundation can evaluate any consulting framework on its merits, adapt it to their context, and own the result. An executive team without it cannot.

Article 2 examines the system conditions that make that foundational work possible — and what changes are needed to make it the norm. This article describes what that foundational work looks like when it is done deliberately and how to design the conditions that make it possible. The Census Bureau engagement of 2013 is an example. Not because it was perfect, but because it worked: it produced a leadership team that could see its enterprise together, and a foundation from which real operating model improvement became possible.

II. Start with Why

Mark Moore’s foundational work on public value established a principle that federal managers have been slow to apply: before an agency can define what it does or how it does it, its leaders must first define why it exists — that is, the public value it is authorized and obligated to deliver. In Creating Public Value, Moore places that purpose question at the center of public management.² It is not a strategic choice or a leadership aspiration. It is a public accountability. Simon Sinek would later popularize a version of this idea for private organizations, but for federal agencies Moore had already established the more precise formulation: the “why” is not discovered through introspection. It is assigned by Congress through law and confirmed through statutory analysis.

This concept leads to two questions that should open every federal leadership engagement before any framework is introduced, any strategy is written, or any operating model is designed. First: why did Congress legally authorize this agency to exist? Second: what is the agency required to do? The first question establishes the agency’s core public purpose: the mission value it exists to deliver. The second defines the mandate: the specific activities, services, and functions the law requires in service of that purpose. Together they establish the statutory foundation from which everything else follows, and the what that flows from the why, the customers who co-create value through the what, and the value streams that constitute the how.

The Census Bureau engagement illustrates why. The Bureau’s statutory mandate is clear in broad terms: collect, process, and disseminate data about the American people and economy. When the Census Bureau executive team began their engagement in 2013, each member understood the Census mission and the legislated requirements from his or her functional perspective. But they had never looked at how their functions fit together to collectively deliver on that mission.

III. What: Define the Problem Space and Value Streams

The Census Bureau Data Dissemination Task Force, a cross-functional team of 16 senior executives, was not struggling with the mandate in the abstract. They were struggling with a specific and consequential challenge: how to define and develop a strategy and action plan for modernizing their data dissemination environment. Different leaders had recognized the constraints they experienced from their own vantage point and surfaced potential solutions accordingly. But their individual views had not yet been effectively stitched together into a holistic, big picture view for the leaders to explore together.

The first working sessions were designed to address exactly that gap. Drawing on emerging business design practices and methods borrowed from leading technology organizations, the sessions gave the executive team structured tools for mapping the problem space together: its scope, its boundaries, its key elements, and the interdependencies between them. The goal was not to produce a slide deck. It was to produce a shared mental model that every executive in the room had participated in building and could therefore genuinely own.

G. Lynn Shostack’s concept of service blueprinting, introduced in a landmark 1984 Harvard Business Review article, offers a useful lens for what this mapping work reveals.³ Shostack argued that service delivery should be approached as systems engineering to explicitly distinguish what customers see and experience in the frontstage from the supporting processes and infrastructure operating behind the line of visibility in the backstage. Twenty years before modern digital service design made this distinction fashionable, Shostack was making the case that service quality failures are almost always design failures: the result of organizations that understood their backstage operations but had never mapped them to the frontstage experience of the people they served.

For the Census Bureau, the data dissemination environment was precisely such a system. The Bureau’s researchers, technologists, and program offices operated in the backstage to design, produce, process, and maintain the data products that constituted the agency’s core output. The American public, policymakers, businesses, and researchers who depended on that data interacted with the frontstage, trying to discover, access, and use what the Bureau produced. The gap between what the backstage produced and what the consumers needed was the problem space the executive team had gathered to address. Mapping it together, explicitly, for the first time, was itself a form of progress.

IV. Who: Map the Customers

Mapping the problem space reveals the system. Mapping the customers reveals who the system exists to serve and who makes it work. In federal government, these are not two separate exercises. Customers are not external to the system; they are integral elements of it. Consumers, Producers, and Approvers are the key actors whose interactions and interdependencies define how value flows, where it gets stuck, and what the system must be designed to do differently.

Article 1 introduces the three-customer framework: Consumers, who directly receive the service; Producers, who deliver it; and Approvers, both external (Congress, oversight bodies, advocacy organizations) and internal (executives who authorize investment decisions and oversight functions), who authorize and hold the system accountable.

What Article 1 describes conceptually, the Census Bureau sessions made tangible through a facilitation technique that turns out to be as important as the framework itself.

Instead of asking the executive team to build a system diagram from scratch, the facilitators presented them with a partially completed picture: a frontstage/backstage map of the Census data dissemination environment that placed customers — with Consumers and Approvers visible in the frontstage, value stream steps sketched across the system, and the backstage functions partially identified — within a single integrated view. The boundary of the “data dissemination environment” was left deliberately undefined. The executives were asked to engage with it critically: what was missing, what was inaccurate, and where would they draw the boundary around the environment they were tasked with modernizing?

What followed was something that no amount of asking people to “collaborate” would have produced. An executive team of sixteen, representing different functions, different priorities, and in some cases competing interests, came together around the shared task of telling the facilitators how they had gotten it wrong. The partially completed diagram did what no blank whiteboard could: it gave a group of disparate participants a common object to react to, a common language to argue in, and a common purpose to correct the outsiders’ definition of their own system. This common purpose temporarily dissolved the boundaries between their functional lanes.

For the Census Bureau, that integrated picture revealed something the executive team had not previously articulated together: the data products the Bureau produced were not reaching the researchers, policymakers, and public users in forms they needed to easily discover, access, and use. The dissemination environment was the gap between what the Bureau knew how to produce and what its consumers needed to receive. Naming that gap together, placing it within the shared system picture, and agreeing on its scope, became the moment the problem space and the customer landscape converged into a design challenge the team could collectively own.

V. How: Design the Value Streams

With a shared understanding of why the agency exists, what it does, and who its system serves, the executive team is ready to address the fourth question: how does value flow from the trigger of customer need to a delivered public outcome? This stage is where the language the series argues for throughout becomes a lived experience. In the room, with the shared system picture on the wall and the customer landscape mapped within it, “products” stop being the right word. The team is no longer looking at only outputs to be built. They are looking at a flow to design. The initial system diagram made that flow visible immediately: it included the Bureau’s own published Survey Development Lifecycle, the documented sequence of steps from survey design through data collection, cleansing, tabulation, disclosure review, and publication, placed within the full system picture for the first time.

Placing the SDLC within the integrated system picture, with consumers visible in the frontstage and backstage functions arrayed around it, did something unexpected: it revealed that the team had been thinking about their own process incorrectly.

The Census Bureau had always represented and understood their SDLC as a linear flow. Step follows step; the process moves in one direction; the output is a published data product. But seen within the full system picture, with the varied consumer types visible on the other side of the line of visibility and their feedback needs made explicit, the linear model was missing something valuable. The feedback loops between the consumers using the data products and the survey designers and product managers were never designed into the cycle. Tracing a value stream end-to-end, from survey design through backstage production through the line of visibility to frontstage consumption and back again, surfaces exactly these kinds of errors: design problems made invisible by functional structures and linear architectures, but unmistakable once the full picture is seen together.

Two of those insights stand out. The first was the SDLC reframing from linear production process to circular, feedback-rich cycle. Consumer needs and preferences should influence survey design. The second was equally significant, and it involved the Approvers in the system picture. Congressional oversight had been experienced by the Bureau primarily as a retrospective accountability mechanism: Congress reviewing performance and holding the agency accountable after the fact. Seen within the integrated system picture, a different relationship became visible. Congress was not just a watchdog. It was an Approver whose early engagement and input were necessary for the Bureau to navigate the constraints and tradeoffs that Decennial planning inevitably produced. The team recognized that, instead of waiting to be called to account, the Bureau should be proactive in keeping Congress informed about emerging challenges, seeking their input on alternatives, and treating oversight as a collaborative relationship rather than an adversarial one.

VI. What the Engagement Produces

The Census Bureau engagement did not begin with an operating model. It did not begin with a technology strategy, a reorganization plan, or a transformation roadmap. It began with a set of questions that federal executive teams are rarely given the structured opportunity to answer together: why does this agency exist, what does it do, who does it serve, and how does value flow through the system they collectively manage?

The answers, which they built jointly, tested against a shared system picture, grounded in statutory purpose, produced something that no consultant deliverable can substitute for: a leadership team that sees its enterprise together.

The Census engagement produced two lasting legacies. The first was operational: the Center for Enterprise Dissemination, the enduring enterprise solution the Bureau built for data dissemination in the years that followed. The second was cultural. In the words of one task force co-chair reflecting on the experience years later, the engagement “ventilated our siloed activities,” creating the conditions for collaboration across boundaries that had previously been impermeable, and helping pave the way for the Bureau’s broader Transformation Initiative. The sixteen executives who worked through those sessions emerged with a shared vocabulary, a common mental model, and a level of trust built through having disagreed productively and arrived somewhere together. The engagement did not solve the problem. It built the team that could, and in doing so, changed what the team was capable of becoming.

Article 4 takes up the structural question of how an agency should organize its mission domains, decision authorities, and technical architecture so that all three reinforce each other rather than work at cross-purposes. The answer draws on the same convergent insight that Domain-Driven Design, Wardley Mapping, and Team Topologies have each arrived at independently. That convergence has a name: structural isomorphism.⁴ The foundational work this series has described is what makes that structural alignment possible to achieve. Without it, isomorphism is an architectural aspiration. With it, it is a leadership decision.