Pulumi

Pulumi is the leading infrastructure-as-code platform: engineering teams use it to build, deploy, and manage cloud infrastructure across AWS, Azure, Google Cloud, and hundreds of other providers. I lead product design for Pulumi Cloud, working across a small, high-output team of product professionals and UX engineers. The work spans the design system underneath everything, the surfaces above it, and the AI-native primitives Pulumi has been shipping since 2024.

Growth: the first-run surfaces

My most recent end-to-end work at Pulumi is growth: the moments where a team decides whether Pulumi is worth adopting.

• OIDC onboarding for Pulumi ESC. Four manual steps in the AWS console became one guided flow that sets up federated identity across a whole organization, with SSO as the recommended default. The share of teams creating environments with a cloud login provider roughly doubled.
• Connect cloud accounts. Built on the same pattern, it took setup from hours or days to about three minutes for a batch of accounts, and the typical number of accounts connected in a team's first setup more than doubled.

The full story, including the options I rejected and the tradeoff I'm still working on, is in Onboarding as a pattern.

Leading design and research

• Design rituals that stuck. In 2024 I started a weekly UX critique and a weekly design team meeting at Pulumi. Both still run.
• Mentoring engineers. I mentor engineers daily on product and user experience design, and give design feedback on project documentation.
• Setting direction. I recently drafted the vision document for Pulumi Governance.
• Research that reaches customers. It starts with internal stakeholder feedback, moves to customer support and sales, then to customer calls recorded with Clari Copilot. I review the video and transcripts, then work through possible solutions with engineers and product managers.

Pulumi Design System

The Pulumi Design System is a library of Web Components built on the Pulumi Design Foundation, the design tokens that carry Pulumi's visual design. It's the foundation everything else in this case study sits on.

• Token architecture (colors, type, spacing, motion) tuned for a deeply technical UI that has to read at density without losing hierarchy.
• Web Components that import the tokens, so every surface built on them gets the same visual design.
• Figma libraries and tokens kept in sync with code, so what's designed is what ships.

Pulumi Insights & Governance

Shipped from beta through general availability. I led UX across the Insights surface from public preview through GA, the product that makes every cloud asset across AWS, Azure, GCP, and hundreds of other providers searchable, queryable, and governable, including resources created outside infrastructure-as-code. Insights has since matured into Pulumi Governance, and I owned the design through each step of that evolution.

• Resource search with rich query syntax: filtering, grouping, column customization, and AI-assisted natural-language queries ("find all untagged resources in AWS").
• Discovery of assets that were never declared in Pulumi: the long tail of click-ops and shadow infrastructure.
• Policy on discovered resources: extending CrossGuard policy enforcement past IaC-managed infrastructure into the cloud as it actually exists.
• Policy violation triage: CrossGuard policies run at pulumi preview and pulumi up, and one deployment can produce many violations across enforcement levels, packs, stacks and resources. I worked on the policy issues UI so triage is fast and the next action obvious, with language that reads as one thing across CLI output, PR comments and Pulumi Cloud.
• Shift-left governance: surfacing compliance posture early enough in the workflow that fixing it isn't a separate project.

Adoption. Weekly active teams using Insights tripled in its first full quarter of use, and teams applying policy groups grew several-fold. Launch week for Policy Findings set an all-time high for teams actively using policies. In a user study, policy findings tasks had a very high success rate; policy configuration tasks scored lower. A platform engineer at a customer, on the policy overview: "this could substitute for AWS Inspector."

Pulumi ESC, onboarding & approvals

Pulumi ESC (Environments, Secrets, and Configuration) is centralized configuration management for infrastructure and applications. I owned design for two of its highest-touch surfaces in 2024–2025.

• Onboarding & OIDC: a redesigned first-run experience that walks engineers through setting up Pulumi ESC as an OpenID Connect provider for AWS, Azure, GCP, and the rest. The flow has to make federated identity feel approachable on day one without hiding the complexity from senior platform engineers on day two. See Onboarding as a pattern.
• Approvals: a structured review process for any proposed change to an ESC environment. Two interaction shapes: update approvals that gate changes to critical config and secrets before they apply, and open approvals that gate just-in-time access to an environment's credentials. Update approvals shipped in August 2025 and open approvals in October.
• One model for two gates. An update is edited content, reviewed as a new version. An open is a short-lived permission, with how long the grant waits and how long access lasts. I kept both on the same request, review and apply pattern, so people learn it once.
• The pull request as the mental model. Request, reviewers, approve, comment or close, a timeline of revisions and verdicts, then apply. Engineers already know how to read it.
• Approvers named by the rule, not by role. A ruleset sets how many approvals are needed, who can give them (users, teams or a permission), and whether self-approval counts. That fits ESC's security model instead of adding a new role to manage.

Pulumi Neo: governance and policy remediation

Neo is Pulumi's agentic AI platform engineer, launched in public preview in September 2025. It writes Pulumi programs from natural-language prompts in TypeScript, Python, Go, and others, scans for misconfigurations and policy violations, executes infrastructure changes, and monitors outcomes, all under the team's existing RBAC and policy-as-code controls.

My contribution to Neo is where it meets Governance: policy remediation.

• A finding is the start of a fix, not the end of a report. In Governance, you select policy issues and hand them to Neo, many at once grouped by entity type, or one at a time from a suggested task on the issue. It opens with the policies, resources and stack already in context, fixes the code, proves the fix with a preview, and still stops for approval before anything changes.
• Approvals that informed Neo's. I designed approvals for ESC. Neo's approval step isn't my design, but it was directly informed by that work: a gate has to show what it will let through and name who owns the yes. Neo's approval sits on the preview, with scope, change type and policy result summarized before the buttons.
• Built on the policy work underneath. Remediation extends the Insights and Governance surfaces I led: policy on discovered resources and policy violation triage. Neo turns that triage into a next action instead of a ticket.

Full-stack contribution

Beyond design deliverables, I ship full-stack features into the Pulumi service: TypeScript and React / Web Components on the front end, Go services and REST/GraphQL APIs on the back end, including internal hackathon work I've taken end-to-end from data model and API surface through to a shipped UI.

• Working full-stack closes the loop between intent and outcome: the same person who decides what the interaction should feel like also touches the schema, the handler, and the component. Surprises surface during build, not during handoff.
• It also keeps the Pulumi Design System honest. When the design system has to absorb a brand-new product surface under deadline, it helps to be one of the people writing the consuming code as well as one of the people maintaining the system.

Through-line

The connective tissue across all of these surfaces is the same: AI-native design is not a feature pinned on top of an existing UI; it's the substrate. That shows up in the Governance query layer, policy remediation with Neo, the policy violation triage, the ESC approval flow. The job is to make agentic capability feel safe, legible, and trustworthy for the platform engineers, SREs, and application developers who actually run production.

I write production code on this surface daily. It's how I prototype, how I ship, and how I keep the distance between concept and shipped product collapsed.