the-managers-path-by-camille-fournier.md

The Manager's Path By Camille Fournier

• Hands-on expertise is what gives you credibility

  • It helps you make decisions and lead your team effectively

• A manager who leaves you alone most of the time unless you specifically ask for help doesn’t seem so bad at all. P.16.

• Managers who care about you as a person, and who actively work to help you grow in your career. Managers who teach you important skills and give you valuable feedback. Managers who help you navigate difficult situations, who help you figure out what you need to learn. Managers who want you to take their job someday. And most importantly, managers who help you understand what is important to focus on, and enable you to have that focus. P.19.

• One on one meetings with your direct manager are an essential feature of a good working relationship. P. 20.

• Great managers notice when your normal energy level changes, and will hopefully care enough to ask you about it. P. 20.

• Being an introvert is not an excuse for making no effort to treat people like real human beings, however. The bedrock of strong teams is human connection, which leads to trust P. 21.

• [Behavioral feedback] the sooner you know about your bad habits, the easier they are to correct. P. 23.

• Keep track of this feedback, good and bad, and use it when you write your self-review for the year. P. 23.

• Asking your manager for advice is also a good way to show that you respect her/him. People like to feel helpful, and managers are not immune to this sort of flattery. P. 24.

• When it comes to your role at the company, your manager needs to be your number one ally. P. 24.

• Whatever kind of company you work for, expect that you are responsible, for the most part, for figuring out what types of training you want. P. 25.

• In whatever way promotions happen, your manager should have an idea of whether you are qualified to be promoted. P. 26.

• I also advise you to find the best managers and mentors you can, and watch them work. Try to find people to work for who push you to succeed but also reward you for success, who inspire you to stretch yourself. P. 27.

• However, you also want to spend a lot of time writing code, and getting really good at understanding how high-quality code is written. This will probably take a few years of focus, and you can’t rush it. P. 27.

• I encourage you to create and build a strong network of peers. P. 27.

• Developing a sense of ownership and authority for your own experiences at work, and not relying on your manager to set the entire tone for your relationship, is an important step in owning your career and workplace happiness. P. 29.

• As you go through various stages of your career, you’ll start to realize how much uncertainty there is in the world. P. 30.

• Use your manager to discover what’s possible where you are, but look to understand yourself in order to figure out where you want to go next. P. 31.

• Advocate for yourself. P. 32.

• Seek out feedback, including constructive feedback on areas to improve. When that feedback comes to you, take it graciously, even when you don’t agree with it. P. 32.

• [Asking for something] However, it’s the fastest way forward. P. 32.

• Asking for advice is always a good way to show respect and trust. P. 35.

• Strong managers know how to play the game at their company…Strong managers have strong networks, and they can get you jobs even after you stop working for them. P. 36.

• There’s a difference between a strong manager and a manager that you like as a friend, or even one you respect as an engineer. P. 36.

• Many organizations use mentors as part of their onboarding process for all new hires. P. 39.

• How do you create good, effective mentoring relationships without slowing development down too much? P. 41.

• [Becoming a good manager] Skills are listening, communicating what needs to happen, and adjusting to his responses. P. 44.

• Listening is the first and the most basic skill of managing people. P. 44.

• Listening is a precursor to empathy, which is one of the core skills wherever your career takes you. P. 44.

• One of the early lessons in leadership, whether it is via direct management or indirect influence, is that people are not good at saying precisely what they mean in a way that others can exactly understand. P. 44.

• Mentoring new hires is critical. Your job as a new hire mentor consists of onboarding, helping this person adjust to life in the company effectively, and building your and her network of contacts in the company. P. 49.

• Effective teams have good onboarding documents they provide to new hires. Things like step-by-step guides to setting up their development environments, learning how tracking systems work, and familiarizing themselves with the tools they will need for the job are crucial for new hires. P. 50.

• Adopt the mindset that network building is a worthwhile investment of your time and energy. P. 51.

