climbing the leadership ladder: from manager to director to VP

Recently, I’ve been asked several times what I’ve found to be the difference of being a manager, a director, and a VP. Each of those roles is an interesting one with its own challenges. My thinking on this is heavily influenced by this blog post from Peter Merholz. In his post, he introduces what I think of as the three distinct modes of management: managing down, managing to the sides, and managing up.

Managing down is managing those who report to you, or through you if you’re managing managers or directors. Managing to the sides is working with your peers to communicate information, resolve issues, and make decisions. Managing up is the skill of giving your manager, whether they’re a C-level or a senior manager, the tools and information that they need to help you, your team, and your company be successful.

As a first-line manager, where you’re only managing individual contributors (ICs), almost all of your time is about enabling them to be happy and productive. About 60% of your time is directly managing them: keeping them on track, giving feedback, coaching them, making sure they’re working well together, etc. Another 30% of your time is managing to the sides: ensuring that you’re aligned with your peer managers, resolving conflicts, communicating status information, and removing roadblocks. The remaining 10% of your time is managing up: working with your boss to manage priorities, identifying additional resource needs, communicating status, managing the budget, asking them to remove roadblocks, and setting the strategy within your area of focus.

As a second-line manager (for simplicity, I’m going to call this “director”), where you’re only managing managers, your focus shifts. You’re no longer the one directly responsible for enabling a team of productive and happy ICs. That’s the job of the first-line managers who report to you. Now your role is to ensure that the teams who report to you are happy, productive, and working on the right things. For a director, I’d estimate that 40% of your time is managing down to the team: ensuring that your managers are being effective in their roles, coaching your managers in how to be effective coaches and leaders, communicating needed information, resolving issues, setting direction for your team, setting your team’s culture, and removing roadblocks within and for your teams. As a director, managing to your peers is more important than it was as a manager. I estimate that managing to the sides is about 40% of your job. This is ensuring that you and your cross-functional peers are aligned on strategy and prioritization, that you’ve got the right folks working on the right problems across your teams, and that you are removing roadblocks for your teams and for your peers’ teams. The last 20% of your time is managing up: working with leadership to set strategy, communicating needed information, advocating for your teams, identifying roadblocks that need leadership intervention, and so on.

As a third-line manager (for simplicity, I’m going to call this “VP”), where you’re only managing directors, your focus shifts again. Now your directors are the ones responsible for having their teams be happy, productive, and working on the right things. You are accountable for all of that, plus be part of the team responsible for setting corporate strategy, and delivering on the commitments that you are making on behalf of your team. This means that much less of your time is managing down, maybe 20% of it. Managing down involves is communicating strategy, coaching your directors, resolving conflicts within your organization and between your organization and others, setting your organizational culture as part of your overall company’s culture, and ensuring that your directors are aligned amongst themselves. Managing to the sides is still about 50% of your job. Now that it’s at another level higher, it is even more cross-functional. Now you’re setting strategy across the entire company, identifying opportunities for your company, setting policies, removing roadblocks across your org and for your partner orgs, and communicating needed information across the company. The last 30% of your time is managing up: working with the senior executive team on setting strategy, communicating, making decisions, representing the company, and so on.

Looking back at Peter’s original post, the percentages that he lists don’t match my experience. I think he’s underestimated the amount of time needed at each level to manage up and to the sides, especially at the lower levels. While Peter frames his thoughts in terms of design orgs, I’ve found in my conversations with other leaders as well as my own experience in managing engineers and product folks that it’s held generally true cross-functionally.

If the things that you love are communicating, unblocking, and coaching, you must do more of that at higher levels. The shift that you’re making at each level is that you’re more abstracted away from your core discipline, and that you’re seeing and making decisions on a much broader swath of the company and the business. You are responsible for making a lot more decisions, often with less information than you  would like. I’ve found it to be a lot of fun, and a lot of responsibility.

moving from mid to senior

