“With so many stakeholders coming from so many different perspectives, the sprint challenge was to fully grasp the needs of each user within the hiring process.”

The Challenge:

Building, sustaining, and nurturing a strong company culture is what separates winners of the long game from those who burn bright but eventually burn out. Human Resources is the gatekeeper of company culture and enterprises that invest in HR are better positioned to maintain a strong culture. That’s why gHire is such an important part of Google’s DNA.

GHire is a suite of SaaS applications built to support the hiring infrastructure for the entire company. As Phil Chung, a UX Manager in Corporate Engineering at Google, describes it, “We own the candidate journey from the online application all the way to the job offer.” Along that journey there are multiple input points from a variety of decision makers including the People Operations team, hiring managers, and interviewers. Everyone accesses the gHire suite as the candidate’s application moves through the pipeline.

The Sprint was convened to build cohesion around the team’s vision. “With a recent reorganization of the team and pieces of the product becoming public,” says Sprint Master Rachel Inman, “we needed a sprint to align on our critical user journeys and share information across sub-teams.”

With so many stakeholders coming from so many different perspectives, the Sprint Challenge was to fully grasp the needs of each user within the hiring process and to reach consensus on the values of Google’s hiring philosophy. Simply put, the Sprint needed to answer the basic question, “What does Google care about when making hiring decisions?” Once that question was resolved, the Sprint would look to explore ways of baking those values into gHire—in the design of its process and tools—from initial application to final hiring decision as well as to use the findings as a launching point for a rebrand of the product suite.

“This was a relatively large and relatively quick sprint with upwards of thirty people working together for just three days.”

The Team:

The Sprint brought two teams together: the UI/UX designers and engineers who build the hiring tools and People Operations (Google’s HR team) who manage the hiring process, the two sides of the hiring coin. Getting everyone in one room helped helped reduce tunnel vision of each team, revealing a wider, more empathic perspective on the hiring process.

This was a relatively large and relatively quick Sprint with upwards of thirty people working together for just three days. A number of new project managers and engineers had recently been brought onto the hiring team, so the sprint doubled as an introduction to the gHire universe, ensuring buy-in with the new team members.

The Sprint:

Intensive preparation was key to the Sprint’s success. The team knew they wouldn’t have the traditional five days, so doing the necessary groundwork before convening the Sprint was critical. Rachel met with all the gHire cross functional team leads to create a starting list of critical user journeys. She also met with the gHire user researchers to collect all relevant research study data that informed these critical user journeys as well as the tech leads to aggregate gHire usage stats from the past year.

The prep included collecting and analyzing all the user roles - their goals, needs, and pain points. In addition to Rachel’s pre-sprint interviews, information was gathered via diary studies, task analysis, UX research and team surveys. The important piece was to document not just what people did in their separate roles, but the reasoning behind each decision. Eventually, the Sprint team compiled user journey maps documenting how people went about accomplishing their jobs and why they made the choices they did at each critical juncture.

When the team finally got together, the first order of business was to review research findings in lightning talks. Getting people out of their team silos and sharing the big picture had a profound impact on everyone’s understanding of the necessities of an effective hiring system. Context, as is so often the case, dramatically altered people’s perspectives.

On day two, the large group broke into small teams to tackle pain points in different user journeys. Each team included one to two Googlers with a different role - hiring managers, People Operations managers, UX designers, and engineers. The idea wasn’t necessarily to solve the problem itself, but to share perspectives on possible solutions from every stakeholder in the process as well as to discover shared values. Including people from multiple disciplines meant it was easier to understand the broader implications potential changes would have on the process as a whole.

Engineering interviewers were also brought in to talk about the interview process. This proved particularly informative, as many People Operations “employees” or “team members” were unaware of the more technical aspects of engineering interviews. It became clear that the process needed to better accommodate these technical requirements.

Finally, on day three, the group returned to the overall hiring process, sharing their insights from day two and building out a roadmap. “The teams presented their journey maps back to real gHire users,” says Inman, “which was an important learning moment for even the more senior gHire team members.” This final step ensured agreement on hiring values as well as the flow of user journeys and overall product strategy.

“Including people from multiple disciplines meant it was easier to understand the broader implications suggested changes would have on the process as a whole.”

The Discovery:

Whereas the traditional Sprint is designed to prototype and test product/design solutions, the gHire Process Sprint functioned more as a discovery and consensus building exercise around the hiring experience and process. The Sprint clarified that People Operations and gHire designers and developers were often trying to solve separate problems. The Operations team were invested in using data and research to build a process based on particular values intrinsic to Google’s hiring philosophy. On the other side, the design team was buried in solving practical pain points and tool building, blissfully ignorant of the hiring values and how their tools either enabled or hindered the broader hiring goals. Simply put, they all became aware of how process and tools can affect one another.

Consider Google Calendar as an example. Users can set meetings for a half hour or an hour by default. The result is that meetings occur in half hour increments. The tool itself comes to define corporate behavior. The Sprint clarified the need to build tools that were mindful of the values People Operations were trying to support throughout the hiring process, especially as it related to the candidates. After all, the hiring process itself is the candidate’s first introduction to the Google’s values and a key component to finding a long-term fit is recognizing shared values.

A good example of those values is Google’s emphasis on its hiring bar—the demarcation line between a strong candidate and someone who doesn’t quite have the right stuff. That’s why Google strives to detach its employment decisions from hiring managers. Partly, it’s to counter the impulse towards nepotism, but mostly it’s a way to ensure that candidates aren’t judged against one another, but rather against an ideal. Maintaining that ideal is the key to high caliber hires. This, it turned out, was the most important aspect of the entire hiring process and every stakeholder needed to hold that in mind when building or interacting with the gHire Suite.

“The Google Hire Process Sprint functioned more as a discovery and consensus building exercise around the hiring experience and process.”

The Outcome:

The process sprint was not run to create and test immediate solutions. Rather, it was run to build cohesion and consensus, a way of ensuring that everyone involved in gHire understood the core mission, agreed upon the baseline hiring bar, and that all their future work served a common goal. “We had a tremendous amount to get done in a very short time frame,” says Inman. “The Sprint required an extreme level of organization and time keeping. We wouldn't have gotten through as many exercises without this rigid time boxing.”

While the Sprint was not designed to explore new ideas, as with many traditional Sprints, the process couldn’t help but inspire a few. Since the Sprint, the gHire engineering team has built a number of tools that have streamlined the hiring process, improved its speed and efficiency, and, most importantly, made it easier to evaluate the candidate’s talent.

One particular example involves engineering hires. The UX design team built a coding environment that allowed candidates to code on a keyboard as they would on the job, while simultaneously enabling interviewers to capture and time the coding itself, removing the busy work of transcription. To date, the new coding environment has been a hugely successful addition to the hiring process.