Book: The Manager’s Path

“The Manager’s Path: A Guide fro Tech Leaders Navigating Growth & Change” By Camille Fournier

• See: “First, Break All the Rules”
• “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.”
• “The bedrock of strong teams is human connection, which leads to trust. And trust, real trust, requires the ability and willingness to be vulnerable in front of each other. So, your manager will hopefully treat you like a human who has a life outside of work, and spend a few minutes talking about that life when you meet.”
• “When you have a problem, instead of demanding that your manager solve it for you, try asking her for advice on how she might approach the problem. Asking for advice is always a good way to show respect and trust.”
• “A strong engineer may make a great mentor-manager to someone early in his career, but a terrible advocate-manager for someone who is more senior.”
• “Listening is a precursor to empathy, which is one of the core skills of a quality manager. You need this skills wherever your career takes you; even principal engineers with no reports need to be able to hear what others are really saying.”
• “Even if you have absolutely no interest in management, it’s very difficult to build a career at any company with multiple teams without building a strong network of trusted people to share information and ideas with. The workplace is built around humans and their interactions, and these networks from the basis of any career, whether it’s focused around management or individual technical contributions.”
• “Don’t hire interns who are not going to graduate in the year after their internship.”
• “Diversity in your internship program will translate to diversity in your new grad hiring, which in turn will translate to diversity in your organization.”
• “The idea that the tech lead role should automatically be given to the most experienced engineer, the one who can handle the most complex features or who writes the best code, is a common misconception that even experienced managers fall for.”
• “I sold the idea by focusing on the different impact this would have on individual team members. For some team members it was about having a more reliable service, for others it was about iteration speed, and for others it was about reducing the on-call burden so they could sleep through the night. When talking with my manager I emphasized the reduced operational overhead, which meant we could accomplish more features work as a team in the future.”
• “Teams often fail because they overworked themselves on a feature that their product manager would have been willing to compromise on.”
• Agile Manifesto
  • “Individual and interactions over process and tools”
  • “Working software over comprehensive documentation”
  • “Customer collaboration over contract negotiation”
  • “Responding to change over following a plan”
• “be careful of relying on process to solve problems that are a result of communication or leadership gaps on your team.”
• “My other piece of advice is to look for self-regulating processes. If you find yourself playing the role of taskmaster–criticizing people who break the rules or don’t follow the process–see if the process itself can be changed to be easier to follow. It’s a waste of your time to play rules cop, and automation can often make the rules more obvious.”
• “As with many of the manager pitfalls, an obsession with process an be related to a fear of failure and a desire to control things to prevent the unexpected. If you are honest and make it clear that it’s safe to fail and to be imperfect, that’s often enough to get your process czar to relax a little bit and let some ambiguity in.”
• How to be a Great Tech Lead
  • “Understand the architecture”
  • “Be a team player”
  • “Lead technical decisions”
    • “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. In all of these cases, make it clear what the matter under discussion is, and communicate the outcome.”
  • “Communicate”
    • “Your productivity is now less important than the productivity of the whole team. Often, this means that you pay the price of communication overhead. Instead of having every team member sit in a meeting, you represent the team, communicate their needs, and bring information from that meeting back to the team.”
• Managing individual
  • “How do you like to be praised, in public or in private?”
  • “What is your preferred method of communication for serious feedback? Do you prefer to get such feedback in writing so you have time to digest it, or are you comfortable with less formal verbal feedback?”
  • “Why did you decide to work here? What are you excited about?”
  • “How do I know when you’re in a bad mood or annoyed? Are there things that always put you in a bad mood that I should aware of?”
  • “Are there any manager behaviors that you know you hate?”
  • “Do you have any clear career goals that I should know about so I can help you achieve them?”
  • “Any surprises since you’ve joined, good or bad, that I should know about?”
