Book for new and aspiring software engineering managers about how to do the job effectively. Unlike an individual contributor, your output as a manager is basically the output of your team (plus others that you influence), so the job is less about your individual output, and mostly about getting others to achieve their full potential. Manager duties are to gather information, make decisions, nudging, and being a role model.
In your first week as a new manager, you should first get a picture of what’s going on in your team, and set up 1-on-1s with your reports. These should take place in a private area, and the first meeting is a good time to set expectations for the relationship. Take notes on progress that you can refer back to later.
Every manager needs to delegate work, with varying degrees of autonomy, but is still ultimately responsible for the quality and timely delivery of the work. You should be caring, but willing to confront issues that arise. People have different work preferences: some like stability and deep technical focus, while others desire novelty. You want them to feel engaged in their work, otherwise they are likely to leave and are less productive.
Performance reviews should be done every 6 months or so, it’s best to have it written down and sent before the meeting so it doesn’t come as a surprise. Use the meeting time to reflect on achievements, improvements, and future plans, also it’s best to have the salary discussion in another meeting and not get distracted.
Hiring is a balance between quality, price, and speed of hire. Initial ad on job board should include why they should work for the company, skills needed, and how to apply. Interview should be friendly and not too tense. Offer a fair salary, don’t lowball the offer, and don’t hire the candidate if you’re on the fence about them.
People leaving the company is also normal, this can be for good reasons (great opportunity somewhere else) or bad reasons (problems at current company). Sometimes you need to fire poor performers, do this by putting them on a PIP, but make it reasonably achievable and be prepared to keep them if they meet expectations.
Another manager’s job is shielding employees from “wobble” — uncertainty from above in the organization that cause unnecessary anxiety. Forcing people to work hard isn’t effective, in the current market they’ll just leave; you have to draw on their internal motivations. Adding engineers to a project also doesn’t help because of the increased communication overhead. When a project is late, communicate honestly and make a tradeoff between speed, scope, and quality. Also good to make sure your team’s output is visible to the higher-up management so they don’t think you’re slacking off.
Networking between teams is important, a useful setup is have a mentor relationship between a junior and senior. Another is “guilds” of people who are on different teams but share similar skills. Internal talks are good for letting other teams know what you’re doing, and short “lightning” talks are lower pressure for those less experienced in public speaking.
Overall, I found the second half of the book to be weak and full of generic advice that were basically common sense. In contrast, the first half (up to chapter 8) gave more specific advice non-obvious insights about the role of a manager.