The 2027 Capacity Stack: What to Install Before the Next Governor Class Takes Office

Thirty-nine gubernatorial elections sit on the 2026 calendar, and roughly twenty-one incumbents are term-limited or otherwise not seeking reelection. That means at least twenty-one governors’ offices are guaranteed a transition before the 2027 governing cycle begins.

My last post was advice to incoming CIOs about what an individual leader can do in their window. This is the companion piece: what the rest of us owe those governors before they’re sworn in. Philanthropy, civic tech, the digital service movement, alumni networks, policy shops, and funders can either hand them nine disconnected pilot ideas or a coherent stack of installable capacity.

Too many states relearn the same lessons from scratch. They hire too late, procure too slowly, over-trust vendors, under-use resident feedback, miss federal funding, and treat delivery as a strategy problem when it’s actually an installation problem.

Jen Pahlka’s argument in Recoding America has been stuck in my head: better tools don’t fix government delivery. The systems and structures around those tools do. Implementation is what gets undervalued. We have tools. What we don’t have, in most states, is the operational capacity to use them.

Talent pipelines that match the work to the people who can do it
Feedback loops that put resident reality into delivery decisions
Delivery frameworks that move from project to product
Permission structures that make modern work legal and political
Peer networks that move pattern recognition across state lines

What’s Different About 2027

When we founded the Colorado Digital Service in 2019, three things weren’t true that are true now.

First, the technical landscape changed. LLM APIs are now mature enough for well-scoped, auditable triage and analysis workflows: regulatory review, document analysis, correspondence routing, benefits navigation, internal knowledge management. Standards like the Model Context Protocol (MCP) give AI-enabled applications a more consistent way to connect to tools, data, and workflows. MCP is an open standard for connecting AI applications to external systems. But in government, the hard part is never just connection. It’s authorization, privacy, auditability, service ownership, accessibility, and maintenance.

The opportunity isn’t “build civic apps without government.” The opportunity is to create secure, public-interest interfaces that let agencies, civic technologists, and residents work from the same service layer.

Second, the digital service movement grew up. In 2019, we were still arguing whether digital service teams should exist. Now we have a decade of evidence from the legacy of USDS, 18F, Presidential Innovation Fellows, Code for America, U.S. Digital Response, state services in California, Colorado, New Jersey, Georgia, and city services in dozens of places. We know what good looks like. We have alumni. We have playbooks. The question shifted from “can this work?” to “how do we install it durably?”

Third, the discourse changed. Recoding America did real work. Statecraft and Niskanen Center papers have given language to public capacity that works across ideological lines. The Ohio AI regulatory cleanup made the news. New Jersey’s unemployment insurance modernization is studied. The political cost of arguing for modern government delivery is lower than it’s been in my career.

These shifts mean the 2027 transition isn’t just another transition. It’s the first one where we can hand a governor a coherent stack and reasonably expect them to install it.

OK, the stack.

1. Double Down on the Tour-of-Service Model

Thesis: the talent problem in government is usually framed as a pay problem. It’s also a permission-structure problem.

The federal model proved this. USDS, Presidential Innovation Fellows, and 18F brought people in for defined missions, often for two-year tours, and sent them back to industry with their reputations enhanced. The pay was below market. The talent that showed up was senior and scarce. Why? Because the structure matched how technologists, designers, product leaders, and delivery people actually plan their careers. They could commit to a mission without committing to a career path.

At Colorado Digital Service, we informally borrowed the same model: two-year terms, defined deliverables, work that mattered. People across Colorado from important tech companies like Twilio, Pivotal, Google, and others raised their hand offering to help.

What states need before inauguration:

Authority: executive order, special hiring authority, or another legal mechanism to create tour-of-service roles outside normal classification.
Funding: a four-person cadre costs roughly $800K to $1M annually all-in. That’s small in a state budget but a real ask for a governor’s office.
Mission scoping: vague missions kill tours of service. “Modernize unemployment intake,” “launch paid family leave,” or “ship the licensing portal” works. “Help with digital transformation” doesn’t.
Build alumni infrastructure. Make public service a resume enhancer.

2. Invest in Resident Voice Infrastructure

Thesis: most government delivery is built on what staff assume residents want.

The People Say offers a useful model: a qualitative database designed to help policymakers hear directly from the public when shaping policy. Today it focuses on older adults and caregivers and is a collaboration between the Public Policy Lab and The SCAN Foundation. The 2027 opportunity is to adapt that model to state delivery domains: benefits, licensing, workforce, childcare, tax, permitting, and health.

The technical idea is straightforward. Structured qualitative research at scale, with stories tagged by domain, demographic, life event, service journey, and pain point. A team working on workforce benefits can hear from people who actually applied. A team designing a licensing portal can hear from residents who got stuck. A team modernizing childcare benefits can see how the same family navigated eligibility, documentation, language, and timing across programs.

Every delivery team has a backlog. Every backlog gets prioritized somehow. Right now, in most agencies, prioritization is dominated by statutory deadlines, vendor proposals, compliance anxiety, and internal politics. Resident voice gives product managers a competing input. It changes the meeting. It’s a key input into any Product Ops flow.

Why this scales:

Stories have long shelf life.
Patterns compound across domains.
Marginal cost falls as tooling and methods mature.
Resident input creates legitimacy if consent, privacy, and reuse are handled well.

3. Bring Back Brigades, or the Civic Tech Distribution Channel by Another Name

When we founded Colorado Digital Service, the Denver Code for America brigade was one of our recruiting sources and a great group of folks to talk with about our plans for the team. People came to brigade events because they wanted to do civic work.