• 1-on-1s
  • “If you interact with her [direct report] directly, you may not need a weekly set-aside time to chat.”
  • “A person who’s not good at pushing information up may need more face time to do so.”
  • “One of the topics of discussion in your 1-1s will be company news. Especially ini times of rapid change or uncertainty, make sure you take the time to answer any questions folks may have.”
  • “Often the list is somewhat artificial and made ip of things that could have been handled via chat or email. If you decide to adopt this style, make sure that the list you bring and the lists you encourage your reports to bring are meaningful for 1:1 discussions.”
  • “My goal in a 1-1 is first to listen to any thing my direct reports want to discuss. I want the meeting to be driven by them, and I want to give them space to bring up whatever they feel is important.”
  • “The downfall of the rambling 1-1 is that, if it’s left unchecked, it can turn into a complaining session or therapy.”
  • “try to keep notes in a shared document, with you the manager playing note taker. For each person you manage, maintain a running shared document of notes, takeaways, and to-dos from your 1-1s.”
• “If you’re micromanaging someone, chances are you’re doing it because you don’t trust that a task will be done right, or you want to very tightly control the outcome so that it meets your exact standards.”
• “Autonomy, the ability to have control over some part of your work, is an important element of motivation.”
• “On the other hand, delegation is not the same thing as abdication. When you’re delegating responsibility, you’re still expected to be involved as much as is necessary to help the project succeed.”
• “When you feel like you want to micromanage, ask the team how they’re measuring their success and ask them to make that visible to you on an ongoing basis. Then sit on your hands if you must, but wait a week or two to see what they give you. If they have nothing to share, it’s a sign that you may need to do a course correction, which probably means digging into more details.”
• “If you want to know the status of work, look at the version control system and the ticketing system. If you want to know how stable the system are, subscribe to information about the alerts, look at the metrics, follow what has happen in on-call. It’s OK to ask for status summaries and OK to use your team as a way of surfacing the most important information from all these sources, but use a light touch.”
• Common opportunity for improvements for individual contributors:
  • “Struggle with saying no to distractions and end up helping with other projects instead of finishing their own”
  • “Do good work but are hard for others to work with, tending to be overly critical or rude in meetings, code reviews, or other collaborative activities”
  • “Struggle to break their work up into intermediate deliverables, and don’t balance planning and design with getting things done”
  • “Work well with other engineers but do not work well with other departments or teams”
  • “Struggle to follow the accepted best practices of the team, cut corners, or otherwise do sloppy work”
• “I usually give people a printed copy of the review as they’re leaving on the evening before the review is scheduled.”
• “Real potential shows itself quickly. It shows itself as working hard to go the extra mile, offering insightful suggestions on problems, and helping the team in areas that were previously neglected. The person who has potential but isn’t yet showing equivalent performance is showing up for the team in a way that others do not, even if her work is slow-going. It’s rare o see someone with true potential in a company and poor performance, though you may see slightly below middle-of-the-road performance. Often the solution to this problem is to move the person to a place where his potential can be realized.”
• Questions to ask for preparing your team members for promotion:
  • “How are these decisions made?”
  • “How early do you need to start preparing packets?”
  • “Are there limits on the number of promotions that can happen in any given year?”