When I think about what it takes to move to Senior Researcher, Senior Designer, or Senior Engineer, there are some traits that often don’t get captured very well in a career ladder or other career framework. The following are the most important differentiators to be great at the Senior level:

  • Don’t avoid the hard conversations. Great senior-level folks manage their own discomfort with the hard conversation. They make the conversation productive so that everyone can move forward.
  • Give actionable high-quality feedback. Great senior-level folks give appropriate feedback to those around them. That feedback is timely, actionable, and has the best interests of the person to whom they’re giving the feedback at heart.
  • Respond well to feedback. Besides giving great feedback, senior-level folks respond well to feedback, even when it’s not necessarily high-quality or actionable.

The more advanced that you get in your career, the more that the hard problems that you need to solve are people problems. Senior-level folks understand that their job is to successfully work with others.

Two of my favorite resources for managing hard conversations and feedback are Crucial Conversations and Thanks for the Feedback. Both books have practical frameworks and examples for handling difficult interactions.

improving the success of hiring efforts

I’ve spent much of 2022 in hiring mode: adding designers, researchers, product managers, and leaders to my team and my company. So far this year, I’ve interviewed well over 200 candidates, from those just about to graduate from college for their first entry-level role to highly-experienced leaders for director and Vice President roles.

When I’m the hiring manager, or the executive to whom the hiring manager reports, I do the following to improve the success of my hiring efforts.

First of all, I do most of the outreach to the most interesting candidates personally. Candidates almost always like talking to the actual leader of the team, not a recruiter.

For high-impact roles, I spend a lot of time on sourcing good candidates. I search for potential candidates, and share the results of those searches (both the positive and the negative) with my recruiter so that they can learn what I’m lookin for. I craft personalized messages, and I follow up on the messages that I send.

When I’m not actively hiring, I still spend time in places where the candidates I most want for my roles are the most likely to hang out so that folks know me and are more likely to respond when I am hiring later. Having a good reputation as a leader who is engaged and thoughtful means that candidates who aren’t actively looking are more likely to respond to me.

I make sure that I know what differentiates working for me, my team, and my company different than other companies. I share that with candidates so that they can better understand why they should choose working for me, my team, and my company over their other potential roles. I determine what matters to the candidate I’m speaking to, and talk up the points where working for me is most differentiated on those points from my competition.

I give feedback to high-potential candidates. Candidates often complain that they cannot get feedback during the interview process, so providing meaningful feedback is a further differentiator. As I strongly believe in giving actionable and timely feedback, it’s a way to show candidates how I live my beliefs. Seeing how candidates respond to feedback gives me additional data to use in my hiring decision.

Hiring is one of the most important things that I do as a leader. Getting it right is important to me.

making research more collaborative

Recently, I was talking to a new researcher who is struggling because they feel siloed off from the rest of their organization. “Is this really what research is like?” they asked me, after describing a research process conducted almost exclusively by themselves.

One of the things that I like the most about research is how collaborative it is. I shared several ideas for making research more collaborative, including the following:

  1. Make the planning process collaborative by involving others (other researchers, designers, PMs, anyone who is interested!) in the creation of your test plan. 
  2. Make the research phase collaborative by inviting others to your sessions, or asking others to take notes for you.
  3. In the days of working in-office, I used to bake cookies for my research days to incentive people to come and watch the sessions. While they were watching, I gave them a short questionnaire to fill out while watching the session. It was lightweight enough that it didn’t feel like the observers were being imposed on. Questions on it were:
    • What stood out to you the most?
    • What worked well?
    • What didn’t?
  4. Make the analysis phase collaborative through brainstorming sessions. Take the insights that you gathered during the session and run a workshop with colleagues where you identify themes and potential recommendations to address the issues identified.
  5. Make the outcomes phase more collaborative by scheduling watch parties, where you show some videos from your sessions. This could be one particular participant who had a lot of insight to share, or it could be a collection of clips that show a theme.
  6. If the designers who you work with have some kind of critique session set up, start attending them and sharing your research materials for critique there.
  7. If you have enough fellow researchers, create a critique session where you give and get feedback on your research plans, performance while interviewing participants, or final reports.