In the years since, brigades have weakened. Code for America itself changed its formal relationship with brigades, and many local groups had to rethink sustainability, funding, and affiliation. Branding matters less than function. What’s been lost is the local civic tech distribution channel where energy concentrates and talent finds its way into public work.

What’s different now:

Open datasets are more common.
Open source is no longer exotic in government.
Standards like MCP and adjacent patterns are lowering integration friction.
AI has made small teams dramatically more productive.
The alumni network from digital service work is large enough to seed local ecosystems.

But the rebuilt brigade shouldn’t be a hackathon factory. It should be a maintainer network.

The goal is persistent civic infrastructure: open-source components, documented APIs, service journey testing, agency-adjacent prototypes, local delivery research, and talent pipelines into public roles. The best projects should have maintainers, agency relationships, and a path to adoption or graceful retirement.

Failure mode to avoid: recreating volunteer organizations that build throwaway apps no one owns. The new civic tech channel should concentrate energy, create relationships, and move talent into the stack.

4. Run Workshops That Create Permission Structures

In 2017, Robin Carnahan and Waldo Jaquith came to Colorado on GSA 10x funding. They ran workshops on agile delivery and procurement reform. Legislators came. Agency heads came. CIO staff came.

Watch Waldo’s famous testimony to the Michigan State Legislature.

What changed because of those workshops in Colorado?

The legislature started asking agency directors better questions about IT projects. Their oversight tightened. CDS got political cover to experiment with procurement. Agencies got political cover to try iterative delivery. Shared language emerged. “Modular procurement” stopped being jargon and became a thing the budget director could ask about.

That’s permission-structure work. Workshops are an unreasonably effective way to do it because they change what powerful people know how to ask for.

The 2027 playbook should include workshop bundles for new governor transitions:

Agile delivery and the difference between project and product
Modern procurement, modular contracting, and outcome-based solicitations
How to read a technical proposal and ask vendors the right questions
Case studies from Colorado, New Jersey, Ohio, Pennsylvania, and other states

These should be free to transition teams and delivered by practitioners with skin in the game. This may be the highest-leverage workshop work we can do, and it’s astonishingly underfunded relative to its impact.

5. Publish the Salary Reallocation Playbook

I have not actually run this play myself, but it’s one of my favorite ideas here.

The problem is simple. State IT positions are often classified around $75K to $130K. Market rate for the senior engineers, product managers, designers, data leads, security specialists, and delivery leaders we need is often much higher.

But there’s a move many agency heads may already have, or can request, authority to make: combine vacant positions within a functional area to fund a higher-paid single position, holding total appropriation flat.

Example:

Before: two vacant IT classifications at $130K each, unfilled for 14 months.
After: one senior product or engineering role at $200K, tied to a named mission.
Fiscal impact: appropriation stays flat.
Operational impact: the agency gets one senior person it can actually hire instead of two mid-level positions it can’t fill.

Steps to actually pull this off:

Legal review and authority templates for each state
Classification rewrites for senior engineer, product manager, designer, security lead, data lead, and delivery manager
Talking points for the budget office, legislature, public employee unions, and press
Failure-mode mitigations for union objections, legislative pushback, and classification disputes

Every state that adopts this potentially unlocks better hiring without needing a new appropriation.

6. Build Federal Funding Optimization Tooling

In Colorado, the Office of Federal Funds and Strategic Initiatives is a small team with an oversized return. Its mission is simple: track federal funding opportunities, match them to agency needs, help agencies apply, and optimize drawdown.

Without this capacity, states miss discretionary grants, matching programs, and implementation funding. They also miss the intelligence layer: which grants are worth chasing, which agencies are ready, which matches are feasible, and which federal opportunities align with the governor’s delivery agenda.

The chicken-and-egg problem is real. A state without a federal funds office often doesn’t have the budget for one. External seed funding can break that loop.

Steps:

Seed funding for a one- or two-person federal funds office in any incoming governor state that wants it
Shared infrastructure: a federal opportunities tracker scanning grants.gov, agency announcements, and relevant federal updates
A peer network of state federal funds officers
Training on federal application and drawdown workflows

After 24 months, many states should be able to fund the office from the federal capture it helped generate. The seed is finite. The return compounds.

7. Open-Source AI Regulatory Cleanup

State regulatory codes are archaeological sites: references to defunct agencies, expired sunset clauses, contradictions between newer statutes and older regulations, broken cross-references, and definitions of “modern technology” that name obsolete tools.

Ohio’s AI-assisted regulatory cleanup showed why this is politically interesting. Reporting described AI helping identify outdated or redundant parts of Ohio law and regulation, with human review built into the process, and the state has said the tool removed more than two million words and rescinded nearly 900 rules from its administrative code.

What the tool does:

Ingests a state’s digital regulatory code
Flags temporal markers, expired authorities, and obsolete provisions
Finds broken cross-references and references to defunct agencies
Identifies duplicate or overlapping provisions
Routes every flag to subject matter experts before any recommendation advances

The workflow matters more than the model. Every flag should be traceable to the regulation, prompt, source text, and review path. Every recommendation should show which human reviewed it and when.

The political framing also matters. This isn’t AI making policy decisions. It’s AI surfacing candidates for human review. That makes it useful to conservatives who want procedural cleanup and to liberals who want transparency, auditability, and better administrative maintenance.

8. New Gov Onboarding

An integrated offering for an incoming 2027 governor could look like this:

