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. A consulting firm proposed a “product and platform” operating model — a 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.

The method is not complicated. But it is deliberate. And deliberate design is precisely what the federal leadership system has yet to make the norm.

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.

This sequence of Why, What, Who, How is not a consulting framework. It is a disciplined way of reading what Congress has already decided and building shared leadership understanding from that foundation rather than from assumption.

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.

This process is what defining the “what” looks like in practice. It is not a strategic planning exercise. It is a systems mapping exercise that requires the people who manage the backstage and the people who understand the frontstage to look at the same picture together and agree on what they see. The value streams that are the series of steps from statutory mandate to delivered public value become visible through that act of joint mapping. And once visible, they can be designed.

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.

This distinction matters more in federal government than almost anywhere else. Private organizations typically have a relatively clear customer: the person who pays for the product or service. Federal agencies rarely have such clarity. The taxpayer who funds the agency is often not the person who directly receives its services. The person who receives the services is rarely the person with authority over how the agency delivers them. The oversight body that holds the agency accountable is rarely the one with visibility into whether value is being delivered. Treating any one of these relationships as “the customer” produces an incomplete picture of the system. Treating all of them as integral elements in the co-creation of value, mapped explicitly and owned collectively, produces something the agency can design around.

Article 1 introduces the customer roles 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, investors, and oversight organizations in the frontstage, value stream steps sketched across the system, and the backstage functions partially identified within a single integrated system view. The boundary of the “data dissemination environment” was left deliberately undefined. The executives were asked to engage with the diagram 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 simply “work together” 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.

This pattern has proven durable across multiple engagements since. Something uniquely powerful happens when outside facilitators present their own definition of a system to the people who run it. The instincts to correct, to complete, and to defend the institutional knowledge are enablers, not obstacles, to alignment. In the right design, they are the engine of it. The facilitators’ provocation creates the condition; the group’s collective critique produces the shared understanding and alignment.

Shostack’s line of visibility is the organizing device that makes this integrated picture concrete. Consumers live in the frontstage: the touchpoints, interactions, and experiences visible to those who receive the service. Producers operate on the other side of the line of visibility: the front-line service staff and the back-end processes, systems, decisions, and infrastructure that make the frontstage possible. Approvers, both internal and external, set the conditions under which the entire system runs. Seeing all three customer categories as elements within the value stream, instead of as a separate stakeholder list attached to it, is what gives the system picture its operational usefulness.

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 it 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 shared language 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 (SDLC), 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 an incomplete view of the agency’s core process.

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 not built 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 omissions: design problems made invisible by functional structures and linear architectures, but unmistakable once the full picture is seen together.

The sessions did not produce a finished value stream design. That was not their purpose. What they produced was something more durable: a leadership team that had collectively traced the flow for the first time, corrected foundational errors in how they understood it, and surfaced insights that no amount of internal analysis could easily generate.

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.

This insight is what the customer roles work looks like in practice. Approvers are not external to the value stream. They are integral elements of it. Designing the value stream without accounting for how to effectively engage them is as incomplete as designing it without accounting for what consumers need to receive.

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, and grounded in statutory purpose, produced something that no consultant deliverable can substitute for: a leadership team that sees its enterprise together. That shared understanding is not a soft outcome. It is the hardest and most consequential thing a federal executive team can build, because everything that follows depends on it.

Organization design decisions. Technology investment priorities. Value stream definitions. Domain boundaries. Governance structures. Policy implementation decisions. None of these can be made well, or made to hold, without a leadership team that has first agreed on what the enterprise exists to deliver and who it exists to serve.

This cohesive view is what the Public Value Aperture model conveys. The six interlocking elements of Mission Domains & Strategy, Customer Insight, Organization Design, Service Delivery, Technology Enablement, and Measures are not components to design independently. They are interdependent elements of a whole, and the whole can only be designed coherently when the leadership team that owns it has done the foundational work the aperture’s first two blades require. Mission Domains & Strategy without a shared statutory foundation is just a strategy document. Customer Insight without a collectively built system picture is just a stakeholder list. The engagement described in this article builds the leadership team that can align those blades to a clear focus on value.

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 Steve Jost, one of the task force co-chairs who was 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 helped 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. Those elements are the preconditions for the harder work that follows: defining mission domains, aligning organizational structures, and building the technical architecture that makes value delivery possible at scale. 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 define and 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 describes is what makes that structural alignment possible to achieve. Without it, an aligned operating model is an architectural aspiration. With it, it is a leadership decision.