leadership lessons from Mike Kruzeniski

Tomorrow is the one-year anniversary of the death of Mike Kruzeniski. He’s been on my mind a lot in the past couple of months, not only because of this anniversary.

I got to know Mike when he became my boss. He was hired as the very first VP of Design and Research at Included Health. I was a bit nervous during my first few meetings with him, balancing making him feel welcome in his mid-pandemic start, showing the value of my research team, and helping him get acclimated to the new company. He quickly won me and the rest of our design and research teams over.

Mike cared deeply about the craft of design. He wanted design to be beautiful and powerful. He bonded quickly with the designers and encouraged them to uplevel their skills. He gave them space to be creative and to push the boundaries. He didn’t hesitate to roll up his sleeves and get into the details. The design team flourished under him.

I have to admit that Mike’s care for the craft of design gave me pause when he started. I’ve worked for multiple design leaders who pushed designers to greater heights of creativity, and in doing so relegated user research to doing nothing more than validation research to prove how creative the design team was. Not Mike: his support for user research was boundless. He knew when and how to use research. He understood the value of generative research. He knew how to talk about its value to the executive team. He never talked about the design team, but rather the design and research team. My research team loved him just as much as the design team did.

One of Mike’s top strengths as a leader was that he believed in his team. He didn’t second-guess. He asked coaching questions if he thought that something hadn’t been considered. He always made it clear that not only did he trust his team, but he was also all-in on their success. I was the beneficiary of the opportunities that he created for me to grow my skills. At first, I didn’t even realize that it’s what was happening, but quickly came to see the pattern in as I observed him do it for me and for many others across the design and research team.

In addition to his innate belief in his team, Mike was vocal in sharing that belief. If I ever admitted that I was anything less than completely confident that I was going to be successful in something, he was there to cheer and to support. One of Mike’s friends called him the antidote to impostor syndrome, a description that I must agree with. He gave ongoing feedback and advice while reminding me that he believed in me and had no doubts that I could do it.

Although I didn’t get nearly as much time with Mike as I was hoping to, I still learned so much from him. His leadership style has informed a lot of who I am as a leader today. When I was first offered the promotion to VP of Experience Design at Babylon Health a couple of months ago, I immediately wished that I could call him and get his thoughts on making that transition.

I wish I could call him and thank him for everything. I’ll have to try to do him proud instead.

goodbye, old friend

The iPod is what made me a Mac user. I am, and always have been, a music lover and collector. When digital music players first started coming out, I tracked them closely, but none of them were good enough for me to take the plunge.

Until the first iPod came out. I was a user research intern at IBM when it was launched, finishing up my MS degree. I coveted the iPod deeply. I finally bought one to celebrate my conversion to a full-time employee a few months later. At the time, I was running Linux on my ThinkPad, a configuration that had absolutely nothing compatible with an iPod. I had to buy a FireWire card for my ThinkPad, install Windows (!!!), and then install a third-party app to make it possible to read and write to my iPod because Windows compatibility wouldn’t come for another few months. I jumped through all of those hoops and more to use that iPod. I was so excited to have 1000 songs in my pocket. I carried it everywhere, I used it all the time.

The ease of use and attention to detail in the iPod is what convinced me to switch to a Mac. I already knew that OS X was really *nix under the hood, but I hadn’t really considered it before that. I finally bought an aluminum MacBook Pro a few months after that and never looked back. Being a Mac user and a user researcher is what got me recruited by Microsoft to work for what was then called the Macintosh Business Unit. I took the name of this blog from the first t-shirt that I got from that team (and, in fact, I’m pretty sure I’ve still got that shirt).

I haven’t used an iPod since I bought the first iPhone. Listening to music and podcasts is still my single largest use of my phone. Even though I haven’t used one in quite awhile, the announcement that Apple has discontinued the remaining iPod in its lineup makes me a little bit sad. Goodbye, old friend.

the jerk matrix

There’s always a difficult colleague. When trying to understand how to work with that difficult colleague, I think of the jerk matrix.