Pre-inauguration: workshop bundle for transition team, agency heads, CIO staff, budget staff, and legislative leaders
First 30 days: authority templates for tour-of-service hiring
First 90 days: seed a four- to six-person delivery team using tour-of-service authority
First 180 days: launch federal funds capacity and connect to the shared opportunities tracker
First year: adopt the salary reallocation playbook, activate local civic tech infrastructure, and plug into resident voice infrastructure
Year one and beyond: run an open-source regulatory cleanup pilot and foster an “ambassador network”

9. Create an Ambassador Program

This last idea came from a Claude webinar I joined today, focused on AI in state and local government, in which they encouraged folks to join the “Claude Ambassador Program“.

An ambassador program would be a state-specific network of technologists, civic tech alumni, government delivery experts, procurement reformers, product leaders, designers, data leads, and policy operators recruited explicitly to “give first” and help agencies. This is very similar to the incredible Techstars mentor network that was born here in Boulder, CO.

Steps:

Recruit from USDS, CDS, 18F, PIF, Code for America, U.S. Digital Response, state digital services, civic tech companies, and government alumni
Tag expertise by domain: health, workforce, benefits, licensing, procurement, hiring, data, security, AI, and product operations
Maintain light infrastructure: directory, office hours, shared Slack, and a matchmaking function
Add trust rules: conflict disclosures, confidentiality norms, and a clear line between peer support and sales

The point isn’t just helping individual leaders. It’s transferring pattern recognition across state lines. The mistakes Colorado made in 2019 don’t need to be made in Virginia in 2027. The wins California had in 2024 should propagate to North Carolina in 2027. Ambassadors can help.

What Could Break the Stack

This only works if we’re honest about failure modes.

A governor’s office can like the idea and fail to assign an owner. Philanthropy can fund pilots and ignore maintenance. Digital service hires can arrive without procurement, budget, or legal authority. Resident voice can become performative research instead of backlog input. AI cleanup can become a political stunt instead of auditable legal triage. Brigades can rebuild volunteer energy without sustained maintainership. An ambassador network can become advice without accountability.

Every one of those failures is predictable. That means every one can be designed against.

The stack needs owners, maintenance funding, authority, governance, trust rules, and a bias toward boring implementation.

Especially the boring parts.

Good Luck to the new Govs!

As I was researching and writing this post, I used OpenAI Codex to build a visualization to help folks understand differences across state governments and identify opportunities for capacity building. I used Perplexity AI to source data from state websites and Anthropic Claude to help me polish the blog post.

View the State Government Insights Dashboard and the supporting GitHub repository here.

The greens, blues and black diamonds of Health Data Interoperability

If you’re starting your first job as a software engineer, designer, or product manager in healthcare, welcome. Truly. We need you.

🟢 Greens: Beginner

When you’re new to healthcare, there are a few things you’ll quickly get up to speed on, including types of health data and data privacy.

Types of health data

Start with the basics: the core categories of clinical data.

A doctor visit → Encounter
A blood draw → Lab
An X-ray → Radiology report + image
A medication → Med list entry
A blood pressure reading → Vital

Same patient. Same event. Data ends up in different systems depending on the EHR, lab machine, imaging vendor, or workflow.

When you go to the doctor because your knee is unusually sore after a few days on the slopes, the provider is going to ask you questions about how you’re feeling. You may have your blood pressure measured, height and weight recorded, etc. All of this is going into the Electronic Medical Record software they use, which is why the provider is using a laptop and typing. If you have blood drawn, the sample will go to a lab, and the results will be stored in the lab’s software, sent back to the provider, and likely automatically stored in the EMR. If you get an X-ray, the results are stored in the X-ray machine’s software and may or may not be automatically stored in the EMR.

This is your first lesson in interoperability:

Clinical reality is simple; data reality is not.

Your job at this stage is to understand what the data represents, where it lives, and why systems disagree about the “source of truth.”

Data privacy

One of the first things you’ll experience in your first week is HIPAA training. It feels routine until you first see real patient data. A diagnosis. A lab result. A radiology report.

At that moment, something shifts.

You realize you’re being trusted with the most intimate data a human being has. This isn’t “a schema.” It’s someone’s life. And that responsibility will shape the rest of your career.

Also, remember that “the P in HIPAA stands for Portability.” Beyond data privacy, HIPAA addresses health data interoperability and patients’ access to their personal health information. PACS systems, and more.

🟦 Blues: Intermediate

I think of this level as gaining an understanding of APIs, agents, web scrapers, and the real healthcare software ecosystem, and how to retrieve data from EMRs, billing systems, PACS, and more.

Once you understand the data, you begin to understand why it doesn’t move easily.

This is the messy middle:

FHIR APIs (powerful but inconsistent)
Vendor APIs (Epic, Cerner, Athena, payer portals)
Scrapers + agents (still everywhere because… reality)
Release of Information (ROI) workflows (the backbone no one wants to talk about)
Manual queues, PDFs, faxes (yes, still)

And you begin to see the ecosystem:

Providers create and store data
Payers request and evaluate data
Patients want control of their data
HIEs, clearinghouses, and networks move data
Vendors create their own micro-walled gardens

Interoperability is rarely a technical problem. It’s an incentives problem.

◆ Black Diamond: Expert

This is when policy, standards, and the actual shaping of the future of healthcare are closely intertwined with your day-to-day job.

You begin to see how CMS, ONC/ASTP, and OCR shape the data landscape, payment models, API certification, information blocking, privacy enforcement, and more.

You learn how standards actually get made:

