What people operations can learn from product development

Have you ever worked at a company where everyone was unhappy with the goal tracking system? The People Ops team had worked hard to roll out a new process and tool, but it was a big flop. Teams just didn’t take to it.

I see this situation happen again and again on Human Resources and People Operations teams. What’s worse is the high time and cost commitment of change means companies are stuck with a bad system for several years.

We often accept situations like this as a fact of life when dealing with organizational change and the complexities of internal requirements. And yet, we see product development teams that are continuously evolving complex products for customers around the world. Why are these two teams operating in such different realities?

From my experience leading People Operations teams and working on our own product development at Range, it’s not that the substance of the work is so different. Rather, it’s about how these teams do their work. On the one hand, People Operations teams often take on big, isolated projects that span multiple quarters before being launched. On the other, product development teams have learned how to leverage user research, cross-functional teams and sprint-based projects to provide continuous improvements to users.

This difference is great news for those of us working in People Operations because it means we can learn from product dev practices and apply them to our own operations.

The first step is understanding the people that we serve. While People Operations is constantly thinking about, well, people, we often forget to get comprehensive information input from the teams we serve. So, at the beginning of any project, we can start where product development starts: user research.

User Research

User research is the discipline of using observation, interviews, data collection, and other methods to learn about user needs, wants and behaviors. In product development, user research often involves interviews with product users, asking questions about how they currently do a task and their needs. The premise is a better understanding of users helps product teams build better products that more effectively meet their needs.

People teams also have users. In this case, our users are internal teams and leaders using our ‘products’ — where products can range from actual products like goal-tracking software to processes like onboarding programs or manager training.

And just like product dev teams, People teams can benefit from a deeper understanding of our users. Through relationships, surveys and ongoing conversations, People teams often start down the path of user research. But we do so seeking validation of a proposed solution, rather than an exploration of a need.

What I rarely — if ever — see a People team do is study how teams work and integrate that knowledge into their programs, software choices and plans.

Tell me if this sounds familiar: a team or company has grown, and leaders have been grumbling for a while about losing a sense of what’s going on and how to drive progress. The classic next step is the leaders tell the People team they’d like to implement OKRs as a way to hold everyone accountable. The People team asks the leader questions about what they’re looking for and starts researching OKR tools. They might ask a few teams to pilot the tool before doing a company-wide rollout.

Did the People team do user research? Yes. They talked to leaders about what they needed and incorporated teams into the pilot program. But what’s missing is a deeper understanding of how teams are operating today. At Range, I often ask teams to show me their spreadsheets or walk me through a team meeting to help me get a firm sense of what they’re doing today and why. For People teams, this type of research is invaluable to identifying the needs that a uniform goal system would need to solve, and the difficulties that might arise during that process.

In this situation, taking time to interview users might alert a People team that any software that doesn’t integrate with Jira is going to be useless for engineering teams. That knowledge helps save time and money when selecting an OKR product. On a deeper level, they might learn that many teams are already tracking and working on goals, but they only hear feedback from leaders on a quarterly basis. In that case, the People team might push back on senior leaders’ ask for an OKR tool and instead suggest evaluating the communication process internally. That’s the power of user research.

The next key lesson from product development focuses on the people who are on your team.

Cross-Functional Teams

Driven by Agile and the Spotify model, many product development teams have shifted towards shorter-term, highly cross-functional teams where designers, product leaders, researchers, data scientists, and engineers all work together on the same team. The key difference between these teams (often called squads or pods) and traditional team structures is the way in which work happens. Traditionally, work was handed off between teams in a waterfall approach, meaning each team finished its part of the project before handing off to another team. For example, a design team might fully spec out the end state of the product before handing off to engineering.

This approach sounds good in theory, but work isn’t linear. Design issues or data analytics questions arise throughout a project, meaning teams go back and forth handing work off, slowing down the project.

