Here are my highlights from a highly recommended book The Manager’s Path by Camille Fournier.

Management 101

• 1on1 meetings with your direct manager are an essential feature of a good working relationship.
• 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.
• Good managers know that delivering feedback quickly is more valuable than waiting for a convenient time to say something.
• Bring agendas to your 1on1s when you have things you need to talk about.
• When you want to raise, ask for it. When you want the promotion, find out what you need to do to get it. Your manager cannot force work-life balance on you. On the flip side, sometimes if you want a bigger job, you will have to work more hours to get it.

Mentoring

• Listening is the first and most basic skill of managing people.
• Mentoring new hires is critical. Mentoring an intern: give them a project and make them present the work.
• Alpha geek tries to create a culture of excellence but ends up creating a culture of fear. If you’re ever in a position to promote people to management, be very, very careful in giving your alpha geeks team management positions, and keep a close eye on the impact they have in that role.

Tech Lead

• 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 coach, is a common misconception that even experienced managers fall for.
• Tech lead is a leader, responsible for a software development team, who spends at least 30% of their time writing code with the team.
• I have a strong opinion on pushing people into management, which is that you shouldn’t do it.
• Real-life of a manager: when you only had a team you were able to balance things and still write code, but as your team has grown you’ve lost touch with the code. It’s troubling you as something you should be doing, but there’s no time.
• Successful leaders write well, they read carefully, and they can get up in front of a group and speak. Don’t forget to listen during all of this communication.

Managing people

• 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.
• Regular 1on1s are like oil changes; if you skip them, plan to get stranded on the side of the highway at the worst possible time. The default scheduling for one on ones is weekly.
• Some people assume that good relationships require very little attention, and spend all their time on their bad relationships.
• As much as possible, when someone does something that needs immediate correct feedback, don’t wait for the 1on1 to provide that feedback. The same goes for praise!
• When you strip creative intelligent people of their autonomy, they lose motivation very quickly.
• The worst micromanagers are those who constantly ask for the information they could easily get themselves.

Managing a team

• Leaders are capable of identifying the highest value projects and keeping their team focused on this project. In addition to focusing the team, they are capable of identifying headcount needs for the team and planning and recruiting to fill these needs.
• If you truly wish to command the respect of an engineering team they must see you as technically credible. You need to stay enough in the code to see where the bottlenecks in-process problems are. It’s hard to make up lost time when you stop writing code, and if you do it too early in your career, you may never achieve sufficient technical savvy to get beyond the role of middle management.
• Infrequent releases can hide the pain points such as poor tooling around releases, heavily manual testing, features that are too big, or developers don’t know how to break the work down.
• Project management rules of thumb:
  • Do you have 10 productive engineering weeks per engineer per quarter
  • Budget 20% of the time for generic sustaining engineering work across-the-board
  • As you approach deadlines, it is your job to say no
• Test of happy engineering team: “If you buy them pizza in the evening, will they stick around and socialize together, or will they race out the door as quickly as possible?“
• Whenever asked for an estimate, take your guests and double it.

Managing Multiple Teams

• The engineering director
  • is responsible for a significant area of the technology team. Leads engineers across multiple product areas, or multiple technology functions. He is not generally expected to write the code on a day to day basis. However, the engineering director is responsible for the organization’s overall technical competence, guiding and growing that competence in the whole team as necessary through training and hiring.
  • should have a strong technical background and spend some of their time researching new technologies and staying abreast of trends in the tech industry.
  • focuses on ensuring that we continue refining our development/infrastructure standards and processes to create technology that will deliver sustained value to the business. They are leaders for recruiting, headcount management and planning, career growth, and training for the organization. They’re responsible for creating and growing the next generation of leadership and management talent in the organization, and helping the talent learn how to balance technical and people leadership and management.
  • is a motivated, cross-functional collaborator, a very strong communicator, and has a positive public presence.
  • should spend the time to gain mastery of programming before moving up to management.
  • spends at least a solid half-day once a week completely free from meetings or other obligations and uses this time on some creative pursuit (blog post, conference talk, open-source project).
• One example of an important but not urgent task is actually preparing for meetings so that you can guide them in a healthy way.
• Engineers who don’t write tests often have a harder time breaking down their work.
• Frequency of changes is one of the leading indicators of a healthy engineering team.

Managing managers

• You must take the time to proactively hold skip-level meetings with the people who report to your direct reports (once a quarter).
• Learning how to hold managers accountable will be one of your biggest learning opportunities as you work at this level.
• A manager is accountable for the health and productivity of the team.
• Making the wrong person and manager is a mistake, but keeping her in that position once you’ve realized she’s wrong for it is a critical error.
• Don’t compromise on culture fit, especially when hiring managers. Many people are very reluctant to hire in management from outside, and for a good reason.
• Dedicate to 20% of your team schedule to “sustaining engineering”.

The big leagues

• It’s not about being the lead engineer, chasing the latest language or framework, or having the shiniest technology. It’s about building a team with the tools and attributes to build the best possible product for our customers.
• VP is an engineering role, CTO is not.
• In my experience, most people need to hear something at least three times before it really sinks in.
• As a senior-most person in an organization, you’ll be watched closer than you ever been watched in your life.

Bootstrapping culture

• Structure is how we scale, diversify, and take on more complex long-term tasks. It’s more common in small companies to see structure come too late.
• He describes the early start-up as 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 the risk of crashing at any moment, but you only take yourself down if 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. Finally, you graduate to a spaceship, where you can’t make quick moves and the course is set long in advance, but you’re capable of going very far and taking tons of people along for the ride.
• A complex system that works is invariably found to have evolved from a simple system that worked. Complex system design from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
• Culture is how things get done, without people having to think about it.
• Call them what you want pods or squads or pillars, but cross-functional product development groups are a popular structure for a good reason. By putting everyone who is needed to make a project successful together in one group, you help the members of those teams focus on the project at hand, and you make the communication for the whole group much more if active.
• Organizations that design systems, are constrained to produce the designs which are copies of the communication structures of these organizations.
• 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.