HL7 workgroups
FHIR Implementation Guides
Da Vinci, Argonaut, CARIN
CMS Interoperability Framework
The stakeholders that show up in the room (and the ones who don’t)

You understand TEFCA, QHINs, and the meaning of “exchange purposes” in the context of nationwide data flow.

And you start asking different questions:

How should clinical data move in the U.S.?
Where should policy intervene vs. where should technology evolve?
What incentives will finally align interoperability with patient needs?

At this level, you’re helping shape the future, which is pretty darn cool.

⛷️ Good Luck, you’ve got this!

Keep Reading

Nine years ago, I wrote a post titled “The First 90 Days for a Product Manager New To Healthcare”.

The First 90 Days for a Product Manager New To Healthcare

It’s fun to look back on that now and reflect on what’s mostly the same and the big improvements.

Below is a short reading list I often share with people who are new to health data or interoperability, or who are trying to understand why everything still feels so… harder than it should be.

1. The Fragmentation of Health Data — Travis May (Datavant)

🔗 https://medium.com/datavant/the-fragmentation-of-health-data-8fa708109e13

A big-picture walkthrough of where health data comes from, why it splinters instantly, and what it takes to stitch it back together.

2. The Graveyard of Interoperability Initiatives — Travis May

🔗 https://travismay.medium.com/the-graveyard-of-interoperability-initiatives-in-the-past-how-we-can-drive-the-future-5ff3ec1f1a12

A look at decades of “this time interoperability will work!” attempts—and an honest take on what has to change for it to finally stick.

3. The Health API Landscape — Arjun Sethi (a16z)

🔗 https://a16z.com/2017/04/05/health-api-landscape/

A tour of the early API companies that started loosening the grip of legacy EHRs and helped health data move a little more freely.

4. Why the Fax Machine Still Rules American Healthcare — Sarah Kliff (Vox)

🔗 https://www.vox.com/health-care/2017/10/30/16228054/american-medical-system-fax-machines-why

The classic explainer for why healthcare still leans on fax machines—part technology gap, part incentives, part “it’s how we’ve always done it.”

5. The New Rules of Healthcare APIs — Kibbe & Kuraitis

🔗 https://thehealthcareblog.com/blog/2014/12/04/the-new-rules-of-healthcare-apis/

A foundational argument that APIs (and standards like FHIR) change the game by letting systems talk to each other without hand-built integrations.

More if you want to keep going:

6. A Common-Sense Guide to Health Data Interoperability — ONC/HHS

🔗 https://www.healthit.gov/topic/interoperability

A straightforward introduction to what interoperability actually means—beyond the buzzword.

7. The Case for a Health Data Utility — Civitas Networks for Health

🔗 https://www.civitasforhealth.org/insights/the-case-for-a-health-data-utility/

Makes the case for treating health data infrastructure like a utility: shared, reliable, and built to serve everyone.

8. Why Is It So Hard to Share Health Data? — Kaiser Health News

🔗 https://kffhealthnews.org/news/why-is-it-so-hard-to-share-health-data/

A simple, human-centered explanation of the legal, technical, and business friction that keeps data stuck.

9. FHIR Is Not Magic — Grahame Grieve

🔗 https://www.healthintersections.com.au/?p=2944

A gentle reality check from the creator of FHIR on what the standard solves—and what it doesn’t.

10. The Future of Accessing Your Health Data — Travis May

🔗 https://travismay.medium.com/the-future-of-accessing-your-health-data-e2624e63bdd8

A hopeful look at what health data access could be if we build the right pipes, policies, and incentives.

Advice to Incoming Government CIOs

Image of founder fathers building software

Building the Capacity You’ll Need

As we head into the 2026 midterm cycle, we’ll see dozens of governorships turn over, new mayors sworn in, and a wave of transitions in state and local IT organizations. For the incoming CIOs, CTOs, and digital service leads, this moment brings a rare kind of opportunity. You’ll inherit legacy systems, legacy contracts, and legacy decisions, but you’ll also inherit a public that expects government technology to work as well as the apps in their pocket.

This is written for those stepping into those roles. I hope it offers a practical view of what really matters in your first year, and how you can build the state capacity to deliver for residents.

Make Policy Reform Part of Your Delivery Toolbox

State and local policies shape everything you will be able to do: hiring rules, job classifications, procurement authority, interpretations of federal guidelines, budget structures written for a pre-internet era. In Colorado, when we started the Colorado Digital Service, we couldn’t hire anyone who lived outside the state. Our job descriptions needed updating, and the budget process was geared toward projects with a start and end, not products that need continuous improvement for years. All of these constraints shape delivery far more than any platform decision ever will.

Incoming CIOs have a unique window to push for reform:
• Hiring and HR modernization: Can you hire remote staff? Can you bring in short-term experts? Can you compensate for modern skills?
• Procurement flexibility: Modular contracting, outcome-based solicitations, pilots before full commitments.
• Budget structures: Moving away from multi-year waterfall appropriations toward funding that supports continuous delivery.
• Federal interpretation: Many “rules” are simply norms. States that ask federal partners for flexibility often get it.

As Jen Pahlka said in her discussion with Sam Hammond, “When we burden public servants, we don’t relieve burden on the public.” Fixing the policy scaffolding around delivery is the best way to reduce that burden.

Take the Long View

Government doesn’t build for quarters or for annual OKRs. It builds for decades. The systems you shepherd today may still be running when your children are grown. Someone will inherit them just as you’re inheriting what came before you.