• The best mentoring relationships evolve naturally and in the context of larger work. When a senior engineer mentors a junior engineer on the team in order to help him be more productive, they can work on problems together that are relevant to both of them. P. 52.

• The “alpha geek” is driven to be the best engineer on the team, to always have the right answer, and to be the person who solves all the hard problems. The alpha geek values intelligence and technical skill above all other traits, and believes these attributes should determine who gets to make decisions. The alpha geek usually can’t deal with dissent, and is easily threatened by those she perceives as trying to steal her spotlight or who might upstage her. P. 55.

• The alpha geek tries to create a culture of excellence, but ends up creating a culture of fear. P. 55.

• The alpha geek is usually an excellent, effective engineer who goes into management either because she was pushed into it or because she believes the smartest person on the team should be the manager. P. 55.

• At their best, alpha geeks can be inspirational to younger developers, even though they seem very intimidating. P. 55.

• Alpha geeks have a lot to teach you, if they want to, and they can design great systems that can be fun to help build. P. 55.

• The alpha geek believes that every developer should know exactly what she knows, and if you don’t know something, she will gleefully point out your ignorance. P. 56.

• Practicing the art of teaching can help us learn how to nurture and coach, how to phrase things so that others will listen, instead of just shouting them down. P. 56.

• Alpha geeks are often better off kept out of management and given more of a focus on technical strategy and system design. P. 57.

• What you measure, you improve. As a manager you help your team succeed by creating clear, focused, measurable goals. P. 58.

• …mentoring is work that takes time, but also yields valuable returns in the form of better employee networks, faster onboarding, and higher internship conversion. P. 60.

• Developing patience and empathy is an important part of the career path of anyone working in a team-based environment. P. 60.

• Your internship program is not a way for you to get extra work done in the summer; it’s a way for you to identify and attract talent. P. 61.

• …unconscious buildup can cloud our thinking and reduce our creativity. When we close our minds and stop learning, we start to lose the most valuable skill for maintaining and growing a successful technical career. P. 63.

• Mentoring provides a great opportunity to cultivate curiosity and see the world through fresh eyes. P. 63.

• While many people think creativity is about seeing new things, it’s also about seeing patterns that are hidden to others. P. 64.

• Software development is a team sport in most companies, and teams have to communicate effectively to get anything done. P. 65.

• Mentoring is a great way to build this network…don’t abuse the mentoring relationship. P. 66.

• Tech lead is not the job for the person who wants the freedom to focus deeply on the details of her own code. P. 68.

• …tech lead was to continue to write code, but with the added responsibilities of representing the group to management, vetting our plans for future delivery, and dealing with a lot of the details of the project management process. P. 69.

• Being a tech lead is an exercise in influencing without authority. P. 71.

• Becoming a tech lead required me to change my focus. Work is now less about me and working on the most technically challenging idea or the most fun project; instead, my focus I more on my team. P. 72.

• Having the technical chops and maturity is nothing, however, if you can’t figure out the biggest trick of being a good tech lead: the willingness to step aware from the code and figure out how to balance your technical commitments with the work the whole team needs. P. 73.

• It’s natural for humans to prefer activities they’ve mastered, so when you have to spend less time on your current talents in favor of learning new things, it’ll feel quite uncomfortable. P. 73.

• Your highest priority as a tech lead is taking a wide view of the work so that you keep the project moving. P. 76.

• The systems architect and business analyst role requires you to have a good sense of the overall architecture of your system and a solid understanding of how to design complex software. It probably also requires you to be able to understand business requirements and translate them into software. P. 76.

• Project planner role breaks work down into rough deliverables…Part of the challenge here is getting as much productive work done in parallel as possible. P. 76.

• The Stone of Triumph is a metaphor for achieving recognition only to discover that recognition comes with a heavy price. P. 78.

