In March 2023, I had the chance to participate in the NYC Product Led Summit as a panelist alongside Jasjit Mangat (Hinge), Marvin Li (Reddit), Nicole Tai (Muck Rack), and Penelope Madry (American Express). Our panel’s theme was:
“The power of cross-functional deference in product management”
When I began preparing for the panel session, the word DEFERENCE threw me off kilter. The word felt important and full of responsibility! Later when Jasjit, Marvin, Nicole, Penelope, and I explored “deference” in our product management work, we found a strong link between deference and empathy. The five of us brought this to life during the session by sharing stories from our experiences, reflecting on the ways we intentionally create culture, and exploring how deference can result in building the most impactful products. Here are some of the stories I shared.
_____
Jasjit (moderator): When you heard the title of this panel session, what did you think it meant?
Gaelle: When I first heard the title, I thought about respect.
In 2021, a designer joined my team. It was the first time we brought Design into a platform product development team at the New York Times, and I firmly believed that a designer would help us improve our developer tools.
Early in their first few days, my design partner said to me: “Gaelle, I am not sure what my role should be and how I can contribute. Your team is not building user-facing experiences.”
I immediately said: “No, no, we really really need your expertise! I would love to partner with you to better understand the experience of New York Times engineers and the areas where are we missing the mark. I need help to run better user research, to level up the UX of the tools we are providing, and to ultimately connect those tools back to our consumer product so that the consumer product itself improves.”
My design partner was intrigued and ultimately they were willing to join me on the journey… So for me, deference means creating trust with your partners, empowering them to do what they do best, and letting them shine via the unique craftsmanship they bring to the work.
Jasjit: When is it the product manager’s role to make the decision and hold power, and when is it our responsibility to hand off responsibility to someone else? How do you balance that tradeoff and is there a moment where there can be too much deference?
Gaelle: As product managers we can help provide clarity on the guardrails. Perhaps we need to make a change on a short timeframe and that can be helpful for design to know so that the designer focuses on a simple user experience to start. Or perhaps the engineers might need to know that the launch date is not flexible due to a marketing campaign with planned advertising. That can enable the team to more proactively raise risks and engage the product manager to make a tradeoff so that the launch date holds.
Jasjit: Deference is easy to think about in theory. What happens when people on your team are in disagreement and you’re ultimately at the helm of making a decision?
Gaelle: I joined the Times as a Technical Product Manager on the Authentication team. Early on, I experienced that the InfoSec team would frequently come to the team and say: “Here’s a new security vulnerability we uncovered, you need to fix it straightaway!” The steady stream of urgent, unplanned requests was not working well.
I took the time to meet with my InfoSec partner and say: “OK, we need to have more of a process in place. When there is a new security vulnerability uncovered, let’s discuss the risk level of the vulnerability so that the team can triage appropriately. Also, let’s discuss how you and I can partner effectively on an ongoing basis. Perhaps we could create a backlog together and review the backlog regularly?”
We had a very explicit conversation with each other. We discussed that both of our teams have goals and both of our teams have constraints. We discussed how we might partner effectively together. We really spelled things out, did a bit of a reset, and then we acted on our shared plan.
Just like we agreed, we met once a week. I would share an update on any security improvements the team had accomplished and my InfoSec partner would share an update on new security initiatives. It became a really productive partnership, but it took resetting together and agreeing on how we would improve.
Jasjit: Sometimes things don’t go well. How do you build trust and psychological safety so that teams feel empowered to give their honest opinions?
Gaelle: I strongly believe that building psychological safety is something you have to invest in everyday. That practice also takes a variety of forms.
A really important starting point is to connect with the various team members on a human level. Some tips & tricks into the ways we do this on my team: when someone is new, we take time to get to know that person. We’ll play 2 truths and lie, which may seem a little silly but frequently we get tricked by the new individual! We’ll also do “3 Things 3 Minutes” and have the entire team introduce themselves by sharing a little bit about their lives.
That’s an important foundation because, when we’re having a difficult conversation and we’re not all in agreement, we find that we have a bit more connective tissue between the different members of our team. That connective tissue enables to be more open minded about ideas because we understand where different people might be coming from.
Lastly, we have very strong practices around retrospectives. We will never forego doing our retro and we rotate which team member runs the retro session. During each retro, we discuss what we could have done better and we’ll also give each other shoutouts. For the things that could have gone better, we make a point of taking action, which reinforces the benefits of sharing during retro.
Jasjit: How you ever had to navigate deference while introducing product to the org?
Gaelle: When I joined the Times, my team had not previously had a product manger and was not used to working with a product manager. A second challenge was that I was one of few product managers working on internal Platform products. My third challenge was that it was the first time I had the title of “technical product manager” and I was a little scared of what that meant because I do not have a technical background.
Being new to the team and to the organization, I started simply by observing how everyone worked, what were the goals of the team, how did other teams rely on the team. Then I found a clear opportunity to lend my Product expertise and raise the quality of the work. The team was in the process of launching a change, so I jumped into that: I did go-to-market internally, I highlighted how the change tied to overarching business goals, and I reported back on impact after the launch so that we could iterate based on learnings. The team saw me in action in a very concrete way, and that quickly built trust.
Following that launch, I kept building on the momentum. I continued to bring the team members closer to the business goals and to the ways their work impacted the New York Times customer. Now no one could imagine NOT having a product manager on the team!