• “One of the basic rules of management is the rule of no surprises, particularly negative ones. You need to understand what a person is supposed to be giving you, and if that isn’t happening, make it clear to her early and often that she is not meeting expectation.”
• “It turned out, being a good manager isn’t about having the most technical knowledge. The work of supporting people was far more important to management success.”
•  “Sometimes, teams aren’t shipping because the tools and processes they’ve been using make it hard to get work done quickly. A common example is that your team only tries to release changes to production once a week or less, infrequent releases can hide pain points such as poor tooling around release, heavily manual testing, features that are too big, or developers who don’t know how to break their work down.”
• “For example, if overwork is due to (in)stability of the production systems, it’s your job as the manager to slow down the product roadmap in order to focus on stability for a while. Make clear measure of alerts, downtime, and incidents, and strive to reduce them. My advice is to dedicate 20% of your time in every planning session to system sustainability work (‘sustainability’ instead of the more common ”technical debt’).”
• “In a case where overwork is due to a pressing, time-critical release, remember two things. First, you should be playing cheerleader. Support the team however they need supporting, especially by helping out with the work yourself. Order dinner. Tell them you appreciate the hard work. Make it clear that they’ll have explicit break time after the push. Make it as fun as you can in the moment.”
• “Second, do everything you can to learn from this crunch period and avoid it the next time. But features if you can. Push back on the date if it’s truly unrealistic. Crunch periods will happen, but there is no reason they should happen frequently.”
• “So, yes, shielding your teams from distraction is important. Or, to put it another way, helping them understand the key important goals and focusing them on those goals is important. However, it’s unrealistic to expect that you can or should shield your team from everything. Sometimes it’s appropriate to let some of the stress through to the team. The goal is not to stress them out, but to help them get context into what they’re dealing with.”
• “When you have a product or business head, she should be accustomed to using data about the business, the customers, the current behavior, or the market potential to justify her decisions.”
• “For example, give that person data about team productivity (such as the time it takes to complete features) or data about quality measures (like how much time is spent dealing with outages, or the number of bugs found in QA or other releases).”
• “Taking the time to develop customer empathy is important because you’ll need to give your engineers context for their work. Developing customer empathy will also help you figure out which area of the technology have the greatest impact on your customers, and that understanding will guide where you invest engineering effort.”
• “the regular process retrospective has a lot of value for detecting patterns and focusing a reckoning with the outcome of decisions.”
• “This approach is more subjective than gathering data bout the team’s health, but it’s arguably even more valuable than many objective measures, because it comes from the things the team itself is noticing and struggling with or celebrating.”
• The dos and don’t of managing conflict:
  • “Don’t rely exclusively on consensus or voting.”
  • “Do setup clear processes to depersonalize decision”
    • “Start with a shared understanding of the goals, risks, and the questions to answer before making a decision. When you assign the ownership for making a decision to someone on the team, make it clear which members of the team should be consulted for feedback and who needs to be informed of the decision or plan.”
  • “Don’t turn a blind eye to simmering issues.”
  • “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.”
    • “It’s kind to tell someone who isn’t ready for promotion that she isn’t ready, and back that up with the work she needs to do to get there. It’s unkind to lead that person on, saying ‘Maybe you could get promoted,’ and then watch her fail.”
  • “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.”
• “You can encourage this by taking the time to get to know people as human beings and asking them about their extracurricular lives and interests.”
• “This is more than empty small talk; it fosters relatedness, the sense of people as individuals and not just anonymous cogs.”
• “When companies talk about hiring for ‘culture fit,’ they often mean they want to hire people they can be friendly with. While this can have some unwanted consequences, such as discrimination, it comes from a wise place. Teams that are friendly are happier, gel faster, and tend to produce better results.”
• “The best thing you can do for your team, in the context of having a brilliant jerk, is to simply and openly refuse to tolerate bad behavior. This may be one of the few instances where ‘praise in public, criticize in private’ is upended. When a person is behaving badly in a way that is having a visible impact on the team, and a way you don’t want your culture to mimic, you need to say something in the moment to make the standard clear.”
• “You’ll want to have tight control of your own reaction because delivering this in public is walking a fine line. If you seem emotional, it may undermine you. The offender may write off your feedback as just emotion, or you may come off as picking on the person. Keep the feedback neutral but to the point if you are going to deliver it in the moment, in public.”
• “Simply put, if your team member doesn’t respect you or her peers, why is she working there? Ask her if she wants to be working on your team. If she says she does, lay out what you expect, clearly and calmly. If she says she doesn’t, start the process to move her to another team, or help her leave the company.”
• Project management rules of thumb
  • “You have 10 productive engineering weeks per engineer per quarter”
  • “Budget 20% of time for generic sustaining engineering work across the board”
    • “By ‘generic sustaining engineering work,” I mean testing, debugging, cleaning up legacy code, migrating language or platform versions, and doing other works that has to happen.”
  • “As you approach deadlines, it is your job to say no”
    • “The only way to achieve these goals is to cut scope at the end of the project. That means that you, as the engineering team lead, will partner with your teach lead and the product lead/business representatives to figure out what ‘must-haves’ are not actually must-haves.”
  • “Use the doubling rule for quick estimates, but push for planning time to estimate longer tasks”
  • “Be selective about what you bring to the team to estimate”
