How I built Google’s enterprise security UX org from one person to 32
The ask was one UX designer to make the tools better, but the tools were a symptom. I treated the org as the product.
- Company
- Google · Privacy, Safety & Security
- Role
- Senior Staff UX Manager
- Team
- One person to 32, across nine locations plus remote
- Read
- 8 min
1 to 32
people in the first UX function in PSS, before I handed it to a UX Director
32 to 45
on the team today, under the Director I now report to
19 of 21
direct reports still on the team
18
promotions in my reporting chain
The short version
Proprietary data, interfaces and workflows omitted under NDA- Context
In 2019 Google’s Privacy, Safety & Security (PSS) organization protected the data of ~4.5 billion users with thousands of engineers and no UX function. The internal tools that defended Alphabet’s infrastructure were powerful, fragmented and described by their own users as borderline unusable.
- Problem
The ask was one UX designer to make the tools better, but the tools were a symptom. The organization had grown without anyone owning how its software felt to use, and one designer could not change that.
- What I did
I treated the org as the product. Over five years I designed its structure, hired its first 32 people across 9 locations, set its operating model, and built it to run without me. In early 2025 I handed it to a UX Director and it has since grown to 45.
- Impact
32 people, 9 locations, 19 of 21 direct reports still on the team, 18 promotions in my reporting chain, and 100% positive annual manager surveys. The org is now the default UX partner for PSS, and it kept growing after the handoff.
Business problem
One designer, thousands of engineers
In 2019 I joined Google as the first and only UX professional in Privacy, Safety & Security (PSS). The mission was to keep everyone safe at scale: Alphabet’s infrastructure and the personal data of about 4.5 billion users, against threat actors up to and including nation states.
The teams were world-class at security. Their software had grown organically for years, each tool built by the people who needed it, with nobody responsible for how the pieces fit. The result was a tooling ecosystem that was powerful and fragmented.
What it cost
In a consumer product that costs you conversion. Here it was operational risk. A defender who loses ten minutes to a bad interface is ten minutes behind an attacker.
The users
Experts fighting their own tools
Our users were the people defending Alphabet: security analysts, investigators, incident responders, and the engineers working alongside them. They were experts, and they were accountable when things went sideways.
Their tools had bugs, dead ends and no coherent user journey, and analysts described them as borderline unusable. They didn’t need delight. They needed software that stopped getting in their way.
Solution
Why hiring designers wasn’t the answer
A series of decisions in the order I made them
The obvious response was to hire a few designers and point them at the worst tools. I’d seen that pattern fail before: designers embedded one per team, each fixing a screen, none of them changing how the organization made decisions.
The vision I had was an organization that could keep its own tooling usable as it grew. That meant the deliverable was an org, with its own research practice, its own design system, its own way of deciding what to build. The first product I shipped at Google was a team.
Decision 01 of 07
Centralized the team before there was a team
A unified org that can drive impact, not siloed designers who can’t.
The first structural call was whether UX would report to me as one central function or sit inside each product team. I chose central. Product teams get deep, dedicated partners, and I keep the ability to move people as PSS priorities shift, which they do constantly in security. It also meant UX had one voice in planning instead of twelve quiet ones.
Embed designers in the product teams that shouted loudest.
Fast to staff, popular with the engineering leads, and it would have locked the first hires into whatever tools happened to be on fire in 2019.
A centralized UX org.
The ability to dedicate UX partners across product areas, and headcount I could reallocate as organizational priorities shifted.
Centralized: the four designers report to me as one UX org, and each is a dedicated partner to one product team.
Decision 02 of 07
Hired generalists first
Early hires have to survive ambiguity. Specialists come later.
The first roles went to strong UX generalists who could handle a problem with no brief, no research and no design system. Once the foundations existed, hiring shifted to specialists: researchers, content strategists, program managers and eventually UX engineers.
Hire by discipline from day one, the way a mature org is staffed.
Clean on an org chart, and the wrong shape for a team of three facing a tooling ecosystem nobody had mapped.
Hired five generalists in the first year.
While hiring, I focused on finding people who could thrive in ambiguity and knew how to wear a lot of hats. This was critical to the early success of the team.
Decision 03 of 07
Built research and a design system before anyone asked
A design org without evidence and a shared system is a studio.
PSS had no UX research and no repository of what it knew about its own users. I hired the first researchers and built a centralized insights repository, so a finding from one team could inform every other. About two years in, I brought in a UXR manager as a peer to lead the researchers and scale the practice. In parallel I drove adoption of an enterprise design system built on Material, which cut technical debt and gave the fragmented toolset a shared language.
Ship design work first and backfill the foundations once the team earned credibility.
It’s the usual advice and it leaves the org dependent on individual judgment.
Research practice and design system first.
Establish them before the headcount exists to justify them on paper. This sets the team up for longer term scalability and success.
Decision 04 of 07
Began hiring around the globe
Follow your engineers and users, not the headquarters.
Chicago was our first site because that’s where I am based. Zurich came next because there were large cohorts of users and product developers from the Detection & Response organization located there. From there the org grew to nine locations: San Francisco, Sunnyvale, Chicago, Austin, New York, Zurich, Rome, Munich, and São Paulo, plus remote.
Keep everyone in one or two US hubs.
That’s where hiring and management were the easiest.
Put UX where the engineers and users were.
Build the operating rhythm to hold a distributed team together.
Decision 05 of 07
Wrote the mission with the team, not for it
People stay for a mission they helped create.
As the team grew past 10 people, I started running annual workshops where the whole org co-defined its values, strategy, mission, and OKRs. The mission they wrote, "make it easy to protect and defend Alphabet," is still the one we use today.
Write the mission and strategy myself and present it.
Faster, but it would have been mine instead of ours.
Annual co-creation workshops.
I think this is one of the main reasons 19 of my 21 direct reports are still on the team.
Decision 06 of 07
Replaced myself as the bottleneck
A flat org stops working at about fifteen people.
For a long time everyone reported to me. At my peak I had 17 direct reports, which meant I was the limiting factor on every career conversation, every review, and every escalation. I restructured into three UX Managers for design, with the UX Engineers reporting to me directly.
Keep the flat structure.
It was fast, everyone had access to me, and promoting managers from within meant losing some of my strongest ICs to management.
A well structured UX organization that could scale.
Three design managers, and me out of the critical path.
Flat: all 17 people reported to me.
Decision 07 of 07
Made the UX org legible to the rest of PSS
An org that partners can’t engage with gets routed around.
Historically, PSS had no user-centered process, so partner teams had no way to bring UX in early. I implemented engagement models and operating frameworks that defined how a team partners with UX, what they get, and who decides when there’s a conflict. This is unglamorous work and it’s most of what made my team the go-to partner instead of the optional one.
Stay informal and rely on relationships.
It works at five people and quietly breaks at twenty.
Written engagement models and decision frameworks.
I developed an intake model, prioritization frameworks, and planning rituals.
The handoff
Where this story ends
At the start of 2025 the org was 32 people, and a UX Director was hired above me. That’s where this case study stops, on purpose. The test of an org you built is whether it keeps growing when it’s no longer yours to run. Since the handoff the team has grown to 45, and I now lead three UX Managers and the UX Engineering function inside it.
I didn’t do the first 32 alone. The UXR manager I brought in as a peer two years in built the research practice into what it is now, and the engineering and product leaders who gave the team headcount took a bet on a function that didn’t exist yet.
- 2019
- 2020
- 2021
- 2022
- 2023
- 2024
- 2025
- Design
- Research
- Content
- P&O
- Engineering
Results
Impact of the work
What changed in PSS
The org is now the default UX partner for PSS, and it kept growing after the handoff. Scattered tools and broken workflows are now part of a cohesive, unified portfolio.
What survives me
The org, obviously. It kept growing without me at the top, which is a result on this page I’d defend in an interview without a single caveat.
The mission and the workshops. "Make it easy to protect and defend Alphabet" is still the line the team uses, and I’ve trained many on the team in how to run these workshops themselves.
What I’d do again
Centralize early, and hire generalists first. Both were unpopular with certain partners at the time and both held up in the long run.
What I wouldn’t
Stay flat as long as I did. Seventeen direct reports was a sign I’d waited a year too long to build a management layer, and the people who paid for that were my direct reports.