The jerk matrix is something that I came up with a few years ago when I worked with a particular cluster of difficult colleagues. I realized that some knew that they were being difficult, but others didn’t. I further realized that some cared that they were being difficult, while others did not. The matrix helped me better understand the difference between them, and to come up with coping strategies.

Those who don’t care that they’re difficult are, simply put, assholes. The difference between knowing and not knowing is whether they’re an outright asshole or an oblivious asshole.

Most importantly, the jerk matrix helped me understand when someone is difficult but working on it. If they both know and care, they’re awkwardly improving. They’re on the road to recovering from being a difficult colleague. On the other hand, someone who cares but doesn’t know that they’re being difficult is simply oblivious. They could get on that road to recovering if they can find enough self-awareness to know when they’re being a jerk.

Another good use of the jerk matrix is if you have that group of difficult colleagues. If you map where they fall on this matrix, you might find that they cluster in one quadrant. In that case, you’ve identified a failure mode of your company or team. It’s worthwhile to consider whether there’s a cultural problem that causes people to become that difficult colleague, or whether the culture has something that makes it attractive to people who are already that difficult colleague.

the inverse relationship of quality and quantity of candidates in the hiring funnel

In my previous role, I worked at a rapidly-scaling startup. I joined when the company had ~600 people. When I left in November 2021, the company had merged with another company, acquired a third company, and in total grown to ~2000 people. As a leader in the organization whose role is inherently cross-functional, in the span of 18 months, I interviewed over 500 candidates for roles across the company. That number includes hiring for the establishment and scaling of the research and content design teams.

Through that process, I observed an inverse relationship in the sources of candidates for my hiring funnel. The sources that had the highest quality of candidate had the lowest quantity of candidates, and vice versa.

My stack-ranking of candidate sources based on the quality of candidates is as follows:

  1. Candidates who I reach out to directly.
  2. Internal referrals from people who are on my team or very closely aligned with my team.
  3. Candidates who a well-trained recruiter reaches out to directly.
  4. Inbound interest after I have posted my opening to highly-targeted channels. These channels are those that are the most closely aligned with the role and level.
  5. Internal referrals from people who are aware of my team but not aware of what makes a good candidate for my team.
  6. Candidates who a naive recruiter reaches out to directly.
  7. Inbound interest after I have posted my opening to less-targeted channels, such as job boards for historically-excluded groups or for very senior leaders and managers who work in tech.
  8. Inbound interest after I have posted my opening to non-targeted channels, such as a LinkedIn post or Twitter post.
  9. Direct applicants via LinkedIn or my company’s jobs website.

If I were to stack-rank these sources based on the quantity of candidate, my listing is almost the exact opposite. Direct applicants via LinkedIn and my company’s jobs website far outnumber all of the other sources of candidates combined. When I looked at the funnel for the last person I hired, I had more than 50x as many applicants who applied blindly via LinkedIn and the company’s jobs website than I did from all of the other sources.

You probably noticed that I listed recruiters twice on my list. I’ve never been able to hand a job description over to a recruiter who I haven’t yet worked with and had them be highly successful in identifying the right candidates to reach out to. A recruiter who specializes in research and design roles has a higher success rate, but it still requires time and investment to learn more about me, my team, and what a successful hire for my team looks like. This education helps them when they talk to candidates. They are better able to represent me and my team to the candidate in their early conversations. When I’ve aligned with my recruiter on what great candidates look like, they reach out to fewer candidates, but those candidates are of much higher quality for my open roles.

Analyzing the quality and quantity of candidates in my hiring funnel helped me identify where I should allocate my time when hiring. In doing so, I was better able to optimize my job description to be a better representation of the role and a successful candidate, allocate my time to the activities that were the most likely to result in a high-quality candidate, and reduce the time that I spent on low-value activities.

the discovery problem in your career

A long time ago, I believed that merely doing great work was sufficient to get promoted, and that it was my manager’s job to not only know that I was doing great work but also to ensure that I got promoted for it. This is not true. As your career advances, and this is doubly true when you’re leading a team, the more that your success is measured in terms of others’ perceptions of you. You cannot wait for recognition to come to you. You have to tell others why you deserve recognition.