Adopting a long-view mindset changes how you lead:
• Instrument everything. If you can’t measure it, you can’t improve it. Build observability into every service such as uptime, latency, abandon rate, and user pathways/funnels.
• Center the user journey. Residents don’t experience agencies. They experience a life event like applying for childcare, renewing a license, or seeking housing support. Build around that reality.
• Continuously deploy. Policy changes and bugs happen. Focus your delivery teams on the basics like shipping a text change or a line of code. Make sure this is perfect.
• Leave things better documented than you found them. Future teams shouldn’t have to rediscover the map of your systems.

You don’t need to be the CIO who solves everything. You need to be the CIO who ensures the next team can keep building without starting from zero.

Build State Capacity

Real capacity is structural. It comes from three places, none of which involve publishing another strategy document.

Build or strengthen your digital service team

Digital service teams bring modern product, design, and engineering talent into government. They sit close to the work and act as translators between agencies, vendors, and policy staff. They augment your delivery teams ability to understand contractor proposals, guide architecture decisions, and be a smart buyer.

When we built the Colorado Digital Service, we saw firsthand how many people in the region wanted to serve, they just needed an entry point into government that was more familiar. You can create that entry point. Read more about that here.

Work across states — because your problems aren’t unique

Your challenges aren’t new, and they aren’t unique. Whether through health information exchanges, multi-state collaboratives, NASCIO, or informal networks of CIOs sharing what actually works, you can borrow patterns that others have already tested.

The Software Collaborative is one of my favorite concepts.

Partner with organizations already built to help you

Code for America, U.S. Digital Response, Beeck Center, Schmidt Futures, National Governors Association, Recoding America Fund, and academic partners…there’s an entire ecosystem around you. But collaboration only works when it’s structured as real shared work.

Round tables and being on panels at conferences is great, but how can your teams actually roll up their sleeves and collaborate deeply with these orgs? Give your internal team explicit permission and mechanisms to collaborate: shared GitHub repos, co-designed sprints, open technical roadmaps. Don’t just talk about partnership, enable it. We did this during COVID at every level of government and it can be done again.

Modernize HR

You can have the best strategy in the world, but if your only hiring path is outdated job descriptions, low salary bands, rigid classifications, and in-state requirements, you won’t be able to hire the talent you need.

Capacity is people. If you want to deliver modern services, you need modern hiring.

Tie Your Work to Resident Outcomes

CIO conversations often drift toward cloud migration strategies, cybersecurity frameworks, shared platforms, and enterprise architecture. All important. None of them matter unless they connect to the experience of real people.

Anchor your work in questions like:
• Did a resident access a benefit faster?
• Did a worker’s administrative burden decrease?
• Did an agency get the ability to release data safely instead of emailing spreadsheets?
• Did dollars move from overhead to direct public service?

This is the language governors, legislators, and agency heads understand. It’s also the language that earns you the political capital to fix deeper structural issues.

Know the Power, and Limits, of Your Role

You won’t fix every legacy system. You won’t solve every procurement bottleneck. You won’t modernize every program in your turn to run with the baton.

But you can fix the conditions that determine whether your teams can deliver:
• You can modernize hiring and classification.
• You can reshape procurement.
• You can create a digital service team with real authority.
• You can standardize modular, iterative delivery.
• You can document the system and leave it better for the next team.
• You can help your government org interpret federal requirements with more flexibility.

If you do those things, you will have built real capacity, not just for your tenure, but for the teams and leaders who follow.

And residents, especially those who rely most on public services, will feel the change.

Good Luck to the new Mayors!

(Originally posted Aug, 2023)

With nine new Mayors taking office this year representing cities with the largest populations and countless others across the country representing smaller towns and mid-sized cities, it’s a good time to think about how these new administrations can approach technology.

With such large technology portfolios that span transportation, permitting, healthcare, public safety, and much more, a new Mayor and their CIO, CTO, and leadership team can create an environment whereby the Government is held accountable for designing and delivering services with a focus on the actual experience of the people whom it is meant to serve.

Within the first 100 days, new Mayors can:

Issue an Executive Order directing agencies to prioritize Customer Experience (CX)
Define five “Life Experiences” such as “Approaching Retirement” or “Facing Financial Shock” and direct agencies to deliver strategies and playbooks on working together to achieve related goals
Create a new Digital Service, a small team of highly-talented technologists that serve a one to two-year “digital tour of service” to focus on the Mayor’s top three priorities

Within the first year, new Mayors can:

Invest in user experience design and research talent and processes that will contribute to better service design
Create agile vendor pools that will lower costs and increase competition for the technology products and services the city purchases
Build a talent pipeline of technologists, junior and senior, specifically product managers, UX practitioners, and cybersecurity experts
Invest in a zero-trust security model and evangelize for security best practices across all horizons of the application development lifecycle

To succeed in service delivery, new Mayors and their teams must consider the customer journey of the people they serve. For example, in Colorado, nearly 20% of residents are covered by Medicaid. Medicaid is a Federally-funded program with a diverse ecosystem of local partners that deliver services to City and County of Denver residents. The City must take an active role to ensure appropriate health data information is being shared across various levels of government as needed and foster a culture of listening, user research, and service design that can best support the work of all of our government and non-profit partners.

To understand if the delivery of a service is working for the people, instrumentation, monitoring, and observability are critical. Teams in charge of services should have a deep background in audience metrics, funnel analysis, conversions, and more. Using quantitative product metrics combined with qualitative user research is how delivery teams build empathy for their users and iterate toward the product/market fit needed to serve residents best.

