People Search - Architecture Modernization

The problem

The existing Employee Search experience was constrained by legacy assumptions about how employee data should be modeled and retrieved. It functioned more like a basic lookup tool than a modern discovery layer, which limited its ability to support how users actually navigate organizations, find the right people, and act on employee relationships in context.

The page itself could no longer scale as the entire page relied on stored procedures and direct SQL queries that caused the page to take upwards of 20 seconds to the first meaningful load for clients over 5,000 employees.

From a product standpoint, the problem was not just UI depth or search relevance. The deeper issue was architectural: the system was not designed to represent more complex relationships, assignment-level distinctions, or the broader organizational context needed to support more advanced search and discovery workflows. That created a ceiling on what the product could become and made incremental feature work less valuable without a stronger foundation.

Context

This work sat inside a broader HRIS / HCM environment where employee data, reporting structures, and assignment details were already being used across multiple workflows. The challenge was that the existing architecture reflected a flatter, more traditional view of employee records, while the product opportunities were moving toward a richer model of organizational context.

There were several constraints:

• First, the existing system had technical and data-model limitations that made it difficult to extend search cleanly.
• Second, there were differing opinions across product, engineering, and leadership about how ambitious the solution should be, including debates around employee-level versus work assignment-level modeling, and whether the product should remain narrow or evolve into a broader people-finding capability.
• Third, this work touched multiple stakeholder interests, which meant product direction had to balance user value, engineering feasibility, delivery sequencing, and organizational appetite for change.

The environment also required translating a strategic architecture problem into something concrete enough for cross-functional teams to evaluate. That meant framing not only what users needed, but why the underlying model had to change in order to support those needs over time.

This was further complicated by the fact that two teams and two product managers were involved. One team owned the front-end experience, while the other owned the People Search database and supporting data needed to make the new experience possible.

My role

I helped define the product direction for the modernization effort by framing it as an architecture and platform problem, not just a UI enhancement. I grounded the solution in the same data structures and technology that powered standard employee search APIs across the platform, so the new experience would return consistent, trustworthy results.

I worked to frame the opportunity in a way that business and technical stakeholders could understand: not as a one-off feature request, but as a foundational product problem involving scalability, discoverability, and the representation of employee relationships. I influenced how the team thought about the tradeoffs between short-term delivery and long-term flexibility, and I pushed for a model that could better support complex real-world organizational scenarios rather than preserving a simplified legacy structure.

More broadly, I served as a bridge between product vision and architectural implications and limitations, helping connect user-facing pain points to the system-level changes needed to address them as well as the governing technical constraints that existed in the tooling used.

Approach

I approached the problem by reframing People Search as an architectural modernization effort rather than a simple feature enhancement. Instead of starting with isolated UI ideas, I focused on the underlying product structure: what users were really trying to do, what kinds of organizational relationships mattered, and what the system would need to represent in order to support those workflows.

That led to several key elements in my approach:

• I clarified the difference between basic employee lookup and a broader people-discovery model.
• I pushed the conversation toward scalable structures, especially around how people, assignments, reporting relationships, and contextual roles should be represented.
• I framed the product direction in terms of long-term capability, not just short-term feature output.
• I worked through tradeoffs between ideal architecture and practical delivery, recognizing that modernization had to be communicated in a way that engineering and leadership could absorb.
• I used product artifacts, strategic framing, and stakeholder conversations to move the work from isolated requests into a more coherent systems discussion.

At the center of the approach was a belief that the quality of the search experience would ultimately depend on the quality of the underlying model. In other words, better product outcomes required better structural thinking.

Outcome

With the new architecture in place, we reduced the page load time from 20+ seconds to sub-300 milliseconds, even for clients with over 5,000 records. The addition of filters to the page had negligible impact on these load times and increased the overall user experience based on initial Early Access user acceptance testing.

The modernization effort helped elevate the conversation from “improve search” to “improve the architecture that makes better search possible.” Even where final implementation decisions were constrained by organizational or technical realities, the work created a clearer product framing around why legacy assumptions were limiting the solution and what a more scalable direction could look like.

It also surfaced important strategic lessons. First, in enterprise products, search problems are often relationship-model problems in disguise. Second, architecture decisions can quietly define the ceiling of the user experience long before the UI is designed. Third, one of the most valuable things product leadership can do is make hidden structural constraints visible, so teams can make more informed decisions about what they are really building.

The result was not just a concept for a better search experience, but a stronger articulation of how architecture, data modeling, and product strategy needed to work together to support modernization.

It did open up additional questions to be resolved, as all good projects do:

• This new People Search page was built to replace the existing Employee Search page, and that was Admin-only. Would this new page be useful to non-admins?
• For Admins, this new page works similar to the Company Directory page and even felt similar. However, if a user had limits on how many employees they could see, this page would look similar to the Directory, but operate differently.
• Should this page replace the Company Directory? If so, how would employee users (non-admins) react to having the Company Directory relocated from its current location nestled with the Org Chart?

These questions would all need further research, and show how a single technological update can expand into a much deeper strategic discussion and extend the initial project scope beyond initial delivery.