I know that this is not easy. It’s hard to know where to start. It’s sometimes hard to know when you’re being successful. It feels like getting people to understand the impact of your great work is taking away from you being able to do more great work. Not being able to concentrate on doing more great work makes you worry that you really are selling snake oil. But that’s not true. What you’re doing is enabling people to discover your great work and build on top of it. Help them understand why it’s great. Help them understand how it contributes to them doing great work.

In user experience, we know that one of the common challenges of any product or service is discoverability. I’ve experienced this many times. You get user feedback that says that the one way that you could make your product or service better is to do this thing really awesome. “But it’s already there! I spent months delivering that feature!” Not only is your user frustrated that they think they can’t do what they want to do, but also you’re frustrated that you spent all that time and energy developing the very feature that they need and they’re not actually using it. You’ve got a discoverability problem. You’ve got to figure out how to fix it so that your engineering effort isn’t wasted and your user can accomplish what they want to do. Fix your discoverability problem, and you’ll fix two different frustrations.

And it’s the same with your great work. It’s not enough to do great work. You’ve got to make it possible for other people to discover your great work, to understand it and how it’s a contribution, to be able to build on it. Don’t think of the time that you spend changing perceptions as a waste of time. Think of it as solving the discoverability problem in your career.

Apple Health app uses 1.6TB?

When trying to upgrade to the iPhone 12 Pro, I got an error message saying that there wasn’t enough space on my new phone. That was the beginning of a couple of days of troubleshooting, culminating in a couple of hours on the phone with Apple Support to try to figure it out.

A screenshot of iPhone Storage, showing 1.61TB of data in Apple Health

When I looked at my iPhone 11 Pro’s storage, the culprit was easy to spot: Apple Health says that it’s got 1.61TB of data. I have been working out a lot lately, but I don’t think that the data from my biking and my strength workouts is really that big.

That sent me to my Mac to see when my last backup was. I sync my phone with my Mac pretty frequently, so I thought that I’d be fine and could just use a recent backup. Not so: it turns out that my last backup to my phone was on September 16. September 16 coincides with another problem that I’ve been experiencing: ever since updating to iOS 14 on my iPhone 11, workout data from my Watch hasn’t been reliably syncing back to my phone. It seems to be okay with other workout apps, but not Apple’s Workout app. I’ve been using an app on my phone instead, which defeats the purpose of the Watch.

In doing my online research, I discovered others were having the same issue, but I couldn’t find any documentation of a solution. I called Apple Support. I have to give Apple credit: their tech support people are top-notch. The first agent did the basic troubleshooting with me, treated me well, and listened when I told her what I’d already done. She didn’t make me repeat steps that I’d already tried. When she was at the end of her expertise and had to escalate me, the second rep was just as great.

Here are the steps that we followed to get everything working again.

  1. Unpair my Apple Watch from my iPhone 11.
  2. Upgrade my iCloud storage to 2TB to accommodate the imaginary 1.61TB of data from Apple Health.
  3. Backup my iPhone 11 Pro to iCloud.
  4. Wait a couple of hours for my backup to upload. I had ~400GB of actual stuff on my iPhone, yours might go faster if you’ve got less data or faster wifi.
  5. On my new iPhone 12 Pro, have it restore from my iCloud backup. In Settings > iPhone Storage, I can see that my Watch has 75.2MB of data on it.
  6. Pair my Watch with my new iPhone.
  7. Restore the Watch from backup.

Per Support’s recommendation, I’m going to wait a week to make sure that everything is on my new iPhone as expected. Then I can delete that backup and downgrade my iCloud storage back to its normal tier.

Now I finally get to use my new iPhone 12 Pro! I got the Pacific Blue this time, which I like a lot more than the previous Midnight Green.

a Macintosh girl in a Microsoft world

© 2010-2024 go ahead, mac my day All Rights Reserved