In much the same way, People teams are slowed (sometimes to a halt) by operating without cross-functional partners embedded in their team. People Ops teams often start with a mandate from leadership before moving to loop in other stakeholders like finance, IT, and the broader company. What that means is People Ops teams are stuck going back and forth to different teams with different requests or learnings. As a result, rolling out a new process or software starts to take months because even scheduling a meeting with these stakeholders can require a week or two of calendar finagling.

Consider instead the product development model. A need is identified — perhaps by leadership or by People Ops or even by a team. Then a cross-functional team is formed to learn more (through user research) and identify a proposal. The team includes members from the top stakeholder groups like one exec, one eng team manager, one finance partner and one HRBP. Together, they engage in user research, identifying lessons and forming a proposal for what to do next. Because each group of stakeholders is involved in the process, there’s already a high degree of alignment across groups when the lessons and proposals are shared, making it much faster to address issues and get to the next stage of the process. Plus, each team feels more empowered and committed to the process because their voices have been heard, and they’re already a part of implementation. Through these cross-functional teams, People Operations can move faster and get more done.

Our final, and biggest, lesson from product development teams is about how they scope and collaborate on work.

Agile and Continuous Delivery

The Agile and scrum processes product development teams started shifting towards in the ‘90s introduced an iterative, team-based approach to product development. Instead of year-long development processes, teams work in short sprints, often two weeks long, that focus on iterative improvements and changes. Two weeks might sound like too short a time frame to make an impact, but teams create a backlog of work and a product roadmap which helps guide the sprints to achieve the team’s goals. Each sprint is then scoped to allow the team to complete a set of work within the two-week parameters.

A key principle here is continuous delivery, which means that teams are iteratively releasing updates to software that is actively being used. The magic is that teams can incorporate changes frequently, instead of waiting for the next big launch, which allows for continuous improvement.

Now, consider how we might apply this to People Operations. With projects like our goal process, it’s often a year long (or longer) process to identify, adopt and train the team on a new plan for tracking goals. The problem is that during this year, the team is left without a goal tracking process. And suppose that the new process isn’t quite right? Then the People Ops team is left with a decision of do they continue with an imperfect system or do they spend another year trying to fix it? Most teams I speak with stick with the imperfect system, even when it’s painful for the team.

An Agile approach would consider the purpose of the work, which is to improve team accountability and communication. Launching a new goal-tracking system is a potential solution, but another is seeing what could be done in one or two sprints to help achieve these goals. Instead of adopting a new software, a simple spreadsheet template may suffice.

Let’s say we try sharing the template, but we still see a need for a different software tool. Instead of managing a process to launch to the whole company in eight months, working in sprints would suggest that we start team by team, helping each team adopt the tool until the whole company is on board. This might sound like a logistical nightmare — the company split across different systems — but it makes you think like a product dev team. How might we integrate the existing process into the new one? Could we update the spreadsheet template to be similar to what the software provides, so teams are eased into the shift?

By rolling out slowly, we might also learn that the software isn’t working as we expected it to, and we need to pause, adjust, and go back to the teams. Instead of giving the whole company whiplash, now we just need to talk with a few teams.

People Ops: Time to Adopt a New Way of Working

Working more like product developers can increase the impact of People Operations teams and their ability to react quickly and effectively to teams’ needs. That said, adopting a new way of working can feel daunting. But the advice in this piece can also be applied to that process as well.

Start with user research. Talk to your coworkers in product development and ask them about their work. Collect examples of briefs, questions, and the best approaches to integrating qualitative and quantitative research.

Build a cross-functional team: include members from different sides of People Operations like HRBPs, a senior leader, and learning and development.

Think in sprints and iteration — how might you start working in sprints on *one* of your projects? What would that look like? What’s the smallest step you could take towards doing that? If you’re new to sprints, a great reference with lots of tangible tactics to try is The Sprint Book.

Driving change in companies can feel daunting and even slow, but by borrowing approaches from product development, People Operations teams can move faster and increase our impact on company culture and team success.

---

This article was originally published on CMSWire.