• When joining a new company as a manager:
  • “First, get someone to walk you through the system and architecture, as well as the process for testing and release the software.”
  • “Spend some time getting comfortable in the code base, and start watching the code reviews or pull requests, if they exist.”
  • “By getting to know the code, the process for writing code, and the tools and systems your team use for their day-to-day, you will gain the understanding necessary for managing the team, and the technical credibility necessary for them to see you as a capable leader.”
• “Finally, even if you don’t intend to write much code, I strongly advise you to keep at least a solid half-day once a week completely free from meetings or other obligations and try to use this time at least partially on some creative pursuit. You might write blog posts for your engineering blog, prepare conference talks, or participate in an open source project.”
• “Managing your time comes down to one important thing: understanding the difference between importance and urgency.”
• “As a manager of multiple teams, you can win back a lot of time by pushing an efficient meetings culture down to your teams. Hold people accountable to prepare in whatever way make sense. Ask for agenda items up front. Any retrospective, or postmortem, should have a clear procedure and expected outcomes.”
• “During meetings, look around the room at your team and notice their engagement. If half of them are falling asleep, staring off into space, on their phones or laptops ignoring the proceedings, or otherwise disengaged, the meeting is wasting their time. Your attendance at these meetings is partially to pay attention to the dynamics and morale of your team.”
• Do I need to be the person who complete this work?
  • Simple and frequent: delegate
    • “Examples of simple and frequent tasks might include running daily standups, writing up a summary of the team’s progress each week, or conducting minor code reviews.”
  • Simple and infrequent: do it yourself
  • Complex and frequent: delegate (carefully)
    • “Strong managers spend a lot of their time developing members of their team in these areas. Your goal is to make your team capable of operating at a high level without much input from you, and that means they’ll need individuals who can take over these complex tasks and run them without you around.”
    • Examples: “Project management. Onboarding new team members. Working with product team to break down product roadmap goals into technical deliverables. Production support.”
  • Complex and infrequent: delegate for training purpose
    • “You may have a tech lead sit with you to write the performance review for an intern, or have a senior engineer provide feedback on how many new people he believe would be needed to support a project next year. Ask for help from above on these tasks until you feel comfortable doing them, but once you feel comfortable, start pulling in rising leaders to learn how they are done.”
• Warning signs:
  • “The person who is usually chatty, happy and engaged suddenly starts leaving early, coming in late, taking breaks to leave during the work day, staying quiet in meetings, and not hanging out on chat. This person is either having a major personal issue or getting ready to quit.”
    • “Regardless of the reason, you may want to have an honest conversation and try to get to the root of the issue before she resigns.”
  • “The teach lead claims that everything is going well, but skips your 1-1s frequently and rarely provides detail in his status updates. This person may be hiding something. Often what he’s hiding is that the progress is going far slower than anticipated, or he’s building something outside of the scope of the project.”
  • “A lack of engagement in meetings tend to mean the team isn’t engaged by the work or do not feel like they have a say in the decision-making process.”
  • “The team’s project list seems to change every week, depending on the customers’ whims that day. This team hasn’t thought about its goals beyond pleasing customers, and may need better product or business direction.”
  • “This team is more strongly identified by their day-to-day work and the system they touch than by the larger team or the company. They may be resistant to change their systems based on the needs of the larger team or the business.”
