Nathan Wallace on Drupal4Gov’s Shift From Platform Questions to Governance

Federal digital-services practitioner Nathan Wallace outlines how reduced staffing and funding are changing what government Drupal teams need from Drupal4Gov. Wallace serves as a senior program and project manager at WebFirst and as president of Drupal4Gov. Allen Jason, Junior Sub-Editor at The DropTimes, conducted the conversation following Wallace’s move into the Drupal4Gov presidency.

Wallace has worked on federal digital projects for agencies including NIH, HHS, the Department of Labor, FEMA, the U.S. Mint, and the FAA, and has created Drupal.org projects including Content Governance and Digital.gov Site Scanner. He says his immediate priorities as president include operational stability, talent cultivation, and building a board pipeline for Drupal4Gov’s 2027 leadership. His answers connect those implementation concerns with wider organisational questions about sustaining year-round programmes, widening government participation, and balancing conference scope against sponsor pressure. He also describes how rolling-wave planning shaped delivery of a federal design system.

Capacity, Events, and Volunteer Ownership

TDT [1]: What are government Drupal teams asking Drupal4Gov to provide in 2026 that they were not asking for two years ago, and how has one of those needs changed the organisation’s priorities?

Nathan Wallace: A year ago, most of the questions that teams had were about the platform: how to get off Drupal 7, how to meet USWDS, or who had survived a decoupled build. In 2026, almost nothing we're asked is about the platform. It's about capacity. Federal web teams are smaller than they were, with less money to do the same amount of work, and the vendors they rely on are rebuilding after cuts. The work didn't shrink with the teams.

So the question we now get that nobody asked in 2025 is, essentially: help me govern this. Not "show me what AI can do" — they've seen that. They want to know how a two-person web team lets an automated tool touch a live page without losing control of accuracy, accessibility, and plain language.

Our own attendees pushed us there. In the open comments on our survey, not one person asked for more AI content. I don't read that as AI fatigue. I read it as a demand for real-world application. People want to hear about what actually shipped inside an agency and got it through review, not someone selling the idea of it.

TDT [2]: What constraint most shaped the format decision for Drupal GovCon 2026, and how did Drupal4Gov respond?

Nathan Wallace: Year-round revenue goals — specifically the fact that our sponsor base is largely the same firms that lost federal contracts this year. We set a target before any of that was clear, and the money came in slower than the year before.

The decision it shaped was the format. Our goal was to bring back the 3rd day of the conference. Two days would have meant fewer rooms and fewer sessions, and we modelled that seriously. We went to three, because three days does two jobs at once: it answers the attendees who told us that running training and sessions in a condensed schedule forced them to choose between them, and it gives us this year to coordinate Leadership Exchange and Global Training Day programs for 2027. We are looking to connect with state or federal agencies for our next Global training day.

TDT [3]: Outside GovCon, which part of Drupal4Gov’s work most needs sustained volunteer ownership, and what has made that ownership difficult to establish?

Nathan Wallace: The year-round programs — the webinars, the GovTech Leadership Exchange, Global Training Days. Those are the things that need someone to own them in February, not just in August. The conference doesn't have this problem; everything between conferences does.

When we ask attendees where they'd like to help, interest in the conference runs about four times higher than interest in any year-round program. That makes sense — the conference is a bounded commitment with a visible result and a clear end date. A webinar series or Leadership Exchange event is a larger commitment where the reward for doing it well is that you get to do it again next month.

We are working to define our volunteer roles by tasks so that more folks feel comfortable with the scope and commitment they need to make.

Representation, Governance, and Delivery

TDT [4]: Which government teams or professional groups are still underrepresented in Drupal4Gov, and what has the organisation changed—or failed to change—to reach them?

Nathan Wallace: Two groups, and they're related: early-career people, and — at an event called GovCon — more federal employees.

The federal number surprises people. In our survey, government employees were outnumbered by private-sector and contractor attendees combined. Government is our single largest industry slice, but it isn't a majority of the room, and the cause this year is obvious: when travel budgets and headcount get cut, the conference trip is the first thing a federal manager can't approve. We are grateful for the uptick in state and local governments’ involvement.

Early-career folks in the federal space are nearly absent at the conference— our government respondents skewed heavily senior, roughly a dozen senior attendees for every early-career one. We are focused on reaching out to junior government technologists to get them involved to maintain the pipeline.

What we've changed: we heard the content-author signal and ran more sessions for non-technical and content roles, and it worked — content managers were our second-largest group last year and asked for still more. That's a real widening beyond the developer core.

TDT [5]: In your work on embedding content-governance guidance directly in Drupal, what have you learned from editors who have used or evaluated the approach, and what evidence would you need before calling it successful?

Nathan Wallace: The premise is slightly ahead of where the work is, and that's deliberate. We've focused primarily on building a solid governance data model tailored to the agency's specific needs—starting with content categorization, defining review cycles, and assigning clear content ownership. While we’ve reached these initial milestones, we are still a ways off from fully leveraging Drupal as an internal communications hub to facilitate end-to-end content governance.

• What I've learned from observing editors and evaluating our approach so far:
  • Target pain points, not full processes: Rules-based editing needs to be highly specific to the actual workflow. Rather than trying to overhaul the entire editorial process at once, Drupal is best configured to target precise friction points to ease rollout and encourage adoption through incremental improvements.
  • Context over compliance PDFs: The failure in content governance isn't that editors don't care about standards; it's that the standards live in a separate document instead of where the work happens. Guidance, rules, and ownership metadata need to sit right where the cursor is.
  • Flexibility with tooling: We're comfortable using Drupal's native JSON-API to feed governance data directly into external dashboards if that aligns better with organizational reporting needs rather than forcing everything into Drupal UI views.
• As for what evidence I would need before calling it successful:
  • Reduced review friction: A measurable drop in review friction reported by authors and site owners because metadata and metrics (review dates, taxonomy tags, plain-language checks) were addressed inline during draft creation.
  • Data-driven accountability: Dashboards show a steady decline in stale or unowned content across the agency portfolio over 3–6 months.

TDT [6]: Can you describe a public-sector project where a fixed deadline conflicted with what the delivery team considered realistic? How did you decide what to challenge, reduce, or accept?

Nathan Wallace: Yes — the HHS Office of the Assistant Secretary for Public Affairs (ASPA) with a 21st Century IDEA milestone deadline for modernizing HHS.gov through a unified design system. The timeline was strict, but implementing a system across a massive agency is a journey, not a destination. I felt like Odysseus trying to ship components—every component touched UX, editorial, design, and Drupal, making full upfront rollouts completely unrealistic.

• What I challenged: I pushed for a Storybook-driven component development workflow to speed up visual approvals and stress test templates incrementally.
• What I reduced: Instead of waiting for all five teams to sign off simultaneously on a massive release, we pivoted to rolling-wave planning—anchoring 1–3 months of high-priority core components for near-term wins while keeping the long-term vision on course over the year.
• What I accepted: I accepted that true alignment takes longer and requires co-owning outcomes. Rather than fighting the friction across teams, I accepted that every component legitimately needs time from docs, editorial, design, and Drupal to be useful for real customers, which meant accepting a slower cadence in exchange for real organizational adoption.
• The principle I took from it: A good design system relies on product and content leadership to set the course and rolling-wave planning keeps you anchored, because building aligned teams matters far more than shipping disconnected code fast.