Building a culture focused on impact and outcomes is incredibly important for a new Mayor, especially within their technology portfolio. Formal techniques can be helpful such as OKRs to guide teams or prompt product managers to use the phrase “as measured by” after describing the impact a feature or change will have on users. I have seen both approaches work well.

I wish this new class of Mayors the best of luck and know there is a community of technologists at all levels of government, non-profits, and tech companies that are always there to help improve the delivery of services in the communities they love. Please don’t hesitate to reach out to us!

Keep Reading:

City of Boston’s Five-Year Strategic Plan

US Digital Response – helps local governments with service delivery

Launching a Digital Service

Future of Infrastructure podcast

Recoding America by Jennifer Pahlka – required reading for government CIOs and delivery teams

Product Management & Delivery Frameworks: My Go-To Books

Thinking about software delivery cadences, team styles, and what frameworks work best for teams is one of the many, many, many parts of being a Product Manager.

“How much process do you need? As much as you need to get the job done — but only as much.”
— David Allen, Getting Things Done

In large organizations, process often serves as connective tissue. When you have dozens of teams shipping across product lines or a portfolio, cadence becomes a form of language. Weekly sprints, quarterly planning, or six-week program increments give everyone a shared sense of rhythm. The marketing team knows when a feature might land, executives can see what’s in flight, and delivery teams can make tradeoffs without blocking other teams.

But process alone doesn’t build trust or velocity. The best teams I’ve worked with have enough rhythm to create predictability and shared accountability, but they leave plenty of room for autonomy and experimentation. They understand the “handshake” between product and engineering: business leaders define why and what we’re solving, and technical product teams own the how, the architecture, scalability, and delivery details that make it real.

But it’s never quite as simple as that of course.

Over time, I’ve learned that transformation isn’t about installing a new framework, it’s about cultivating clarity and confidence across disciplines. A great cadence helps product owners, engineers, designers, and execs move in sync.

If you’re thinking about how your team works, or why your current framework feels off, and need some inspiration, try these books.

The Phoenix Project: a novel that captures how invisible work, broken communication, and misaligned incentives sink delivery. People seem to love or hate this book, but I find myself still turning to it for motivation from time to time.

Ask Your Developer: a reminder that agile teams thrive when engineers are trusted to shape solutions, not just implement them. Jeff Lawson captures what real collaboration between product and engineering looks like—it’s probably my most recommended book to work friends.

Shape Up: an antidote to endless sprints, with a model for giving teams clarity and boundaries without micromanagement. I have followed the 37 Signals team for twenty years and still find Jason and David’s constantly evolving approach to delivering software very important to my own thinking.

The Year-Round Ski Pass

Mountain Capital Partners has published a list of capital improvements for the next ski season.

https://www.mcp.ski/resort-investments-2025

Notable in this press release is their continued effort to make mountain passes a year-round lifestyle membership, not just a ski ticket.

Adding golf and bike park access isn’t just a perk. It’s a revenue strategy. Predictable cash flow, lower weather risk, and deeper loyalty.

Vail Resorts’ recent earnings report highlights the challenge: weather-driven revenue fluctuations are unsustainable. Alterra’s expansion into four-season operations points to the same reality.

MCP is smaller, but they’re playing a smart hand. Betting on the lifestyle, not just the season.

I’d watch this space closely. The next competitive edge in the mountains won’t just be who has the best snow days — it’ll be who owns the full calendar.

🔗 Mountain Capital Partners 2025: https://www.mcp.ski/resort-investments-2025

🔗 Vail Resorts Q2 Earnings: https://investors.vailresorts.com/news-releases/news-release-details/vail-resorts-reports-fiscal-2025-second-quarter-results-and

🔗 Alterra News: https://www.alterramtn.co/news

Environmental Permitting

On April 15th 2025, this Updating Permitting Technology for the 21st Century Executive Order was signed.

The new directive pushes agencies to ditch paper forms, speed things up with better tech, and make the whole process more transparent. It also asks the Council on Environmental Quality to create a tech roadmap for a shared system across agencies. The goal? Cut red tape, make smarter decisions, and keep projects moving without sacrificing environmental protections.

I had a chance to spend a year with the Council on Environmental Quality (CEQ) to better understand the technology landscape and bureaucratic hurdles that cause so many of the delays on our large infrastructure projects in the United States.

This explainer video from the WSJ details the SunZia wind farm project, a $11B renewable energy initiative that will deliver 3.5 GW of wind power from New Mexico to Arizona and California via a 550-mile transmission line. Set to finish in 2026, it will power 3 million homes and boost clean energy access across the western U.S.

I love this problem space because it combines emerging technologies such as drones, sensors, AI, and satellite imagery with decades-old problems of federal, state, and local government collaboration (think case management and document sharing).

If you want to go deeper, check out “Abundance” by Ezra Klein and Derek Thompson, and “Why Nothing Works” by Mark J. Dunkelman. These books cite numerous examples of infrastructure projects that take forever or fail, and will help you understand how we have reached this moment in the United States.

Keep reading:

What is NEPA? NEPA stands for the National Environmental Policy Act, a U.S. environmental law enacted in 1970. It mandates that federal agencies assess the environmental impact of their actions and decisions before making them.

The “Permitting Dashboard” displays a list of large infrastructure projects in the United States.

Arrow Canyon Solar Project – an example of a public comment form.

AI in all levels of Government

OpenAI generated image of government IT workers in future setting

