You may have heard of software engineers practicing pair programming — but what happens when two Product Managers try pairing? Is that allowed?
For those familiar with the concept of pair programming, you’re aware that it’s practiced and preached as a method for improving code quality as well as knowledge sharing person-to-person and across a codebase. Furthermore, it can reduce onboarding time for new hires and acts as a means to share best practices.
When I first joined FordLabs in January of 2019, I was paired up with the skilled and energetic Gregory Degorsky for about a month’s time. I found that the benefits of being paired with another PM share similarities to that of software development from above and more.
Knowledge Sharing: What’s great about pairing is it gives both parties the opportunity to learn from each other — no matter your experience level. Working with a pair provided me a sounding board to reaffirm the existing knowledge that I possessed, but may not have had an opportunity to practice. My pair also gave me daily constructive feedback and positive reinforcement, which was important to help me grow my skills while keeping my confidence up. I was able to help my pair, too. Greg shared that I’ve encouraged him to look at alternative ways into data and reporting, inspired him to learn more and look closer to details and become a mentor through empowerment and trust. I’d say that’s a win-win!
Backlog Quality: Much like pair programming, two heads are better than one. This was the same case when it came to our backlog. Working together on prioritization and user stories allowed for more clarity in the stories we were writing and more assurance that we were working on the most important task at that time.
Team Practices: Having a PM pair was helpful for learning team norms, as well as group norms in FordLabs. Joining a new team brings a lot of unknowns, and each team builds their own understanding of “normal”. Having a pair allowed me to observe the team’s behaviors, practices and preferences. This plays into the reduction of my onboarding time.
Best Practices: Best practices in this case may also mean personal preferences. My pair shared with me their habits such as breaking down work into manageable user stories and facilitating group exercises.
Continued Support: When it was time to adventure out on my own become the sole Product Manager for the internal product /dev/central/station, my pair left the conversation open for future questions and help.
Does your team pair team members? What benefits have you seen from being paired up with a teammate? Would you like to see more pairing on your team? Let me know in the comments!
This article was originally published on April 26, 2019.
