It's been almost exactly a year since I wrote a blog post on my leadership principles and shared it with my team, asking them to keep me accountable as I grew as their manager. Thinking back on my mindset in that moment, I was ~four months into my management journey and largely felt like I had no idea what I was doing. Fast forward a year and I still largely feel like I have no idea what I'm doing, but I can say that I'm proud of how well these principles—which I thought I'd for sure revisit as time went on—have held up. I'm also extraordinarily grateful for and humbled by the outpouring of positive feedback and support I received from my team when I announced earlier this month that I'd be moving into a new role on the Microsoft Viva team after spending the past six years on Microsoft Edge. Being responsible for others' careers and development was a huge responsibility that I didn't take lightly, and hearing folks reflect on how much they learned, grew, and felt cared for meant so much to me.

Since the role in Viva will be an IC role to start with, I wanted to spend some time reflecting on what went well, what could have gone better, and what I learned in my first year as a manager so that I'll be able to jump back into this mindset the next time I'm given the opportunity to lead a team. Beyond helping me reflect while the learnings are fresh, I hope this post will be helpful for others who are either new managers or hoping to become managers in the future. If this is you and you want to chat more, please feel free to reach out anytime!

I'm not going to lie, leaving behind an incredible team of exceptional PMs that I'm super proud of was the hardest part about leaving the Edge team, but I think the wealth of new experiences and opportunities for leadership that I'll get in this new role will only help me grow as a better product manager and a better product leader who in turn will be able to more effectively grow others. I'll try to blog about these experiences and learnings a little more frequently than once a year 😉.

Given how much there is to say on each topic, I'll be splitting this into a series of posts:

1. What went well (this post)
2. What could have gone better
3. What I learned

What went well

Let's start with what went well. While I may add more reflections here over time, I decided to pick my top three (in no particular order) to start with:

Growing the team

When I started out as a manager, there was some natural attrition from folks who were ready to take the next steps in their careers. This meant that I had to quickly ramp up both on being a new manager and on understanding what the team needed for long-term success. While I had participated in several interview loops in the past, this was the first time that I was participating in them as a hiring manager, meaning I had to sit down and really reflect on the types of PMs I wanted to bring onto the team. Transparently, I was operating largely on instinct when I first set out on this journey, but after successfully growing the team and looking back, there are now a couple resources and activities I can identify that helped me refine my thinking on hiring over time:

1. Shreyas' thoughts on Operators/Craftspeople/Visionaries - While this thread wasn't written until after I had finished the first round of hiring on my team, it eloquently puts into words several of the internal monologues I had when considering who to hire to set the team up for long-term success. When I looked at both myself and the leaders above me, I saw strong Operators—folks who are great at driving alignment, unblocking execution, and managing up. What we were lacking on the team were Visionaries and Craftspeople—folks who excel at big picture thinking, defining products/strategy, and seeing what others can't.

2. Running a strengths/weaknesses exercise on the team - I struggle to remember what prompted this experiment, but a few months after sharing my leadership principles with my team, I took the list of common PM tasks that Cracking the PM Career identified in each phase of the Discover, Define, Design, Develop, Deliver, and Debrief product loop and had folks self-assess both their competence and level of commitment to each task, a form of self-evaluation I learned from Ken Blanchard's Situational Leadership training:

   

   Beyond increasing transparency, vulnerability, and trust on the team, having the team (myself included) reflect on and openly share their strengths and weaknesses helped me understand where the team needed to collectively grow the most, how hiring could help fill the gaps, and how I should approach managing each person on the team depending on what task they were trying to complete/where they were in the product lifecycle.

I ultimately strove to hire a diverse set of folks who a) had strong PM tendencies (curiosity, customer empathy, and grit/determination are the main things I learned to look for over time) and b) were very different from my primarily Operator-like mindset in terms of their natural product leadership leanings. This ended up (IMO) being a huge contributing factor to the collaborative culture we collectively built on the team; peoples' strengths complemented each others' weaknesses, and through the open sharing/discussing of ideas, we were able to all make each other better PMs and deliver better customer/business outcomes as a result.

Harnessing everyone's strengths and motivators to drive impact and growth

As a manager, a huge part of my job was to help people grow to meet their career goals while delivering customer and business impact along the way. To truly help someone grow, I knew I had to understand and care about them at an individual level, tailor my management style to suit their preferences, and support them through whatever else might be going on in their personal/professional lives. To make sure I got to know everyone on the team as early as possible, I'd dedicate our first 1:1 to asking the following questions:

• What do you need from me/what can I do to best support you?
• What do you see as your biggest strengths/weaknesses?
• What sorts of projects energize you? What sorts of things don’t?
• Where do you hope to see yourself in the next year?
• What is your preferred style of management? More hands on? More autonomy?
• What have your past managers done that you’d like me to also do, or not do?
• How do you like to receive feedback/praise?
• What’s something you do regularly outside of work that’s really important to you?
• Is there anything that you want to learn more about that is top of mind? How can I support you?
• Is there anything else that you think I should know?

While we'd continue to discuss the answers to these questions in subsequent 1:1s, building this foundation up front helped establish trust/transparency and gave me a better idea of how to manage everyone and what work would align best with a certain persons' interests, skills, and aspirations. This (at least from my perspective) boosted collective energy, focus, and morale, and it's been incredible to watch that translate itself into impact and growth for every single member of the team.

Building a customer-first culture that emphasizes the importance of qualitative and quantitative signals

When I first became a manager on my team, the notion of building successful end-user features was foreign to everyone including me. We were traditionally a platform-only team, and while we deeply understood how to gather and act on developer signals, the world of running consumer-facing research, conducting usability testing, partnering with design, scoping MVPs, rolling out A/B tests, optimizing funnels, etc. was still largely unexplored. Here, a combination of hiring and self-directed learning helped a ton in building out this muscle for the team.

On the hiring front, everyone who joined the team was (by design) laser-focused on driving customer—be them end-user or developer—outcomes, had an inherent curiosity for understanding the types of problems that customers ran into daily, and were dedicated to ensuring that those problems were being solved in delightful and usable ways. This customer-focused mindset spread throughout the team like wildfire, and it brought me such joy to see folks on the team step up to share their learnings with others, encouraging them to run research, automate feedback triage workflows, and author/analyze experimental scorecards.

Behind the scenes, I frantically read as many books as I could on product management and dove deep into our team's telemetry and experimentation infrastructure, sharing as many learnings and frameworks as I could, and doing my best to lead by example to harness the team's passion and provide them with new tools for driving measurable customer/business outcomes. One point I always tried to land was the importance of both qualitative and quantitative signals in successful product development as the former were at times overlooked. Qualitative signals are useful for tasks like understanding user problems, assessing the usability/value/appeal of potential MVP solutions, and understanding why a customer performs some action once a MVP is released, while quantitative signals are useful for tasks like prioritizing early opportunities, informing which features are in/out of an initial MVP, and measuring how customer behavior is (or is not) changing in response to your MVP or subsequent A/B optimization tests.

Today, the customer-centric culture on the team is something I'm most proud of, and I attribute its rise to everyone rallying around user problems rather than solutions and collectively defining new norms for how to best build product.