This is the final post in a three-part series chronicling my reflections on what went well, what could have gone better, and what I learned in my first year as a manager.

The first post begins with a bit more preamble on the motivations behind this series, so without further ado, let's jump into what I learned.

What I learned

Looking back on the past year and change, it's challenging for me to succinctly distill all of my learnings into a single post. The ones I've included below were the most top of mind, but it's quite possible that I'll continue to add to this list over time.

Adapt your management style to the person AND the situation

The SLII framework that I learned about from an internal training was instrumental in shaping my early approach to leadership; it drove home the point that everyone has differing levels of competence and commitment to specific tasks, and that adopting a single leadership style in every situation (or for every person) greatly under-serves—and can even frustrate and alienate—people on your team. It also gave me a great framework to share with the rest of the team for assessing our collective strengths and weaknesses when it came to building both end-user and developer facing product.

As I mentioned briefly in a previous post, to run this assessment, I created a PowerPoint template with a single slide for each phase of the Discover, Define, Design, Develop, Deliver, and Debrief product lifecycle loop described by Cracking the PM Career. Each slide had a two-column table on it where each row was a specific activity that took place in a certain phase. There was then a blank cell beside each activity name where folks could add their reflections. I sent this template to everyone on the team and asked them to fill in each blank cell with a specific color that corresponded to a certain development level within the SLII framework:

From there, I took each person's reflections, and after making sure they were okay with having their self-assessments shared with the rest of the team, compiled them all into a single deck where each table had a column corresponding to everyone's answers. Here's a redacted version of our reflections for common tasks in the "Develop" phase:

This view, and the corresponding discussion that followed this exercise was eye-opening, as it helped the team identify where its collective strengths and areas of development were. As a second order effect, it also helped me (and others on the team) see where their strengths were unique so they could better identify opportunities to coach/learn from others. Following our discussion, I was also able to refer back to the PowerPoint deck we put together when considering who to hire to round out the team, and when trying to choose the best management style to help guide folks through various day to day challenges.

Beyond this, the SLII framework also complimented a second training I took from the author of The Coaching Habit by helping me understand when various leadership styles were most appropriate. For example, coaching was most useful in cases where both competence and commitment for a specific task needed to be developed, while a more directive leadership style (something The Coaching Habit refers to as one's "Advice Monster"), can actually come in handy when someone has low familiarity with a task, but is excited to run in the direction that you point them towards to get started.

Something several of my directs told me was that they appreciated the level of autonomy I gave them; I attribute that feedback directly to the fact that these trainings helped me understand where I needed to be hands on, where I needed to be more coach-like, and where I could let them run wild. If you're a manager at Microsoft or any other company where they're offered and have the opportunity to take these trainings, I cannot recommend them highly enough!

Be more of a peer and less of a boss

I came across this picture on Twitter the other day (the entire thread on driving alignment is worth a read) and thought it perfectly visualized another of my key learnings: be more of a peer and less of a boss.

As a firm believer in the fact that harnessing everyone's collective strengths and diverse backgrounds would empower the team to deliver the best possible customer and business outcomes, I knew I needed to foster a culture of openness, trust, and collaboration on the team. I wanted my directs to be comfortable bringing anything—from difficulties in their personal lives, to any size of problem at work—to my (and the rest of the team's) attention so we could work through it together. To encourage this at my level, I strove to remove as many power dynamics as I could (leading with context rather than control) by being as transparent/vulnerable/open to feedback as possible, trying my best to practice a coaching mindset, and making myself available for one-off conversations/meetings whenever they needed something.

This led to some great discussions around all sorts of topics like achieving inbox zero, managing tasks/todo lists, the mistakes that we made in a given week, running more rapid customer research, and increasing focus on DE&I on the team. Weekly team meetings pivoted away from top-down share outs and towards open discussions of whatever was top of mind, giving everyone the opportunity to bond and share their thoughts on whatever was going on in a particular week. The tone of 1:1s also evolved, with folks becoming comfortable sharing that they might be distracted at work because of something else going on in their lives, or opening up about a mistake they made, a decision they were unsure of, or a half-baked idea they had knowing that we could freely brainstorm and collaborate together on potential solutions.