There are 3,144 counties and 55 states and territories in the United States, encompassing 19,500 incorporated cities, towns, and villages. Of those, 14,768 have populations below 5,000. Only ten have populations above one million, and none are above 10 million. 310 cities are considered at least medium cities with populations of 100,000 or more.

127 million people, about 40% of the U.S. population, lived in cities with 50,000 or more residents.

There are 574 federally recognized tribal governments and 326 Indian reservations in the United States, and Native Americans have a population of approximately 10M or 2.9% of the total U.S. population.

In addition to state and local governments (SLED), there are 438 federal agencies and subagencies.

We all want the same outcomes: a thriving and safe community, the happiness of our neighbors, and responsible, competent management from our government.

By applying AI to certain problems, governments can lower costs through automation, provide more valuable information to residents, reduce fraud, enhance public safety, and so much more.

To do this, governments must procure off-the-shelf solutions or build custom software. These teams will comprise AI ethicists, policy wonks, product managers, user experience designers, and software engineers.

To understand how federal agencies think about AI, you can dig deeper into this inventory of thousands of use cases aggregated from most agencies.

Federal AI Use Case Inventory

Five Key Emerging Technologies Revolutionizing the Ski Industry

We are deep into the 2024-25 ski season here in Colorado and I’ve been peering around the corner thinking about what emerging technologies will impact the ski industry over the next few years.

The ski industry is rapidly evolving, integrating cutting-edge technologies to enhance safety, efficiency, and accessibility. From wearable tech to automation, these innovations are shaping the future of skiing.

Here are five key emerging technologies transforming the industry.

1. Wearable Technologies for Comfort & Safety

One of the most significant advancements in ski technology is the rise of wearable devices like the Carv app, which provides real-time digital coaching, helping skiers improve technique and reduce injury risk. Other wearables include Avalanche Airbags and Recco Reflectors, which assist in search and rescue operations. Smart helmets with built-in communication and impact sensors further enhance skier safety, ensuring quick response in case of an accident.

2. Exoskeletons for Assistive Skiing

Aging skiers and those with physical limitations can benefit from exoskeletons, such as those developed by Roam Robotics. These powered assistive devices reduce strain on the knees and muscles, enabling more people to enjoy skiing longer. Exoskeletons provide real-time adaptive support, increasing endurance and preventing fatigue-related injuries.

At CES this year, we also saw innovations from companies like e-Skimo, an electric-powered ski.

3. Process Automation for Ski Resort Operations

Automation is playing a crucial role in making ski resorts more efficient. Automated ticketing systems, dynamic lift scheduling, and AI-driven snow management are streamlining operations while reducing costs. For example, smart lift pass technology powered by Bluetooth low energy minimizes wait times, while AI-powered weather forecasting optimizes snowmaking, ensuring ideal conditions with minimal environmental impact.

4. Robotics Enhancing Efficiency & Cost Reduction

Resorts are integrating robotics for various tasks, from autonomous grooming machines maintaining slopes to robotic food and beverage service, improving guest experiences. AI-powered drones are also used for avalanche monitoring and slope assessments, enhancing safety for skiers and resort personnel.

5. Innovation in Year-Round & Global Ski Tourism

With climate change impacting snowfall, resorts are turning to synthetic snow technologies and indoor ski domes to extend the ski season. Advanced snow generation and energy-efficient cooling systems allow skiing in warmer climates, expanding the sport’s reach beyond traditional alpine regions.

These technologies are revolutionizing the ski industry, making it safer, more accessible, and more efficient. Whether through wearable tech, robotics, or automation, the future of skiing is being shaped by innovation.

Legislation + Product Management

It’s been five years since I first scrubbed in and started working on government problems. One of my early impactful experiences after moving to DC for a year in 2017 was taking a walk next to the White House with my friend Natalie and talking about the 21st Century Cures Act. In that huge piece of legislation, the words “Application Programming Interfaces (APIs)” are referenced a handful of times, a very important signal for government agencies and the healthcare industry to progress into a more interoperable existence. At that time, I didn’t have a clue about policy-making, the legislative process or regulation but soon came to understand the intersection of policy and product management is a fascinating place to work for a product manager and a core product muscle to develop.

In this space where policy and product meet, a product manager can find themselves helping write policy, implement policy or being subject to policy.

Examples:

Writing policy – helping advise policymakers at a Federal agency, Congress or State Legislature on specific technical things or approaches. Ex: CMS Interoperability and Patient Access Rule
Implementing policy – building software, websites and new teams to help a government agency implement some new legislation or regulation. Ex: Medicaid member experience, Paid Family and Medical Leave, Unemployment Insurance, the Bipartisan Infrastructure Bill, etc.
Subject to policy – designing new product features for your business based on opportunities or requirements policy creates. Health data interoperability, privacy, crypto regulation, grant funding opportunities, etc.

For this post, let’s focus on Implementing policy.

How a Product Manager should think about Implementing Policy

Today, big pieces are legislation are treated as requirements documents in which different requirements are usually delegated out to various government agencies to implement. For example, in the recently enacted Infrastructure Investment and Jobs Act (IIJA), there are approximately 14 agencies responsible for 375 programs that will carry out provisions of the bill.

But…before going into implementing legislation as a product manager, a quick primer on the structure of legislation like the Infrastructure Investment and Jobs Act (IIJA).

The Structure of Legislation

The legislation is called an “Act”. Within the Act, there are divisions, titles and subtitles that have many sections.

Each of these sections can have highly prescriptive or super vague direction. For example, on page 1182 of the Infrastructure Investment and Jobs Act (IIJA) you’ll find a specific definition of “reliable broadband service”.