• The tech lead has a much wider scope of responsibility than the senior engineer in an individual contributor position. The tech lead is called on to help architect a project, and then to go through the steps of actually planning out the work. The tech lead is expected to make sure the team fully understands the project requirements, the work is planned, and the team is effective and performing well, all without necessarily having any management responsibilities and usually without any specific training. P. 79.

• As you move forward in your career, you need to understand how to break down work that has complexity beyond the scope of what you can do as an individual. P. 81.

• Project management isn’t something that needs to happen in detail for every single effort, and it’s overused in some organizations. I don’t even like hiring project managers because they often act as a crutch for engineers to use instead of learning to think through their future work and ask real questions about what they’re doing and why, and their presence means that you have more waterfall-style projects instead of an agile process. P. 82.

• Project management has to happen, and as a tech lead, you should be doing it when it is needed, especially for deeply technical projects. P. 82.

• Enforce the self-discipline to think about the project in some depth before diving in and seeing what happens. P. 82.

• We had thought through what success looked like, and we had identified some of the risks that might cause failure. P. 82.

• Take the trouble to explain the basic ideas of the problem space and the motivations behind my ideas. P. 83.

• Process Czars try to stop all work while they search for the perfect process, or constantly push new tools and processes on the team as solutions to the messier problems of human interactions. P. 101.

• If you go into a tech lead role and you don’t feel that you fully understand the architecture you are supporting, take the time to understand it. P. 104.

• Be a team player. P. 105.

• Determine which decisions must be made by you, which decisions should be delegated to others with more expertise, and which decisions require the whole team to resolve. P. 106.

• If one universal talent separates successful leaders from the pack, it’s communication skills. P. 107.

• Encourage participation by updating the new hire documentation. P. 117.

• Get feedback from your new hire. P. 119.

• Don’t make the fatal error of spending all your time with your problem employees and ignoring your stars. P. 124.

• If you see or hear about a direct report doing something you want to correct, try to approach that person soon after. The longer you wait, the harder it will be for you to bring it up, and the less effective the feedback will be. P. 131.

• Your time is too valuable to waste, and your team deserves a manager who is willing to trust them to do things on their own. P. 149.

• The habit of continuous feedback is training you to pay attention to individuals, which in turn makes it easier to recognize and foster talent. P. 151.

• Good managers have a knack for identifying talents and helping people draw more out of their strengths. P. 152.

• Writing and delivering a performance review

  • Give yourself enough time, and start early
  • Try to account for the whole year, not just the past couple of months
  • Use concrete examples, and excerpts from peer reviews
    • Forcing yourself to be specific will steer you away from writing reviews based on underlying bias
  • Spend plenty of time on accomplishments and strengths
  • When it comes to areas for improvement, keep it focused
  • Avoid big surprises
  • Schedule enough time to discuss the review

• Don’t confuse “potential” as it might be described by a grade-school teacher with the type of potential you care about. You are not molding young minds; you’re asking employees to do work and help you grow a company,. P. 160.

• Potential, therefore, must be tied to actions and value produced, even if it’s not directly the value you expected to see produced. P. 160.

• Upon hearing that someone is underperforming, many companies will have you write the person a document called a performance improvement plan. This is a set of clearly defined objectives that the person must achieve within a fixed period of time. P. 164.

• The Dos and Don’ts of managing conflict

  • Don’t rely exclusively on consensus or voting, as it may appear morally authoritative
  • Do set up clear processes to depersonalize decisions
  • Don’t turn a blind eye to simmering issues, and address problems promptly
  • Do address issues without courting drama
  • Don’t take it out on other teams
  • Do remember to be kind, it’s natural and perfectly human to want to be liked by other people
  • Don’t be afraid
  • Do get curious

• The real goal here is psychological safety - that is, a team whose members are willing to take risks and make mistakes in front of one another. P. 201.

• All the evidence in the world can’t change a person who doesn’t want to change. P. 204.

• Keep the feedback neutral but to the point if you are going to deliver it in the moment, in public. Note that this approach should only be used for behavior you feel is detrimental to the whole group. P. 205.

