Developing the Team as a Product Leader
1 May 2020 ‧ 11 min read
One of the crucial areas of responsibility for product leaders is building the team, and one crucial part of that is developing your team members. For an overview, read my high-level article on product leadership responsibilities, or continue reading for a deep dive on people development.
While hiring is crucial to get the right people on the team, by far more time of a product leader's time needs to be spent developing the team that's already there. Of course, if you hire great people, you shouldn't have to micro-manage them, but the approach "hire great people, then leave them alone" also doesn't work. Former Google and Apple exec Kim Scott writes in her book “Radical Candor”, which is one of the best books on people development in my opinion, the following on what happens if you ignore the high performers you hired:
If you don’t take the time to get to know the people who get the best results, you can’t understand how they want and need to be growing in their jobs at that particular moment in their lives. You’ll assign the wrong tasks to the wrong people. You’ll promote the wrong people. Also, if you ignore your top performers, you won’t give them the guidance they need. Every minute you spend with somebody who does great work pays off in the team’s results much more than time spent with somebody who’s failing. Ignore these people and you won’t, in short, be managing.
In this article, I am sharing some hands-on team development best practices:
- Foundation: building trusting relationships
- Setup: managing growth
- Execution: helping people grow
- Practicalities: one-on-one conversations
Foundation: building trusting relationships
The foundation for developing the team as a product leader has to be trusting relationships with each team member. Product development work is inherently creative. No matter how many practices and processes are put in place, it is never a matter of just executing a pre-determined set of steps. This means that leaders can never make all the decisions, and therefore a command-and-control, carrot-and-stick management approach doesn't work. Hence, mutual trust is needed.
Trust means that each party believes that their own best interests are taken into account by the other person. Trust is built up over time through consistency—making commitments and following them. The core mechanism to help the other person believe that you have their best interest at heart is pretty simple, though: you have to actually care about them. In the book “Trillion Dollar Coach” about former football coach Bill Campbell, who coached leadership teams across Silicon Valley, including at Apple and Google, this is summarized as “to care about people, you have to care about people.” In other words, managing is more effective and enjoyable when you genuinely care about the people.
This means investing time at the beginning of a working relationship and then continuously throughout the relationship to get to know the person—not just their work persona, but their whole self. While I am not necessarily saying that there should be no boundary between work and off-work—after all, we all need to switch off and decompress every now and then—it is also an illusion that there can be a Chinese wall between the two. What happens at work affects our personal life and vice versa, and it's often impossible to understand someone's purpose and motivation unless you understand where they came from on a personal and professional level.
Setup: Managing growth
Based on these trusting relationships, leaders need to help their team members grow and develop. For this, I believe you need both clear expectations as well as development goals, which complement each other.
Expectations codify what the team member's roles and responsibilities are. This is important for performance management, of course, but also simply for the employee's sake—if there are no boundaries to what the role could cover, then there's the risk of either endlessly growing responsibilities or misprioritizations and role conflicts. These expectations are meant to be general to the role, not specific to the individual (“a designer is expected to do X”, not “person Y is responsible for shipping feature Z”). Expectations don't have to be super strict and should leave room for self-organization of individual product teams, but they should set an overall framework. (One good question to formally answer through these expectations, for example, is “where do we tend to draw the line between product management and product design?”)
A more elaborate version of setting expectations is through a formal career ladder, which means defining expectations for various levels of seniority: what are the expectations from a junior designer, a mid-level designer, a senior designer, etc. These career ladders not only help define expectations for the current role but can also serve as criteria for promotion. Especially on small teams, having formally defined career ladders might be overkill, though—just a few bullet points for each role might be sufficient.
Career development goals are specific to each individual and based on what they want to achieve in their career. The goal document should contain steps the individual wants to take in order to grow, and form a mutual commitment: for the leader to create certain opportunities (project or role assignments, speaking opportunities, training, attending conferences,...) and for the individual to work on certain skills.
I personally like setting goals in a very simple format (just a few bullet points) on two different time frames: one near term (e.g., 6 weeks) and one medium term (e.g., 6 months). The near term goals should be steps toward the medium term goals. Every 6 weeks, you can assess of the goals were achieved and set new ones for the next 6 weeks. For example, a 6-month goal might be “get promoted to Senior PM”, and 6-week goals might be “take a UX course to improve UX skills” and “present a topic to the senior leadership team to improve presentation and stakeholder management skills”. These short term goals both commit both leader (pay for the course, provide the opportunity to present) and individual (take the course, prepare and give presentation).
Setting up good career development goals requires having established a trusted relationship and getting to know the person quite well, understanding their drives, objectives, and motivations beyond the obvious. Most people I have met on product teams don't have very strongly defined career objectives, let alone long-term ones. However, as a leader, you can't then just give up and only put marginal improvements in the development plan (or worse, skip it altogether), or you risk ending up with a team which is stagnating and demotivated. For more tips on drawing out career development goals, check this article about a simple three-conversation framework to do so.
It is the obligation of product leaders to create opportunities for their team members to tackle new challenges that help them grow. On the whole, people don't like to feel slightly bored at work, they like to be challenged. So don't hold back because you think something might be too hard for the team members. You need to believe more in your team than they believe in themselves. I have a visceral memory of an example. One project on my team had not been set up for success and was in a tough spot. It had no product manager on it, a designer and an engineer were working together directly, and a bunch of stakeholders from across the organization wanted to have a say as well. However, no one was moving in the same direction. The designer was prototyping and user testing one thing, the engineer testing feasibility of another, and the stakeholders were envisioning something altogether different. In my head, I saw a train wreck happening in slow motion and was trying to shepherd the project team members in the right direction myself. I was holding back from asking one of my product managers to join the team because I didn't want to burden them with a project where they had little context and that was in such need of repair. However, at some point I made that leap: I had to believe that one of my product managers would be more capable to fix this than me without sufficient capacity. I did put one of the PMs on the project, and in the end, the project turned out fine. The PM later told me that it was really scary at first but he was really happy to have learned so much from the experience (and I was glad that the train wreck didn't materialize). So it really paid off to believe in my people and trust them with difficult challenges.
Taken together, the tools in this section are an effective means for performance management. By performance management, I don't just don't mean annual formal performance appraisals. If product leaders do their jobs right, then no one on their teams should ever learn anything new about their performance during those appraisals. If expectations and growth plans are clear, and feedback is given regularly, then it should be obvious to the team member how they are performing. Hence, performance management is happening constantly in every conversation.
It is then important to recognize that with different levels of performance, sometimes different measures need to be taken. Firstly, for low performers, having the expectations clearly set is paramount. If the team member doesn't properly understand what is expected of them, they might fail to live up to those expectations. Once expectations have been clarified, the feedback around them needs to be crystal clear. It should come from a place of caring about the team member and wanting them to succeed, but should also be unambiguous where expectations haven't been met. Ideally, the person acts on the feedback and improves so that the expectations are met. If that doesn't happen, then it is best to part ways.
Average performers should not be forgotten. They need to be given the kind of guidance, feedback, and challenges that enables them to be exceptional one day. With these team members, it is especially important to understand their purpose, motivators, and what they want to achieve in life. The closer to their purpose their work can take them, the more likely will they be able to excel.
For high performers, it is important to distinguish between what Kim Scott in “Radical Candor” calls superstars vs rockstars. Superstars are on a steep growth trajectory, rapidly acquiring new skills or deepening existing ones. High performing superstars should be constantly allowed to grow and pick up more challenges and responsibilities. However, it should also be clear in the leader's mind that they might outgrow the team or even the company. In that case, don't stand in their way but make the most of them while they're there.
Rockstars have a slower growth trajectory. In contrast to superstars, who see their current role as a stepping stone to the next one, they are happy with their current responsibilities. They are no less important than the superstars—they are a reliable foundation for the team, solid as rock. High performing rockstars need recognition, first and foremost. Promoting someone out of a position they like might do more harm than good, but recognizing someone's expertise and contribution can take many other forms.
It's important to note that being a rockstar vs a superstar is not an attribute of a person, but can change over time as professional and personal circumstances change. A former superstar might start a family or have a loved one fall sick and become a rockstar. A rockstar might get assigned to a project that is more aligned with their purpose in life and become a superstar. So don't use these designations as labels.
Execution: helping people grow
If expectations are clearly set, growth plans established, commitments from those plans upheld, and people given the right challenges, the leader's job in developing their team is still not done. Team members should also be supported in the “how” of doing their jobs. This can range from giving and encouraging feedback, over broader coaching, to formal training.
Feedback is generally given in reaction to something that the team member has done. Feedback should of course be frequently given, close to the fact, and specific. It is paramount that feedback needs to come from a place of caring about the addressee and wanting them to succeed. It's also important to not make it about the person, but about the behavior. In terms of structuring feedback, I like the “situation—behavior—impact” framework.
Feedback should not just been given by the leader to their direct reports, but also encouraged among the team and peers. It might even be good to do a more formal 360 degree feedback collection every now and then (for example, once a quarter). This can also give the manager a good understanding of how their people are perceived by their teams. Since the majority of product work happens in cross-functional product teams, but product leaders most of the time aren't part of these teams and interact in different contexts with their reports, this is a critical piece of information for understanding someone's performance and success.
Coaching is really about helping people think through problems. In my mind, the best tools here are simply asking more questions to uncover the truth, as well as getting someone to write up a structured narrative about a problem, and then helping discover and fix the holes in the logic. For more information on coaching, I can only highly recommend Marty Cagan’s coaching series as well as the aforementioned “Trillion Dollar Coach”.
Formal training is often skipped completely in technology product teams, possibly because the environment changes so rapidly. There are, however, some easy ways to more formally help people develop skills. A simple one is sharing articles and books that are helpful, and perhaps even discussing them in a form of book club. Another one is peer sharing sessions, in which everyone on a functional team gives a 15 minute talk on a topic of their choice to their peers. It could be about something they are better at than others (for example, the most data literate product manager showing some tricks in the data analytics tool) or just something they have recently had success with (for example, a designer sharing with other designers how they pair with developers in their product team).
Even for expert-led trainings it can be possible to tap into internal resources, for example, a sales or finance person training product team members on business relevant metrics or a data scientist training on machine learning basics. Lastly, it is of course possible to use external facilitators for trainings. This can be helpful both for hard skills (e.g., technical skills) and soft skills (e.g., communication and collaboration).
Practicalities: one-on-one conversations
At the heart of developing the team should be one-on-one conversations between leaders and their direct reports. These meetings are primarily for the benefit of the team members, not the leaders—of course, any status updates and administrative matters can be covered as well for convenience, but not if they crowd out what the team member needs guidance and feedback on. Then-Intel CEO Andy Grove made the following point in his seminal book on tech company management, “High Output Management”:
A key point about a one-on-one: It should be regarded as the subordinate’s meeting, with its agenda and tone set by him.
Now, if the team member doesn't think that they have enough to discuss to fill the time of the one-on-one meeting, the leader should do more to understand the employee and their goals as well as establishing a culture where mutual feedback is accepted and expected. For more on this, I again recommend reading “Radical Candor”.
Some more logistical points about one-on-one meetings: to be effective, they should happen every week (every two weeks is acceptable for managers with lots of reports). They should be long enough to be able to get to the bottom of even “meaty” topics. I've found that early in the relationship with a report, at least an hour every week is good, going down to 45 minutes once there is more shared understanding.
One-on-one meetings should ideally have an agenda that both participants can add topics to (but remember, the meeting is predominantly that of the report). There are many ways that this can be achieved, but a shared (Google) Doc is often sufficient. Also, the participants should take notes—on paper or in the same document as the agenda—focusing especially on any commitments and action items. These action items can be for both participants: reports might have action items to do certain tasks (e.g., “run an analysis on X”, “explore direction Y”), and managers might have actions items to remove obstacles (e.g., “request budget to do X”) or create opportunities (e.g., “allocate the next project with higher technical complexity to the report”).
One last point: with very few exceptions, one-on-one meetings should be regarded as the most important meetings of a leader. Do not cancel or show up late unless really unavoidable, or get distracted by your emails while your report is talking. It is okay to step out of a meeting that is running long with the reason “I have a one-on-one meeting now”. Disregarding one-on-ones creates the feeling for the team member that they are being disregarded. Regular well-run one-on-one meetings, on the other hand, increase both performance and morale of the team.
Developing the team is often what product leaders spend the majority of their time on—for good reason. Team development is one of the highest-leverage activities product leaders can engage in. Every marginal improvement to your team members' skills and performance is going to add up and over time is going to have a compounding effect. Andy Grove reminds us in “High Output Management”:
Let’s say you have a one-on-one with your subordinate every two weeks, and it lasts one and a half hours. Ninety minutes of your time can enhance the quality of your subordinate’s work for two weeks, or for some eighty-plus hours, and also upgrade your understanding of what he’s doing. Clearly, one-on-ones can exert enormous leverage.
The tools in this article, along with the referenced books, can hopefully contribute to more effectively developing the people on your own team.
I hope this article was helpful. If it was, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.