Often times, legislation is prescriptive as to how it should be implemented once passed. For example, the Colorado Paid Family and Medical Leave Insurance Act defines a new division be created within the Colorado Department of Labor and Employment to run the new program.

For the Infrastructure Investment and Jobs Act (IIJA), an Executive Order immediately followed the passage of the bill which established a Task Force.

The process sometimes feels more like art than science and can vary widely across levels of government and the type of policy being created. For example, in both Federal and state governments, the legislature (Congress) makes laws but federal and state agencies can create regulation. To further codify how a piece of legislation should be implemented, the Office of Management and Budget (OMB) may issue guidance to agencies that have “statutory responsibilities”. As you can see from this IIJA guidance from OMB, it further defines how everyone should coordinate with each other across government.

Products created by Legislation

Ok, now that you have a sense of the structure of a big piece of legislation, let’s talk about the products the signing of a new bill or publishing of a new regulation may hatch.

Imagine you are a product manager in the government tapped to work on implementing a new policy. Not unlike most products you’ve likely worked on, there is some type of vision or high-level goals (probably spelled out in the legislative text) and will likely need a website, community building, customer success and internal dashboards.

Website(s)

A piece of legislation and accompanying guidance will likely have a lifespan of a decade or longer. During these many years, state and local governments, territories, Tribal nations, non-profits, businesses, media and others will be learning about the bill. It is important to establish a source of truth for ongoing communication about the bill as the legislative text, once passed, is static on congress.gov.

For example, for Infrastructure Investment and Jobs Act (IIJA), the website Build.gov was created to provide a home for information about the programs that span infrastructure themes such as broadband, water and transportation. A PDF guidebook was also created that summarizes each of the programs. This website is just one web property in an ecosystem that includes:

Build.gov – summarizes the Infrastructure Investment and Jobs Act (IIJA), PDF guidebook, searchable program inventory.
Grants.gov – the application process for many of the grant programs funded by IIJA.
Agency Program webpages – program specific information including application eligibility, notice of funding opportunities (NOFOs) and technical assistance. Ex: Bus and Bus Facilities Program from the Federal Transit Administration (FTA).
Sam.gov – detailed information about each program (call an “assistance listing” in grant-speak).

Along with websites, as a PM you’ll be engaging with secondary sources of information, typically local and national media coverage as well as webinars, infographics and white papers put out by hundreds of associations and consulting or lobbying firms.

OKRs and Dashboards

A variety of data products such as dashboards, shared datasets and more are required to coordinate across agencies and manage a large piece of legislation effectively.

Usually, in artifacts that support the legislation or in the bill text itself, you’ll find some type of guidance or direction about how outcomes and impact should be measured. For example, in the IIJA Executive Order, priorities were defined. This means there also needs to be a way to measure and report on these priorities…which means data and dashboards.

Beyond using data to inform decision-making of the policy implementation, oversight needs to be considered from day one. Reports to Congress and readouts with stakeholders are important for PMs to consider.

(Map showing bipartisan infrastructure bill funding)

Web apps

For legislation that directs funding, usually to state, local, territorial and Tribal governments or non-profits, some type of reporting from those entities back to the Federal government is required, which means you’re likely building a web app. As conditions change, these reporting and compliance requirements also evolve. As a PM, you need to be thinking about a reporting and compliance user experience that is easy for funding recipients. As I’ve talked with folks in all levels of government about grant funding specifically, reporting and compliance burden is always a complaint, especially for small governments without big teams to handle this.

Web apps to support legislation are tricky because many of them have been built in the past to support a variety of different types of legislation and the user experiences have been less than great. So, as a PM, you need to embrace the learnings from these teams and try and avoid building the next web app that most users don’t really like.

Another category of web apps you may find yourself building as a PM helping to launch new legislation are web apps that support some type of functionality required by the policy. In this example, the Quality Payments Program from the Centers for Medicare and Medicaid Services (CMS) supports regulation that requires healthcare providers to upload information via a website or integrate with an API.

Delivery Teams

New policy usually means new delivery teams are needed to build the websites, dashboards and web apps to support the policy. Depending on which government agency or agencies are tasked with implementing legislation, they may not have an operating budget to procure a software delivery team, purchase cloud infrastructure, run sophisticated digital marketing campaigns, and so on. For example, the White House and State Governor’s Offices are examples of structures that don’t have a ton of capacity to ship software versus Federal or state agencies who have a huge portfolio of software products, existing devops processes and cloud infrastructure, cyber security policies, etc etc. In most cases, having the delivery live within an agency of a shared services group like the Office of Information Technology is the preferred path.

As you get started as a PM on a new policy, regulation or legislation, work hard to get clarity on how the delivery teams will be structured. This will be hard as there’s a lot at stake and a ton of pressure to move fast.

Conclusion

Over these five years in government, one of the things that caused me to fall in love with this work is the sheer reach of it all. New legislation, policy or regulation has the potential to change an industry or impact millions of people.

This is also a space where I’ve seen firsthand the impact of “software is eating government” (a remix of the phrase coined by Marc Andreessen, the founder of Netscape). Software has begun to permeate every aspect of our lives and is fundamentally changing business models. We cannot afford to ignore technology as we deliver government services, this includes upstream in the policy-making process.

It’s a really good sign if you, the product manager, are part of the team tasked with implementing a new policy. When done right, your expertise in user experience, software development and product design combined with the brilliance and experience of the policy wonks and government experts has the potential to delivery something truly special.

Kelly Taylor's Blog