• Your first goal is to protect your team as a whole, the second is to protect each individual on the team, and the last priority is protecting yourself. P. 205.

• Ask for agenda items up front. Any sort of standard meeting that involves a group of people, whether it’s planning, retrospective, or postmortem, should have a clear procedure and expected outcomes. P. 225.

• The responsibility of keeping your teams successfully moving forward and happily engaged is on your shoulders. P. 225.

• Your attendance at these meetings is partially to pay attention to the dynamics and morale of your team. A happy team will feel energized and engaged. An unhappy or unmotivated team will feel drained and bored. P. 226.

• As a manager of multiple teams, you’re responsible for balancing breadth and depth of thinking, for knowing the details of your teams today but also looking at where you need to be going in the future and what you need to get there. P. 226.

• If your team needs a manager more than they need an engineer, you have to accept that being that manager means that you by definition can’t be that engineer. I know some people manage both, but you need to decide, if you’re going to suck at one, which one that will be. P. 227.

• A strong manager must develop effective strategies for saying no. P. 237.

• In this modern era, frequency of code change is one of the leading indicators of a healthy engineering team. Great engineering managers of product-focused teams know how to create environments where their teams can move fast, and part of moving fast requires breaking work down into small chunks. P. 249.

• A whole host of ills in a team come from not being able to release frequently. P. 249.

• I find that engineers who don’t write tests often have a harder time breaking down their work, and learning how to do test-driven development can help them get better at this skill. P. 252.

• Before you try to change everything to fit your vision, take the time to understand the company’s strengths and culture, and think about how you’re going to create a team that works well with this culture, not against it. P. 257.

• Durable teams are built on a shared purpose that comes from the company itself, and they align themselves with the company’s values. P. 258.

• What is a skip-level meeting? Put briefly, it is a meeting with people who report to people who report to you. Their purpose is to help you get perspective on the health and focus of your teams. P. 269.

• Skip-level meetings are a chance to hear the other side of the story, to get a reality check from the people on the ground. P. 271.

• Whenever you have experienced managers or first-timers reporting to you, there is one universal goal for these relationships: they should make your life easier. Your managers should allow you to spend more time on the bigger picture, and less timle on the details of any one team. P. 273.

• Learn how to hold managers accountable. P. 273.

• Don’t compromise on culture fit, especially when hiring managers. P. 285.

• Hiring for managers is a multipart exercise, and those parts are actually very similar to those of a good engineering interview process. First, make sure that the person has the skills you need. Second, make sure that she’s a culture match for your organization. The biggest difference between a management interview and an engineering interview is that managers can, theoretically, bullshit you more easily. P. 287.

• The skills of a manager are pretty much entirely based around communication. P. 287.

• A good technical manager will know what kinds of questions to ask that tease out the core issues and guide the group to a solid consensus. P. 289.

• Most new hires act in self-interest until they get to know their colleagues, and then they move into a group interest. P. 291.

• Sometimes there are problems that seem impossible to determine, and many people don’t have the patience to dig through layers of code (theirs and others’), log files, system settings and whatever else is needed to get to the bottom of something that happened only once. P. 294.

• In almost every model of motivation, people need to feel an understanding and connection with the purpose of their work. P. 300.

• You measure the manager on the output of his team, after all, and it is his responsibility to fix it if things are not going well. P. 302.

• You must always be aggressive about sharing estimates, even when people don’t ask, esp. if you believe that the project is critical or likely to take longer than a few weeks. P. 304.

• Another core element of agile software development is the emphasis on the learning from the past. P. 305.

• Don’t be afraid to work with your managers, tech leads, and the business to cut scope toward the ends of projects in order to make important deadlines. P. 306.

• When an engineer comes to you with an engineering project that she wants to do, think about framing the project by answering these questions:

  • How big is that project?
  • How important is it?
  • Can you articulate the value of that project to anyone who asks?
  • What would successful completion of the project mean for the team?