To paraphrase a learning that stuck with me from Manager Tools Basics—a podcast that a friend who recently became a manager recommended to me—as a manager, you have the privilege and power to reach out to your directs at any time to be a boss (asking about project status, driving accountability on a deliverable, etc.). Because of this, you need to be intentional about carving out time and space to make yourself as accessible to your directs as they are to you. Showing up as a peer more frequently helps tremendously here.

Prioritize onboarding

Having a great onboarding experience is critical to making sure that people on the team feel welcome, comfortable, and productive as quickly as possible. Whenever new folks joined the team, I'd create a customized onboarding guide for them that covered the following:

1. A breakdown of who's who in the org - This started with the CVP in charge of our organization and summarized each org directly under him along with its function and its leaders. For the team that my skip-level manager ran, I'd introduce each engineering manager and supporting PM/PM manager in addition to their specific areas of ownership.
2. A breakdown of how we plan work - This included a link to our quarterly OKRs, an outline of what level of management had visibility into each level of our OKR cascade, a link to our framing document for the half, and a step by step breakdown of what activities the team typically participated in during planning.
3. A breakdown of how we shipped our product - This included instructions on how to download insider ring versions of our product and a summary of our release calendar/how to interpret it
4. An explanation of areas of ownership - This was split into short- and long-term projects. For short-term projects, each explanation included a pointer to KRs the new hire would be responsible for driving, a link to any relevant dashboards, top of mind work streams to jump into, links to relevant resources, and a breakdown of people they should get to know along with a one sentence intro for each person. For long-term projects, each explanation was limited to a paragraph or two providing some context and laying out some potential next steps (often running more user research or working with design to create some concept mocks).
5. On-ramp resources - I split this into "Team-Specific Resources", "Org-Specific Resources", and "PM-Specific Resources". The first two categories contained links to useful documents, All Hands recordings, wiki pages worth reading, etc. The latter category included links to slides/guides on role clarity and additional resources that folks could leverage to grow specific skills as a PM within our organization. Since everyone I ended up hiring was an internal transfer, I did not have a "Company-Specific Resources" section, but had I hired anyone externally, that would have been something to add.

As could be expected, this guide got pretty long. An idea I had after onboarding a couple folks to the team (sorry for not thinking of this sooner!) was to highlight key sections that I thought were critical to read first so that folks opening the guide for the first time knew where to start.

While it certainly took a while to put together these guides, the positive feedback I received from my directs and the short on-ramp times I witnessed signaled a strong return on investment. Earlier in my career, I had also run onboarding for Edge and had heard first-hand from new hires on the team who had not received an onboarding guide how hard it was to feel productive, cared for, and motivated. For that reason alone, putting in the extra time certainly felt worthwhile.

Favor transparency over shielding

