The Manager's Path
A must-read for anyone seeking leadership positions in the tech field or any senior dev who usually struggles with why the "best solution" is not always the chosen one. The book goes from how to be managed and basic management concepts to how to manage managers.
----
Below are some of my highlights (spoiler alert):
- Great managers notice when your normal energy level changes, and will hopefully care enough to ask you about it. - The bedrock of strong teams is human connection, which leads to trust. - ... second thing to expect from your manager is feedback. - The feedback you get from your manager will be somewhat public if it's praise, and private if it's criticism. - Good managers know that delivering feedback quickly is more valuable than waiting for a convenient time to say something. - The most mundane work can turn into a source of pride when you understand how it contributes to the overall success of the company. - When that feedback comes to you, take it graciously, even when you don't agree with it. - Especially as you become more senior, remember that your manager expects you to bring solutions, not problems. - Strong managers know how to play the game at their company. - 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. - People are not good at saying precisely what they mean. - tech lead job description ... "to continue to write code, but with the added responsibilities of representing the group to management, vetting our plans for feature delivery, and dealing with a lot of the details of the project management process. - The tech lead is learning how to be a strong technical project manager, and as such, they are scaling themselves by delegating work effectively without micromanaging. - Being a tech lead is an exercise in influencing without authority. - explaining (without PowerPoint!). I never hesitate nowadays to take the opportunity to explain basics and motivation to senior or junior members. It educates them without making them feel small. - Engineers who believe in the "right tool for the job" sometimes turn into process czars when they become tech leads, seeking out the right tool to solve all issues. - be careful of relying on processes to solve problems that are a result of communication or leadership gaps on your team. - How to be a great tech leader: - **Understand the architecture** - **Be a team player** - **Lead Technical Decisions**
- If one universal talent separates successful leaders from the pack, it's communication skills. - Practice repeating things back to people to ensure you understand them. - It's hard to accept that "new manager" is an entry-level job with no seniority on any front, but that's the best mindset with which to start leading. - 1:1 - Weekly means that you talk frequently enough to keep the meetings short and focused. When you meet less frequently, any missed 1-1s must be rescheduled. - But if you spend most of your time trying to get people to correct weaknesses. - Performance reviews go wrong because people aren't given time to prioritize working on them. - This will be easier if you keep notes on what has happened. - Copy of the review as they're leaving on the evening before the review. - One of the basic rules of management is the rule of no surprises. - engineering lead: the person who fills this role is expected to have a large impact on the success. In particular, leaders in this role are capable of identifying the most high-value projects and keeping their team focused. - Being a good manager isn't about having the most technical knowledge. The work of supporting people was far more important to management success. - Humans, by and large, feel good when they set small goals, and meet them regularly. - Try to stay positive and supportive of their efforts in public. - Is this an ongoing problem? Is it something you've personally noticed? Is this something many people on the team are struggling with? Is there a power dynamic or potential bias at play? - 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. - We refer to these employees as "toxic" because they tend to make everyone who comes into contact with them less effective. - 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. You'll want to have tight control of your own reaction because delivering this in public is walking a fine line. - You have 10 productive engineering weeks per engineer per quarter. - Be selective about what you bring to the team to estimate. - On predicting team productivity and satisfaction: - Do I know what is expected of me at work? - Do I have the materials and equipment I need to do my work right? - Do I have the opportunity to do what I do best every day? - On measuring health: - frequency of code releases - frequency of code check-ins - infrequency of incidents - Is your team working to its full capacity? Are your engineers challenged and growing? Is your product team excited by the progress you're making? - As you grow more into leadership positions, people will look to you for behavioral guidance. - people reporting to you: they should make your life easier - you don't know what you don't know - set the expectation up front that you'll hold her accountable for the team - every model of motivation, people need to feel an understanding and connection with the purpose of their work. - my job wasn't to be the smartest person in the room. It wasn't to be "right". Rather, my role was to help the team make the best possible decisions and help them implement them in a sustainable and efficient way. - We don't set up systems because structure and process have inherent value. 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. - the number of interactions necessary to involve everybody increases geometrically with the number of participants. This inevitably limits group participants to about five, or excludes some from the decisions. - Not everyone has to be able to do everything, but everything must be able to be done by more than one person. - On describes, the earliest startup is like driving a race car. You're close to the ground, and you feel every move you make. You have control, you can turn quickly, you feel like things are moving fast. Of course, you're also at risk of crashing at any moment, but you only take yourself down as you do. As you grow, you graduate to a commercial flight. You're farther from the ground, and more people's lives depend on you, so you need to consider your movements more carefully, but you still feel in control and can turn the plane relatively quickly. - If you want to learn from success, make sure you can identify the actual improvement you're seeking when applying those lessons more broadly, and that you understand the context required to repeat that success. - Culture is the generally unspoken shared rules of a community. - multiple levels, from entry-level engineer to executive, broken into four categories: technical skills, getting stuff done, impact, and communication and leadership. - Great managers are masters of working through conflict. - That decisiveness is a good quality, but it can hinder you when you fail to see your interpretation of a situation is just that: an interpretation.