• P. 310

• Make sure that your teams get adequate time to finish up current work. Take the time yourself to understand the reasons for the move, and even if you don’t totally agree, do your part to help make those reasons clear to your team and help them understand the new goals. P. 311.

• Understanding the business and customer goals, you offer guidance as to which technical projects can achieve those goals within reasonable time frames. P. 315.

• A good leader shapes technology discussions to inject the strategic objectives and take into consideration the nontechnical implications of a technical decision. P. 326.

• I like to describe technology strategy for product-focused companies as something that “enables the many potential futures of the business”. P. 347.

• It’s not about actually deciding the product’s direction, but about enabling the larger roadmap to play out successfully. P. 348.

• I could show the engineering team a vision of where we would go as a technology platform, not just what the product roadmap looked like. P. 348.

• Nurturing that kind of connection, even at a superficial-seeming level, helps to reinforce that you do care about them and not just their current projects or work output; that you know they’re people outside of work. P. 360.

• Unfortunately, when you’re the leader, the dynamic changes, and those who may have fought back when you were an individual contributor will feel threatened by you as a leader. P. 362.

• When you get curious and learn how to turn that disagreement into honest questioning, you can learn more about other perspectives on the issue because your team will open up. P. 364.

• True North represents the core principles that a person in a functional role must keep in mind as he does his job. P. 366.

• A common failing of first-time CTOs is to underestimate the importance of being clear and thoughtful about the culture of the engineering team. P. 374.

• We do it because we want to learn from our successes and our mistakes, and to share those successes and encode the lessons we learn from failures in a transparent way. P. 374.

• Early startups attract people who are capable of dealing with extremely high amounts of uncertainty and risk in exchange for equally high degrees of freedom to operate. P. 375.

• A complex system that works is invariably found to have evolved from a simple system that worked. P. 381.

• When failures occur, examine all aspects of reality that are contributing to those failures. P. 381.

• Ironically, while luck plays a role in both failure and success, we often attribute failure to bad luck and success to our own actions. P. 381.

• But in complex environments where the needs of the group must override the needs of the individual, cultural values are the glue that enables us to work as a team and make decisions when faced with uncertainty. P. .384.

• Reach through the part of you that is shy about praising people or embarrassed to share your feelings, and go into the part of you that cares about the people you work with. P. 387.

• The stories that we tell as a community bond us together. P. 387.

• Understand what your company’s values are, understand what your team’s values are, and think about what you personally value. P. 389.

• Without any process, your teams will struggle to scale. With the wrong process, they will be slowed down. P. 405.

• One way to think about engineering processes is that they serve as a proxy for how hard or rare it needs to be for something to happen. A complicated process should exist only for activities that you expect to be rare, or activities where the risks are not obvious to people. P. 406.

• The exceptions to this rule are that code reviews can catch missing updates to comments or documentation or missing changes to related features, and code reviewers can sometimes tell when there is inadequate testing of the new or changed code. P. 409.

• Code review is largely a socialization exercise, so that multiple team members have seen and are aware of the changed code. P. 409.

• Use a linter for style issues. P. 410.

• Look at the circumstances around the incident and understand the context of the events. P. 411.

• Be careful not to give the impression that people need to solve every problem they identify in the course of the exercise. P. 412.

• People often want to have architecture review to prevent teams from signing new features poorly, but it is usually unrealistic to try to catch new feature design early enough in a small company, and it’s hard even in a larger company. P. 413.

• You probably don’t want to put a heavy process in front of a common activity like feature design. P. 413.

• The most important lesson I’ve learned is that you have to be able to manage yourself if you want to be good at managing others. P. 416.

• The more time you spend understanding yourself, the way you react, the things that inspire you, and the things that drive you crazy, the better off you will be. P. 416.

• Getting good at working through conflict means getting good at taking your ego out of the conversation. P. 416.

• Stay curious. P. 417