Advice to a New People Lead¶
Who should read this¶
This guide is intended for scientists or engineers (or similar highly-trained, technically minded folk) who have recently become managers of other people. It's divided into two parts. The first part focuses on the emotional and psychological aspects of the transition to management. The second part focuses on practical tactics for coping with new and unfamiliar responsibilities.
This guide is a compilation of the things I wish someone had told me sooner. It's also just one opinion, and a snapshot of my outlook after two years of leading a small team and another three years of leading other team leads. It reflects my experience at a Very Large Biotechnology Company, but opinions are my own and do not necessarily reflect the opinions of said employer. Your mileage may vary.
This guide mostly focuses on the hard parts of the transition to management. If you're contemplating that move but haven't made it yet, I don't mean to scare you off. It's hard, but rewarding. It's also hard to know whether you'll like it without trying it for a while. It probably takes at least a year to get past the initial discomfort of change and really evaluate it. That said, if you want to go in with your eyes open, you may also find this guide helpful.
Your new day-to-day¶
As I went from graduate student, to postdoc, to researcher at a biotech company, the character of my day-to-day work changed relatively little. I designed experiments, read papers, wrote code, and sat and thought. When I had an interesting problem, I would often think about it from the time I woke up till the time I went to sleep -- in the shower, in the car, at home in the evening. Although I worked on projects with others, often closely, I still spent most of my day in quiet, solitary activities.
The similarity of these early researcher roles left me unprepared for how different my day-to-day would be as a leader of other people in those roles. I suddenly spent a whole lot of my day listening and talking, in team meetings and town halls and one-on-ones. (I didn't even know some of those terms before I got to industry!) I spent alarming amounts of time reading and writing emails, and making PowerPoint decks. On some days, I would struggle to find enough meeting-free time to eat lunch, or would accumulate unread emails and to-do items faster than I could deal with them. When I found time to start a technical project, I often went days or weeks between opportunities to work on it.
Initially, this left me frustrated and overwhelmed. As I got better at these activities, they became easier, but the activities themselves remained pretty much the same. I eventually realized this is just the nature of the job. Whether as a team lead in industry or an assistant professor in academia, leading scientists is a very different job than being a scientist yourself. The skills you developed to be a successful scientist or engineer are still important, even critical, to your success as a technical leader, but you will also need to develop a new and largely different set of additional skills that you probably didn't need before.
Things you might be feeling¶
The move to management was very emotional for me, in ways I didn't anticipate, and some of those feelings went on for years. Others I've spoken to have had similar experiences. I wish someone had warned me. Here's a small selection of things I've worried about:
- Imposter syndrome: I'm not qualified to do this job. I don't know what I'm doing. I don't know all the things my team knows.
- Lack of accomplishment: I didn't do anything valuable today / this week / this month. I didn't produce a tangible product from my work.
- Missing "the bench": I did email and meetings all day. I haven't touched a pipette / seen a plant / written code in ages.
- Fear of losing technical chops: I'm going to forget how to do the valuable and important things I spent so much time learning. The field will move on and leave me behind and outdated.
These are, as far as I can tell, natural and normal feelings to have. From the perspective of the average objective observer, however, these fears are generally unfounded -- you're doing just fine at your new job. In all likelihood, having these feelings is just part of the process. A few thoughts that might make you feel (a little) better:
Imposter syndrome: I once had a senior leader tell me, "I'm faking it till I make it", so more or less everyone feels this way at least some of the time. That's the "growth is uncomfortable" thing. Paradoxically, the Dunning-Kruger effect suggests that questioning your own competence is a positive sign. Also, it's the team's job to be technical experts, and your job to make sure they work effectively together and with others. It is not possible nor desirable for a leader to cover the full spectrum of technical expertise in the team.
Lack of accomplishment: the work of a leader is generally done at several levels of indirection, but with great leverage. It often takes a long time for the results to manifest (good or bad), and it's often difficult to be sure of how some outcome was affected by your actions. Yes, that's sometimes less satisfying than making a thing and showing that thing to other people. But over time, I think you get a little better at recognizing where you've made an important difference to the organization.
Missing the bench: as mentioned above, the day-to-day of a team lead is very different from that of a team member, and there's no getting around this. However, there is a lot of value in having team leads retain a technical element to their work; see below.
Fear of losing technical chops: in my experience, those technical skills don't atrophy all that quickly. And as a technical leader, you'll still need to stay current on the field. You may find yourself paying more attention to the big picture of papers, and skimming (or skipping) the methods sections, and that's OK. You should be focusing on what and why, and your team can cover the how.
The right way to stay technical¶
I have found that retaining a small amount of technical hands-on work, say 5 or 10% of my time, is really important to my overall job satisfaction. This is not uncommon, at least among leads of smallish teams. Many people, including very senior executives at my company, have also affirmed the great value to the company from having leaders continue to be connected to technical work.
However, there are right and wrong ways to stay technical as a team lead. Your schedule is now unpredictable, and sometimes you may go for weeks without much time for technical work. As a result, you should not claim any work that is on the critical path for your team's goals, or otherwise time-sensitive. The unpredictability of your schedule would put that deliverable in jeopardy.
Because you are off the critical path, though, you can step back and take a bigger perspective. While your team has deadlines to hit, you can evaluate new technologies and explore opportunities to improve current procedures and practices. You can take more risks on things that may not pay off, because technical work is not a core part of your business goals. You can identify inefficiencies that your team is suffering through stoically in the name of results orientation, and then you can do something about it. And you can keep yourself happy and engaged by continuing to learn and grow in a field you love. Like other aspects of your job, your technical work can be a lever that amplifies the effectiveness of your team.
What's my job?¶
As a leader, "what's my job?" is a surprisingly nuanced question. It's easy to list activities that a leader spends time on, but harder to articulate the objectives those serve. I've heard and read lots of answers. Some are right or wrong depending on the team, the situation, and the organization. None is definitive. But here are some possibilities to consider:
- Make the team work better: one leader told me, "My job is to make the team work better, which makes the science work better, which then makes the team better, and so on!" There are many ways to make a team work better, but they are generally people-focused, not technology-focused.
- Connect to the big picture: a leader should help the team understand how their work fits into the goals and priorities of the larger organization. Ideally the team members internalize this understanding.
- Human router: like a router in a computer network, an effective manager can leverage their broader perspective, relationships, and network to help connect the right people. People sitting a few feet from each other can be unaware that their projects are connected. You can make connections by virtue of talking to a larger and more diverse set of people than most individual contributors do.
- Shield the team: at Google they say an effective manager is a "shit umbrella" rather than a "shit funnel" -- in addition to communicating relevant information, they also deflect and filter out a lot of irrelevant distractions. Put another way, communication is work, and it takes time. If the leader does that well, it frees the team to focus mostly on technical work.
- Advocate for the team: communication runs two ways. A leader also manages outbound communication about what the team is doing, with whom, and why. A good leader will ensure visibility both for the team's work and for the key individuals involved in the work, to help them grow.
- Ask good questions: one executive told me his greatest value to the company was to question people's assumptions. He recognized that he couldn't be a deep technical expert in every project that came before him, but by probing assumptions and what-ifs, he could ensure the experts had thought through things thoroughly.
- Help the team develop: a core belief at my company is that all employees should put effort into becoming more skilled, knowledgeable, and capable over time. The details differ by person, but the manager is accountable for pushing each person to really think about what development is relevant to them, and pushing them to make time to follow through. A good leader also works to find opportunities for people that will help them accomplish their development.
- Hire the right team: hiring people is incredibly time consuming. It also has a slightly confrontational quality that can be unnerving. But hiring decisions are the most influential ones that a leader makes. They have long-lasting effects: turnover is very low at my company, and many people spend their whole career there. A great hire might contribute for 30+ years and become an influential leader themselves. A poor hire, on the other hand, is unlikely to be poached, unlikely to leave, and is very difficult to remove.
How do I know if I'm doing a good job?¶
I wish I had an easy answer for this. It's hard, for at least two reasons. First, as a new lead, you are mostly exercising skills that you don't have a lot of experience with. As time goes on and you gain experience, it becomes easier to tell where you're doing well and where you're missing the mark. After a couple of years, I'm definitely a better judge of this -- but it's still hard.
Second, it's hard because the work of a leader happens indirectly, and over longer time scales. If your team fails to deliver, you probably share in the blame, although it's possible you were the victim of bad luck. (Maybe you should have done more to guard against those possibilities?) If your team succeeds, you might share in the credit, but it's hard to be sure that you contributed, especially if you're new to the team. (The longer you're in a role, the more likely it is that you are at least partly responsible for the long-term success of that team.)
This is why, for instance, it's hard to evaluate the performance of Presidents of the United States. Economic gains and losses this year could be driven by global forces, or random chance, or the policies of a previous administration. War might have been brewing for decades, or have been thrust upon us. Even through the lens of history, it's hard to be sure how much to attribute to the leader.
All is not lost, however. First, you can ask the people around you for feedback. If your boss, peers, partners, and reports think you're doing a good job, you probably are. If they have suggestions, listen. Honest feedback is rare and valuable, especially as a leader. Second, you can look at your year-end ratings. At my company, these are determined by a panel of people (typically your boss and their peers), and are forced to a curve. Good results are a compliment that can't be faked, because not everyone can be above average. If you're short of where you want to be, double down on getting and understanding that feedback. Since the performance evaluation cycle only happens once a year, everyone needs to make good use of more frequent, less formal feedback anyway.
Why might you choose this life?¶
People want to become leaders for all sorts of reasons, some better than others. If the descriptions in this document sound fantastic to you, then congratulations. But even if they sound frighteningly different from a technical role that you currently love, there are reasons to consider the switch.
My favorite part of leading a team is developing others. (Hence this document.) When I can have a conversation with someone and help solve their problem, I feel useful. When I can help someone reach an understanding about their own career or goals or talents, I feel successful. When I can mediate a dispute or bring teams together, I feel satisfaction. When I see someone I hired starting to thrive, I mentally chalk up that person as part of my career legacy. I didn't know that this would be my favorite part of the job when I started, and I wouldn't have to be in a people leadership role to continue doing it, but the role affords me many opportunities to do this kind of work.
There are other aspects of the role that appeal to me also. I get to see a wider variety of projects than I would as an individual contributor. I spend my day interacting with other people, as part of a team. It's interesting, and fast-paced, and keeps me learning. It's also challenging, and stretches me. (Sometimes more than I wanted -- be careful what you wish for.)
A common motivation for a leadership role is to accomplish goals that are bigger than a single person. It's certainly true that you can do this as a team lead. For me, though, it's counter-balanced by the fact that my personal contribution to that larger goal was more diffuse and indirect. So I personally derive a similar amount of meaning from the indirect accomplishments of these large goals as I did from the more direct accomplishment of more limited goals. I suspect others experience this differently, however.
Some people think that being a leader means more autonomy and more power to make decisions. This is partly true, but in a large organization leaders are still quite constrained until they reach quite high levels. And even there, leadership is often more about herding the cats toward a consensus than it is about handing down The Right Decision from on high. And then you're responsible for the outcomes of the decision! I personally don't find this power to be all it's cracked up to be.
Finally, some people seek leadership positions for the status, recognition, and (frankly) money. I think this is unlikely to end well. As a leader, it's my job to make sure my team is motivated by being recognized appropriately. I do fewer concrete things that I could be recognized for as an individual. The organization also expects that I need to be validated through recognition less often. It's true that sometimes big, cross-organizational awards call out only the team leads instead of all the participants, but in general I find you get less recognition as a team lead rather than more.
As for money, being a team lead does not pay that much better than being an individual contributor. I would guess there's a 10-20% premium, and you probably won't see it until you're in your first leadership role for 6-12 months. (HR wants to make sure you're going to stay a leader first, because they never want to decrease anyone's salary.) The funding factor of the annual bonus is likely to have a bigger impact on your annual income. You will probably have at least one person on your team who makes more than you, either because of tenure or because they're a Fellow, etc. At higher levels of leadership, the monetary rewards continue to increase, but if you don't like the work of leading you're not going to reach those levels. (And even if you do like it, there just aren't very many such positions.)
Appendix: Tactical Advice for New Leaders¶
The rest of this document covers more mundane, nuts-and-bolts aspects of transitioning to a leadership role. My intent is to provide a table of contents to resources I have found helpful, as well as accumulated tips and tricks.
The training you WILL get¶
At the moment, my company doesn't really train new leaders on any of the stuff above, nor most of the stuff below. It's hard to blame them: there's an awful lot for new leads to learn, and they have to be selective. I still got nine days of training on people leadership through in-person classes. These were excellent, and covered topics like giving feedback, legal and HR considerations, what your team needs from you, the hiring process, and more. You should take advantage of such classes over your first 6 -- 12 months as a people lead. There are also some optional courses that I've heard good things about, like Crucial Conversations.
How to learn the rest of it¶
Of course, there's a lot of other stuff to learn. Thankfully, it's not exactly a new field -- humans have been leading other humans for a very long time. The field changes pretty slowly. Among other things, there are millennia worth of relevant writings on the subject. For example, this from the Tao Te Ching (Mitchell translation):
When the Master governs, the people are hardly aware that he exists... When his work is done, the people say, "Amazing: we did it, all by ourselves!"
Fortunately, your background has you well prepared for learning things from books! You know how to do this. For that reason, much of this guide is a reading list of books that I personally have found helpful. So much has been written around leadership that it's hard to sort out the best bits; I've read a good number of books that didn't resonate for me. You can take my list as a starting point, but ask other people's opinions too, and consult the hive mind of the internet. Even if you end up disagreeing with all of my advice, this guide may still be useful as a (partial) list of the skills you'll need as a manager.
Depending on your life experiences to date and the exact situation you find yourself in, some bits of leadership knowledge may be more important than others. One thing it all has in common is that leadership is a performance art. No matter how much you read about it, you have to do it -- repeatedly -- to convert it into muscle memory (so to speak) and really be able to use it on demand. Expect it to be hard at first, and to require practice before it comes fluidly.
For example, initially, I found being a people lead exhausting. I came home and collapsed, drained of energy and unable to think. A colleague told me you build endurance, and it gets easier. He was right. Just like running, after practicing every day, I found it much less tiring (and sometimes even invigorating).
Along those lines, you can't learn everything from books. You're going to need to talk things through with a more experienced leader, who can help you connect your day-to-day challenges to what you've learned intellectually, and who can provide some encouragement and emotional support. Ask your boss, and especially his or her boss, about potential mentors they can connect you to. You want someone who is close enough to the area you work in to understand the situations, but far enough away to be impartial and not have a personal stake in them. Formal mentoring programs can also be good ways to find these relationships. You need at least one mentor, but it wouldn't hurt to have two or three, particularly if they have different strengths you can leverage.
A first book¶
The first book I would suggest is High Output Management by Andy Grove, the former CEO of Intel. He does a good job of explaining what the job of a manager really is. Intel's culture sounds similar to that of my company, so he has a lot of useful explanations of why the company runs as it does. (Why do we have meetings? Why are there dotted line relationships? What are we trying to accomplish with performance reviews?) Grove thinks of anyone who influences others as a manager, so his definition includes many PhD-level individual contributors too. There is a slightly weird part of at the start of the book about what companies do, via an analogy to "the breakfast factory". You can safely skip this part if it doesn't connect for you.
To-do list management¶
One of the first things I noticed as a new lead was that I couldn't keep up with my to do list. I already kept a list on a pad of paper, but it grew so fast and got so large that it ceased to be effective. Personal productivity is a topic that inspires fanatical devotion to a huge variety of systems. I'll offer my system below, for what it's worth, but the important thing to know is that you're going to need some kind of system that works for you, and you will likely need something a bit more robust than you had before.
My recommendation is the classic Getting Things Done by David Allen. I like that he gets to the point within about 30 pages, and there's a flowchart at that point that pretty much summarizes the whole rest of the book. It's a quick read. His key insight for me was that there are different kinds of to do items: things I need to do now, things I need to discuss with people when I next see them, things I'm waiting on from other people, ideas that I'm not going to act on soon but don't want to completely forget, large projects that are need to be broken down into individual tasks, etc. By separating these into different lists, it's easier to focus on what specifically needs to be done next.
Another key insight is that there should be one and only one master list. To do items that come in via email or Slack need to be added to that list, not just flagged in place, or you'll never have a comprehensive view of everything you need to do. (I still struggle with this.)
There are a bajillion tools out there to enable the GTD system. Personally, I keep my list in Microsoft One Note, using the "tags" feature. I've customized them to To Do, Waiting On, Projects, and Ideas For Later. They each have their own color of checkbox and are mapped to a keyboard shortcut (Ctrl-1, Ctrl-2, …). I start a new One Note notebook each fiscal year (arbitrarily), but I have the search feature span all my open notebooks so I don't lose items that carried over from last year. Compared to paper, I like that I don't have to re-copy my list periodically as things get marked off and I run out of paper, plus it's easy to re-order things (by prepending with a date [mm/dd] for deadlines or an asterisk * for high priorities or a Name: for items directed at specific people).
However, I don't like using One Note in meetings or in one-on-ones, because people might think I'm multi-tasking (a.k.a. ignoring them), and typing can be noisy. So I also carry a paper notebook with a pen loop and bookmark ribbons (Eccolo Cool Jazz, if you care). I write my notes and to dos in here. The to dos get a square box □ in the margin, and then when I get a chance, I transfer them to One Note and color in the box in my notebook. If I think I'm going to need the notes a long time in the future, I take a photo with my phone, email it to myself, and paste it into One Note. The only drawback is that it's not full text searchable.
As a manager, your relationship to time is very different than it was as a "creative professional". As Paul Graham points out, most creative work requires large blocks of uninterrupted time to get into "the zone", while managers tend to have calendar-induced ADD on a 30- or 60-minute cadence. But since your life is now driven by your (Outlook) calendar, you should learn to use it effectively.
If you have a smartphone but have resisted putting work email/calendar on it, taking on a leadership role is likely to force your hand. As your calendar drives a larger and larger fraction of your life, and you have fewer chance to slip back to your desk and check your computer, the convenience of email and especially calendar in your pocket becomes almost irresistible. However, you may need other strategies in place at home to ensure that 24/7 access to work doesn't become a work/life balance issue.
Your calendar is not a to do list; see above for to do lists. Unless there is work that really has to happen at a very particular time, it probably belongs on your to do list, not your calendar.
You will start to have a lot of scheduling conflicts, where you need to move one meeting to accommodate another. One of my friends calls this activity "calendar chess", and it can eat significant amounts of time. First, don't feel bad about it, it just has to happen. Second, it's hard to make wise choices for others (or they for you) if all you see is little blue "busy" boxes. Outlook can be configured to make your meeting titles visible to everyone (my preference) or to selected people. It's not the default, but I highly encourage it.
If you need to make certain events private (doctor's appointment, meeting with HR), there is a small lock icon on each invite that will make it show up as Private Event. Use this as sparingly as you can -- there is little inherently private about the titles "doctor's appointment" and "meeting with HR", since a normal manager would be expected to have both at regular intervals. And since other people may have their calendars open even if yours isn't, try not to put anything sensitive in the meeting title in the first place (e.g. "Fire John Doe" is a bad meeting title!).
Good meeting titles are also helpful to all participants. Remember that it should be meaningful on your calendar and on the calendars of the recipients. "Ian/John -- monthly 1:1" is much better than "1:1 with John" or just "1:1" for everyone concerned!
If your reports are individual contributors, they still care about large blocks of open time. If you can put meetings with them at the beginning of the day, at the end of the day, or right before or after another meeting on their calendar, you reduce the fragmentation of their time, and they will generally appreciate it.
Outlook can color-code meetings, either manually using Categories or automatically using rules. My rules make recurring meetings green, one-off meetings yellow (because they tend to be more time-sensitive than recurring ones), reminders and tentative events gray, out-of-office purple, and events that are just me blue. I manually color particularly important meetings red and orange. It takes a little effort to set up, but helps me understand my days at a glance.
Once you get it all set up, make sure to save it as a custom View so that your settings can't get accidentally lost!
I try hard not to set up recurring meetings that create recurring conflicts. This is a little bit hard once you get a lot of them. One thing that makes it easier is using 4 week recurrences rather than monthly ones. You can stagger a 2-week recurrence and two 4-week recurrence in the same time slot, but months are frustratingly irregular and will drift in and out of sync with week-based recurrences. (Yes, I probably think too hard about my calendar.)
Finally, if you're a coder, know that you can interact with your Outlook calendar through Python code. I have some iPython notebooks that help me find good times for recurring meetings with others, and produce nicely-formatted lists of all my recurring meetings for reference. (This is sort of possible in Outlook but doesn't seem to work that well.)
My company has a lot of meetings, for better or worse. It's important to use that time as effectively as we can. The more people are invited to a meeting, the more valuable each minute needs to be -- there is a real opportunity cost to people's time. But even for recurring one-on-ones, it's important to spend a few minutes ahead of time thinking about what topics need to be covered.
I am far from an expert on this, though I know there are some basic principles. Send an agenda ahead of time, laying out what will be discussed and what decisions are needed. This helps people prepare, and prioritize in case of conflicts. Keep an eye on the time, and politely redirect tangents into a "parking lot". Send out notes and action items afterwards (as soon afterwards as practical). If slides were presented, include a link to the deck if possible.
As an organization, we're currently pretty spotty on this, and I'm as bad as anyone else.
As a new leader, you will need to establish a certain number of meetings to help you do your job. First, you'll want regular one-on-one meetings with your direct reports. An hour every 2 weeks seems to be the default, and that works pretty well. If your directs are people leads, you should meet regularly with their reports too; some call these "skip-level" meetings. I've found that 30 minutes every 4 weeks works pretty well for me. Other people prefer less frequent and possibly longer meetings.
Most teams will also need a team meeting of some kind, but some will not: it depends on the degree to which team members work independently of each other or are tightly coupled, and whether another meeting is effectively covering the same territory. Format and frequency vary wildly. At a certain size of organization, these meetings become "town halls" that have significant planning and orchestration requirements.
Keep it short.
No, seriously -- this is the golden rule. If you've ever been annoyed that your boss seemed to read only a fraction of the three-page email you carefully crafted, you will soon be more sympathetic. You may feel bad about it, but it will become a matter of survival.
If you want anyone to read and act on your emails, they need to be as short as possible. If the whole message fits in the subject line, perfect. You should probably re-iterate that one line in the body, just in case they're skimming. A short paragraph is fine. More than three short paragraphs is unlikely to get any meaningful response; see if you can break it up. One topic per email -- if you need to cover multiple things, send multiple emails. (This really helps people who use their inbox as a to do list, which you should try to avoid, but still.) If you need a question answered, then especially, one question per email. The question (or call to action) should be the last sentence, or there's a danger the recipient will get distracted from answering it by the time they've read to the end.
We would probably have fewer meetings if we took more time and mental energy for thoughtful written discourse. But as a culture, my company at least does not, so it's advisable to take that into account.
There is a lot of more generalized valuable advice on how to write clearly about highly technical topics. That advice also applies to email, incidentally. I highly recommend Writing from the Reader's Perspective by George Gopen. He used to each a fantastic multi-day course at Duke, but his books are the next best thing. His basic thesis is that how you structure your sentences and paragraphs has a huge impact on how easy they are to understand. If you match a reader's implicit expectations, good; if you violate them, not so good.
As a lead, you spend a lot of time communicating, and at my company that means PowerPoint. I like the approach advocated by Melissa Marshall. She's come to speak several times at my company, but you can get the flavor from her "Talk Nerdy to Me" TED talk.
Melissa promotes the assertion - evidence model of slide design. In this model, the slide title is a simple assertion of the slide's main message. The slide body is non-textual evidence in support of that message -- photographs, charts, tables, diagrams -- anything but text bullet points! The key is non-textual: if people are reading, they cannot listen to what you're saying. Conversely, if they're listening to you, they cannot also read your slide.
In a perfect world, you're always there to present your slides. In my company though, slides often get passed around long after the presentation. Thus, people fill their slides with text to make sure their message doesn't get lost. Melissa's suggestion is to put those notes in the text box below the slide -- that way you can see them during your talk (with Presenter View), and others can read them afterwards, but your audience doesn't have to suffer through them during your talk.
Playing to your team's strengths¶
A book I strongly recommend to new managers is First Break All the Rules. It focuses on the interpersonal aspects of getting the best from your team. A central idea of the book is that good managers tailor their approach to the strengths, weaknesses, and style of each individual employee.
Unlike many management books, this one is backed by a lot of data from research firm Gallup. It also aligns closely with Gallup's StrengthsFinder approach to evaluating people's natural talents. I find this a useful tool for understanding my own strengths, as well as those of my team. My teams have been most successful when I matched people's assignments to their natural talents and inclinations. They have been less successful when I miscast people in roles they were not suited to.
Making time for work¶
My company is a meeting-intensive environment. As a people lead, meetings will fill 100% of your work time if you let them. While meetings are actually work, and an important and primary component of your work in particular as a people lead, you need some time outside of meetings in order to be effective in your job -- to plan agendas, communicate action items, write slides, and so on.
The exact amount of time is up for debate. Some senior leaders seem to get by with as little as 30 minutes a day, though I'm not sure how. My feeling is that it's hard to be effective if meetings routinely occupy more than about 75% of your time. If you want to retain some technical work yourself, you probably need to keep meetings below 65% of your time. In a 40-hour week, that corresponds to 2 hours per day outside of meetings (25%), and one 4-hour block per week of technical time (10%).
An 8-to-5 marathon is inevitable on occasion, but if it happens for more than a few days in a row I either start dropping a lot of obligations or working at home as night to catch up, and I have found that makes me really cranky. Interestingly, there are large parts of your work that cannot be done outside that 8-to-5 window now, because even if you wanted to work nights and weekends, your employees generally don't. (If you can't set a good example on work-life balance, at a minimum you have to be clear that you don't expect others to match your schedule.)
There are two parts to managing your meeting load. The first is discipline. You do not have to go to a meeting just because you are invited. If you are not contributing anything significant and you are not learning anything valuable, you probably shouldn't be there. (Occasionally you might be acting as a symbol of leadership support, but there may be better ways to accomplish this.) If you're not sure why you've been invited or what's expected of you, ask the organizer. (They may have just been trying to be polite!) If the meeting is valuable, but you have a conflict, consider whether it could be delayed/rescheduled or whether you could delegate to someone else. Keep in mind that meetings are often more disruptive to individual contributor's efforts, though, so delegate thoughtfully. If you are chronically oversubscribed, consider whether you have over-committed and need to refocus.
The second part of managing your meeting load is practices that support discipline. If you want to do technical work, block a chunk of time for it on your calendar, several weeks in advance if need be, and then treat it with the same respect you would another calendar commitment. Mark it as a private event if other people won't respect that time. I know one person who has two 1-hour daily recurring events on his calendar, labeled "Work 1" and "Work 2". In any given day, he moves them around until the rest of the day is full, but they help him see visually when he's reached his maximum commitment. I have a tentative "Lunch time" block on my calendar every day, which helps me remember not to clobber other people's lunch (if possible) and to make sure that I eat while the cafeteria is open. I usually catch up on work during that time too, which is admittedly not ideal.
You will probably find yourself cannibalizing some of this reserved time for impromptu meetings/discussions that are critical for work you care about. If you do this a lot, you may need to build additional reserved time into your schedule.
Part of a manager's job is to ensure that items of work get routed to the right people to do them. In part, that means delegating things that someone else could do as well or better than you. It took me a long time to get comfortable with even asking people to do things, though, much less telling them to. Fortunately, the more you do it, the easier it gets. And you need to get good at it, because it's an unavoidable, core part of the job.
As a leader, you are responsible for ensuring your team understands their priorities. The saying goes, "If everything is high priority, then nothing is." Before delegating, look at the work with a critical eye. If it's not more important than existing priorities, it may need to be put on hold until more resources are available, or perhaps not done at all.
You will also probably find yourself "delegating" to people who don't report to you. If they are peers in the organization, you will have to influence and persuade them. If they report to your peers, you will often want to work through that peer, so as to avoid disrupting their carefully established priorities for their team. Even with your own reports, effective delegation usually relies much more on influence than on direct orders.
Roles & responsibilities (RACI)¶
Particularly in efforts that involve many people, chaos results unless everyone clearly understands their role. My company uses a model called RACI ("racy") to help communicate this. It's a well-known model that you can read about on the internet, though I don't know where it originated.
- Responsible -- the person who actually does the work. Multiple people can be Responsible for the same work, although it's better if the work is clearly divvied up.
- Accountable -- the person who ensures the work is done, on time. For clarity, it is critical that only one person be Accountable for the project.
- Consulted -- a person who both needs to be informed of progress and to have input into important decisions.
- Informed -- a person who needs to be informed of progress and outcomes, but does not need to have input into decisions.
The Accountable role is in some ways the lynchpin, and a role that you will play more often as a manager. RACI models can be hierarchical -- the project you are Accountable for delivering may be one component in a larger project that someone else is Accountable for. From their point of view, you are then Responsible for one component of their project. T here is much more to project management than RACI models, but it's not an area I know much about.
People are emotional creatures, and managing them is full of emotional conversations. Sometimes they get into heated arguments with each other. Sometimes they're unhappy with their job. Sometimes they quit for another job. Sometimes they're not meeting expectations, and you have to tell them so. Sometimes you're not meeting expectations, and they tell you so. None of this is fun or easy, but navigating it with tact and grace is part of the job. This is why soft skills are weighted so heavily in choosing people for people lead positions.
If you get in over your head, focus on active listening and understanding the situation. Be open to what is being said, but commit to as little as possible. Then go seek help and advice from your manager and/or your HR generalist. (You'll definitely need to build a relationship with your HR person as a manager, and you might as well start before there's trouble.)
If someone feels that you are in the wrong, err on the side of apologizing. Even if you believe you are basically right, there's almost always something you could have handled differently. Even if you wouldn't change your decision, you can always regret that someone was upset by it. Apologies don't cost you anything, and as long as they are sincere, can go a long way to mending fences.
The book Crucial Conversations by Patterson & Grenny is highly recommended in this area, as is a course of the same name. I don't have personal experience with either; I read a different book, but didn't think it was that well-written. This kind of course, plus what you learn in other trainings, will help you navigate these situations, including keeping your own emotional responses under control.
In my job, I don't do anything that fits my mental model of "business negotiation" -- haggling over prices, deals, contracts, etc. Yet I spend a lot of time working out compromises that respect the priorities of parties with conflicting interests, trying to find ways for everyone to benefit. From my perspective, negotiation is a subcategory of difficult conversations, and the same principles apply. Namely, seek to understand what's important to each party -- it's usually not the same for everyone -- and seek to frame situations from a neutral perspective that all parties can agree to. I thought that Getting to Yes by Fisher & Ury was a well-written treatment of the subject; it's a classic.
Strategy and tactics¶
Leaders like to talk about strategy, and new leaders are often told to think more strategically or less tactically. I found it difficult to decide what was strategy and what was tactics until I realized that the distinction was hierarchical, and a matter of perspective. My strategies are often my boss's tactics, and my tactics are often my reports' strategies. One mentor phrased it in terms of a multi-story building, "One person's floor is another person's ceiling." Thus strategy & tactics are a continuum stretching from the company's hundred-year vision down to the individual's hourly decisions. This is not to say there is no distinction: having just taken on broader responsibilities, new leads generally do need to broaden their thinking to match, and spend less time "in the weeds".
"Business acumen" is another phrase that gets thrown around without a lot of definition. It doesn't need to mean getting an MBA, or focusing on the arcana of corporate finance or contract law. It really just means thinking about the company as a money-making business rather than as a research organization. Coming from an academic lab and being employed in R&D, it's natural to think of the company as another kind of research institution. But that misses an important dimension of the company; indeed, misses the facets that allow the research program to exist.
Business acumen, at least initially, means understanding the basics of the business model. Who are our customers, and what do they want? How close are we to delivering that? What products and geographies drive most of our profits? Where are we losing money? Who are our competitors, and how do their offerings compare to ours? What do our owners (stockholders) expect of us, and how does that influence our decisions? What are our biggest threats? Biggest opportunities?
There are lots of opportunities to understand the business better, starting with the various town hall meetings and project reviews. As a manager, these are more relevant to you, because you have more need to understand the big picture. In my company, there are also a variety of special training programs. For most of these, you are nominated by upper management, typically at the director level.
Another good way to understand a large, complex business is to first understand a small, simple business. I grew up in an entrepreneurial family, joined a very early biotech startup, and started & run my own small business from grad school days. Those experiences help me in thinking about the much larger business I now work for. If you're so inclined, I highly recommend trying your own small side business. It could be as simple as selling the output of your favorite hobby at a craft fair or on Etsy, though folks with programming skills have lots of other interesting options for internet businesses that require little or no capital investment. If you'd rather be an armchair entrepreneur, I also enjoy the essays of Paul Graham, the writings of Patrick McKenzie, and his guides for Stripe Atlas.
-- Ian W. Davis, March 2018