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 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 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.
