YaleSites — Operating a Platform at Scale

Overview#

Building the YaleSites platform was a multi-year design and engineering effort. Running it as a live product turned out to be a different job entirely — one defined less by what I designed and more by how I made decisions, aligned stakeholders, and kept a shared platform moving forward for a community of 2,400+ active users across one of the country's most decentralized universities.

When the platform launched and moved into operations, I transitioned from Lead UX Designer to Product Manager. That shift meant owning the roadmap, running quarterly governance with university leaders, managing vendor-unit collaborations that ship features to the whole community, and running the weekly agile loop that keeps development moving. This is what that work looks like.

The Challenge — Governing Without Authority#

Yale is intentionally decentralized. Departments aren't required to use YaleSites — they choose it. That means the platform has to earn adoption continuously, and decisions about what to build next can't be made unilaterally. Every prioritization call is a stakeholder alignment problem.

To solve this, I established and run a governance committee — 10 to 12 unit leaders drawn from across the university, including the Office of Public Affairs and Communications, the University Printer, and directors from major units like FAS, Yale College, and West Campus. We meet quarterly. I present the roadmap, report on what shipped, and facilitate structured prioritization discussions about what comes next.

The committee isn't a rubber stamp. These are senior people with competing priorities and different constituencies. My job is to walk in having already done the synthesis work — so the conversation moves productively rather than in circles.

How We Build New Features — The Collaborative Model#

The most distinctive aspect of how YaleSites operates is how major features get built. When a Yale unit has a significant need, they can bring a vendor to develop it — and when they do, I sit at the center of the collaboration to ensure the work benefits the entire platform community, not just the unit paying for it.

Case Study — It's Your Yale × Four Kitchens (YaleSites v2.0)

It's Your Yale — Yale's central employee news and resource hub — needed substantially better content organization and navigation. They brought in Four Kitchens, a specialist web development firm, as their vendor. Over six months, that collaboration produced some of the most significant features in the platform's history: Content Collections (a full two-level navigation system), flexible multi-column section layouts, enhanced post content types with social sharing and estimated read time, and a redesigned block picker.

My role throughout:

• Worked with the It's Your Yale team to scope their needs and separate what was specific to their site from what could serve the whole community
• Collaborated with Four Kitchens to review requirements and ensure features were architected for platform-wide use, not bespoke implementation
• Coordinated with my internal development team to ensure compatibility, run QA, and manage integration into the core platform
• Shaped the feature documentation and release communication so the broader community understood what shipped and how to use it

This model has now been used across multiple collaborations — including partnerships with the Poorvu Center for Teaching and Learning, the School of Environment, and the Institution for Social and Policy Studies — each one adding features the entire YaleSites community now benefits from.

View the live site — your.yale.edu →

Day-to-Day — Running the Agile Loop#

Outside of governance and vendor collaborations, I run the weekly development process. The operational loop looks like this:

In 2025, that process resulted in 5 major platform releases, fixes for 25 community-reported bugs and 113 internally caught issues, and continuous Drupal core security updates.

Results#

• 2,400+

  active users across Yale

• 449

  sites in development or production

• 900

  support requests completed in 2025

Lessons Learned#

Lean on the governance committee early.

When hard decisions came up internally — prioritization calls, scope disagreements, whether something belonged on the roadmap — we found far more success bringing those questions to the governance committee than trying to resolve them in-house. The committee existed for exactly that purpose, and leaning into it meant decisions had institutional buy-in instead of just internal consensus.

"Platformizing" unit-funded features is the real work.

When a unit brings a vendor and funding, they often come with a solution already in mind — one that works perfectly for their use case. The challenge isn't saying no. It's finding the platformized version of what they're asking for: a feature broad enough that other units across Yale could actually make sense of and use it. That requires deep university knowledge, because what looks like a reasonable one-off to the unit often duplicates or conflicts with patterns that already exist elsewhere in the community.

Live operations is its own discipline.

Building the platform taught me how to design systems. Running it has taught me how to sustain them — how to keep stakeholders aligned, keep a community engaged, keep quality up, and keep shipping without burning out the team.

Running YaleSites is structurally similar to live service product management — a shared platform, a community of stakeholders with competing needs, a vendor ecosystem, and a quarterly release cadence. The domain is different. The job is not.