This might be a controversial take (or perhaps a product of the fact that there weren't many situations that truly required shielding), but throughout my time as a lead, I made a conscious effort to lean into transparency as much as I could and avoid shielding the team from whatever might be going on around it.

I'll admit that this tendency was largely due to my own lived experiences. In the past, I've had managers who tried to shield teams I was a part of; while I know that they were looking out for the team's best interests, I found that despite their efforts, information typically had a way of flowing around them. This often led to more uncertainty and rumors as ICs on the team would huddle together and try to make sense of what little information they had in place of having the opportunity to have an honest conversation about it in the open.

Whenever something potentially controversial came up, I'd try to get ahead of it by bringing it up at our next team meeting, acknowledging the feelings of everyone in the room, sharing my own thoughts, and facilitating an open dialog. On more than one occasion, someone on the team had an incredible suggestion for something that could be brought up to leadership to help address the situation. In cases where my directs weren't comfortable going to leadership themselves, I was happy to act as the conduit to my management, sharing my directs' ideas anonymously and following up regularly to ensure that progress was being made. I'm super proud of the changes we were able to collectively drive throughout the broader team that stemmed from these discussions.

While it's possible that my bias towards transparency may have brought certain topics to light that would otherwise have gone unnoticed, I'd much rather that everyone on the team have a chance to discuss them transparently than to have the folks who happened to hear about them left wondering about what they mean for them or the rest of the team.

Set expectations and check in often

One thing I remember thinking as an IC was that I wished I had access to the same training managers got so I could better understand what my managers were learning, frame observations in ways that would resonate, and provide feedback to help them learn and grow in the new ways that they were focusing on. After becoming a lead, I unfortunately wasn't able to get any of my directs access to the trainings directly, but I'd still share my learnings with them in weekly team meetings and encourage them to hold me accountable whenever they saw me acting in ways that ran counter to how I wanted to develop as a manager. Writing down my leadership principles and sharing them with the team also helped folks understand what to expect from me and to point out weak areas as time went on.

A key learning for me in this space was to check in with everyone regularly on how I was doing. Beyond ensuring that my directs were able to provide feedback on how they wanted to be led and hold me accountable for any improvements I promised I'd make, I firmly believe that this process helped cement strong feedback loops within the team as well. The check-in meetings would often include back and forth discussions on what we both could be doing better to support one another and helped develop a sense of joint accountability. I'm so grateful for all the ways that my directs helped me grow as a leader, a product manager, and a human being.

Provide specific, actionable, and timely feedback as often as possible

One thing that I struggled with (and still struggle with, though I believe slightly less) early in my time as a manager was providing feedback. Much of the feedback I had received throughout my career had been fairly generic, often along the lines of "you're doing great!" or "just keep doing what you're doing", or "next time try doing <XYZ> instead". I don't fault the people who gave me feedback like this for doing it the way they did; giving specific and actionable feedback is hard unless you practice.

When I first stepped into a manager role, I tried to get into the habit of giving people positive feedback because that's much easier (though I still found it challenging to make specific at times) than negative feedback. Starting with positive feedback also helps build trust. The framework I typically tried to use for positive feedback went something like "Hey, great job with <situation>. In particular, I really liked how you <specific action> because it led to <outcome>." I'd typically send this over Teams right after I saw the behavior take place so that it helped reinforce the learning in my directs' minds.

Once I got into the habit of sending more positive feedback, I started to venture into constructive feedback. My framework for sending constructive feedback was similar to the one I used for positive feedback, and was heavily inspired by Manager Tools Basics. It typically went something like "Hey, I wanted to share some quick feedback for next time. When you <specific observed action> it causes <specific undesired outcome>. Next time, do you think you could try <new preferred action> instead?".

This removed any mention of the person themselves and focused the feedback entirely on the old behavior, the outcome it caused, and the new behavior that would work better. I'd still send this over Teams (something that made this whole process more challenging, IMO) and often wasn't great about checking in first to see if now was a good time for my direct to receive feedback; again, something about providing feedback over Teams made the best-practice question of "Hey, is now a good time for some feedback?" feel way more heavy/formal than it otherwise would have in person.

I still have a long way to go to be comfortable providing specific, actionable, timely, and frequent feedback, but I do think that I've come a long way from where I first started. If you have other tips for providing lightweight and effective feedback (especially in a hybrid workplace) please let me know; I'd love to learn more!

Be a learn it all

I know the term is over-used, but quite possibly one of the most impactful things I did as a new manager was to fully embrace the learn-it-all mindset. I made peace early with the fact that I had no idea what I was doing and turned to friends/the internet to try to find as many resources that I could leverage as possible.

I've had a few folks who are new to management reach out and ask me what resources I found most useful, so I wanted to share them here with you all as well. If there are others that aren't on this list that should be, please hit me up; I'm always looking for recommendations!

• The Making of a Manager: What to Do When Everyone Looks to You
• Inspired: How to Create Tech Products Customers Love
• Empowered: Ordinary People, Extraordinary Products
• The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback
• The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever
• Radical Candor: Be a Kickass Boss Without Losing Your Humanity
• 7 Powers: The Foundations of Business Strategy
• Playing to Win: How Strategy Really Works
• Measure What Matters, though FWIW, I've heard Radical Focus is a better OKR primer these days
• No Rules Rules: Netflix and the Culture of Reinvention
• Manager Tools Basics

Wrapping up

Whew, I definitely bit off more than I expected with this series, but I'm glad that I got these thoughts out on "paper". Beyond helping me reflect on my time as a lead as I transition back to an IC role for the time being, I hope that some of the things I've shared have also been helpful to you too! I'd love to hear what you found most useful or what you found most surprising and am always happy to chat about all things product/leadership. Please feel free to reach out on any of my social channels linked in the header of this site!

Until next time,

Scott