• Strategies for saying no:
  • “Yes, and”
    • “Responding with positivity while still articulating the boundaries of reality will get you into the major league of senior leadership.”
    • “Start mastering the ‘yes, and’ strategy for saying no, particularly when interacting with your boss and peers, and see how it often transforms contentious disagreements into realistic negotiations for priority.”
  • Create policies
    • “When you start repeating yourself, you have the basis for a reasonable policy. That policy consists of the hard requirements that must be met in order to say yes, and some guidelines for thinking about the decision. Making a policy helps your team know in advance the cost of getting to ‘yes’.”
  • “Help me say yes”
    • “works better for the one-off instances where there is no clear policy.”
    • “‘help me say yes’ means you ask questions and dig in on the elements that seems questionable to you. Often, this line of questioning helps people come to the realization themselves that their plan isn’t a good idea, but sometimes they’ll surprise you with their line of thinking.”
  • Appeal to budget
    • “Lay out the current workload in plain terms, and show how there is little room to maneuver.”
    • “But as I discussed earlier, when you give an implied promise that ‘not right now’ means that you’ll seriously do something ‘later,’ you need to be sure that later can actually happen.”
  • Work as a team
    • “Sometimes you will use your technical authority to say no in a way that is beneficial to the product team. Sometimes you will appeal to the finance department to help you say no to certain budget excesses. Playing good copy/bad cop can be a little bit dishonest, so use this sparingly, but it can be useful to lend your authority to a no and then be able to call in the favor when you need support for your own no in the future.”
  • Dont Prevaricate
    • “When you know that you need to say no, it’s better to say it quickly than to delay and drag out the process.”
    • “You’ll be wrong sometimes, so when you discover that you were too quick to say no, apologize for making that mistake. You won’t have the luxury to carefully investigate and analyze every decision, so practice getting comfortable with the quick no (and the quick yes!) for low-risk, low-impact decisions.”
  • Questions to help predict team productivity and satisfaction:
    • “Do I know what is expected of me at work?”
    • “Do I have the material and equipment I need to do my work right?”
    • “Do I have the opportunity to do what I do best eery day?”
  • “These heal signals–frequency of code release, frequency of code check-ins, and infrequency of incidents–are the key indicators of a team that knows what to do, has the tools to do it, and has the time to do it every day.”
  • Possible questions for skip level:
    • “What do you like best/worst about the project you are working on?”
    • “Who on you team has been doing really well recently?”
    • “Do you have any feedback about your manager–what’s going well, what isn’t?”
    • “What changes do you think we could make to the product?”
    • “Are there any opportunities you think we must be missing?”
    • “How do you think the organization is doing overall? Anything we could be doing better/more/less?”
    • “Are there any areas of the business strategy you don’t understand?”
    • “What’s keeping you from doing your best work right now?”
    • “How happy (or not) are you working at the company?”
    • “What could we do to make working at the company more fun?”
  • When having a people pleasers on your team:
    • “Help the person feel safer saying no and externalizing more decisions so he doesn’t take failure personally. Providing him with strong partners who can take on the task of determining the work roadmap is a good option. Sometimes people pleaser managers work well in agile frameworks because the team itself takes ownership of work planing. Create better processes for getting work scheduled that don’t rely entirely on the manager’s discretion.”
  • Managing outside your skills set
    • “Ask the person to teach you about the work she does. Sit down with here and treat her as if she were your mentor, the person to teach you the ropes for this job.”
    • “Make it clear to the person that your goal is to understand what she does so that you’re capable of appreciating it better.”
  • “Good meetings have a heavy discussion element, where opinions and ideas are drawn out of the team. If the meetings are overscripted,  so that no real conversations can take place, it stifles that creative discussion. If people are afraid to disagree or bring up issues for fear of dealing with conflict, or if managers always shut down conflict without letting disagreements air, this is a sig of an unhealthy team culture.”
  • Roadmap undertainty
    • “Be realistic about the likelihood of changing plans given the size and stage of the company you work for.”
    • “Think about how to break down big projects into a series of smaller deliverables so that you can achieve some of the results, even if you don’t necessarily complete the grand vision.”
    • “Don’t overpromise a future of technical projects”
    • “Dedicate 20% of your team’s schedule to ‘sustaining engineering'”
      • “This means allowing time for refactoring, fixing outstanding bugs, improving engineering processes, doing minor cleanup, and providing ongoing support.”
    • “Understand how important various engineering projects really are.”
      • “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?”

Advertisement