The Manager’s Path by Camille Fournier

Yesterday I finished reading The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier. This is a must-have book for any software engineering manager and a great book for anyone who is even remotely involved with software engineering in any capacity. I liked the book so much that I immediately ordered her other book from Amazon 97 Things Every Engineering Manager Should Know: Collective Wisdom from the Experts. I also listened to all her talks in youtube as much as I could find. It’s not that she is an excellent writer but her content is very relevant to what we face as engineering leaders over the span of our careers.

Here is my key take aways from this book.

What to expect from a manager –

• One-on-one meetings
• Feedback and workplace guidance
• Training and career growth
• Good communication
• Debugging dysfunctions of a team

How to be managed –

• Spend time thinking about what you want
• You are responsible for yourself
• Give your manager a break – he/she is a human and will make mistakes
• Choose your manager wisely

Mentorship –

• Importance of mentoring junior team members
• Mentoring an intern –
  • listen carefully
  • clearly communicate
  • calibrate your response
  • plan the interns to present their work to the team at the end of the internship
  • only hire interns who are going to graduate in a year
• Mentoring a new hire –
  • onboarding
  • technical vs career mentoring
  • help build a network within the company
  • give candid advice, otherwise refuse to be a mentor

The Alpha Geek –

• Driven to be the best engineer
• Values intelligence and technical skills
• Sometimes takes credit for all of the team’s work
• Absolutely terrible managers, so don’t make them managers

Tech Leads may come out of different roles like systems architect, business analyst , project planner, software developer and team leader.  A tech lead –

• Understands the architecture
• Good communicator
• Good team player
• Continues to write code
• Leads technical decisions
• Provides mentorship and guidance to the team members

Project Management –

• Break down the work
• Push through the details and the unknowns
• Run the project and adjust the plan as you go
• User the insights gained in the planning process to manage requirements changes
• Revisit the details as you get close to completion

There is usually a decision point for engineers at their career to either move into management or stay in technical track. Some new managers may become Process Czar. But they need to be reminded of Agile Manifesto –

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Managing People –

• Taking on a new report –
  • build trust and rapport
  • create 30/60/90-day plan
  • encourage participation by updating the new hire documentation
  • communicate your style and expectations
  • get feedback from your new hire
• Communicating with your team –
  • having regular 1-1s
  • TO-DO list meeting
  • the catch-up meeting
  • the feedback meeting
  • the progress report meeting
  • getting to know meeting
• Delegate effectively –
  • communicate the goals and responsibilities
  • provide support and guidance
  • give autonomy
• Create a culture of continuous feedback –
  • know your people
  • observe your people
  • provide lightweight, regular feedback (both positive and corrective)
  • provide coaching
• Performance review –
  • give yourself enough time and start early
  • account for whole year, not just the past couple of months
  • use concrete examples, and excerpts from peer reviews
  • spend plenty of time on accomplishments and strengths
  • when it comes to areas of improvements, keep it focused
  • challenging situations, firing under-perfomers

Managing A Team –

• Staying technical
• Debugging dysfunctional teams –
  • not shipping
  • people drama
  • unhappiness due to overwork
  • collaboration problems
  • managing a former peer
• Act as shield (i.e. bullshit umbrella)
• Drive good decisions –
  • create a data-driven team culture
  • flex your own product muscle
  • look into the future
  • review the outcomes of your decisions and projects
  • run retrospectives for the processes and day-to-day
• Manage conflicts –
  • don’t rely exclusively on consensus or voting
  • do set up clear processes to depersonalize decisions
  • 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
  • don’t be afraid
  • do get curious
• Team cohesion destroyers –
  • the brilliant jerk
  • the non-communicator
  • the employee who lacks respect
• Project Management –
  • 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
  • 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

Managing Multiple Teams –

• Engineering Director is responsible for significant area of the technology team –
  • not expected to write code on a day-to-day basis
  • responsible for technical competence of the team via training and hiring
  • contribute to architecture and design efforts by asking business and product questions
  • smooth execution of complex deliverables
  • responsible for development / infrastructure standards, high velocity organizations, iterating on processes, recruiting, headcount management, handling vendor relationship, budgeting
  • strong leaders who set examples for cross-functional collaboration across divisions of technology
  • guiding the goal-setting process for all the teams
• Stay hands-on even if without writing code –
  • code reviews
  • debugging production issues
  • write blog posts for company’s engineering blog
  • prepare conference talks
  • participate in an open source project
• Manage your time –
  • prioritize tasks based on important, unimportant, urgent, not urgent quadrant
• Decisions and Delegation –
  • decide whether to do yourself or delegate based on simple, complex, frequent, infrequent quadrant
  • delegate simple and frequent tasks
  • handle simple and infrequent tasks yourself
  • use complex and infrequent tasks to train rising leaders by showing the way yourself
  • delegate complex and frequent tasks to develop your team
• Learn strategies to say no –
  • “yes, and…” instead of a direct no
  • create policies so the team knows what it needs to get a yes
  • “help me say yes…”
  • appeal to budget and time
  • work as a team to say no
  • say no quickly if you have to instead of agonizing
• Technical elements beyond code like team health –
  • frequency of releases
  • frequency of code check-ins
  • frequency of incidents
• Avoid dysfunction of shallow binding due to lack of creating shared team identity –
  • fragile to the loss of the leader
  • resistant to outside ideas
  • empire building
  • inflexibility
• Create durable teams –
  • resilient to loss of individuals
  • driven to find better ways to achieve their purpose
  • first-team focused – peers across the company
  • open to changes that serve their purpose

Managing Managers –

• Similar expectations as managing multiple teams
• Skip-level meetings
• The fallacy of the open-door policy
• Manager accountability –
  • unstable product roadmap
  • errant tech lead
  • full-time fire fighting mode
• First-time managers –
  • they need a lot of coaching
  • they may refrain from managing in fear of micro-management
  • lack of delegation resulting in overwork, so help them identify those opportunities to delegate
  • overwork and micro-management
  • cultivate willingness to learn and aptitude to become solid managers
  • accommodate HR trainings for managers
• Experienced managers –
  • make sure this person fits in with the culture fo your team – management tends to be a very culture-specific task in a company
  • industry-specific knowledge is less important than modern development best practices and ability to inspire creative product-centric engineers
  • collaborate on areas of difference – be ready to learn from them
  • help them embody company values
• Hiring manager –
  • hiring for managers is a multi-part exercise, similar to good engineering interview process – check for skills, check for culture fit
  • theoretically managers can bullshit you during the interview more easily than an engineering candidate
  • role-play one-on-one as part of the interview
  • ask about their management philosophy – if they don’t have one, that’s a red flag
  • if senior position, consider the candidate to give a presentation to a group of people – not to judge the content of the presentation but to know how good they are in answering questions posed by the group, structuring thoughts, getting up in front of an audience
  • abbreviated version of your standard technical interview for engineers
  • reference check
• Debugging dysfunctional organizations –
  • managing teams is a series of complex black boxes interacting with other complex black boxes
  • have a hypothesis
  • check the data
  • observe the team
  • ask questions
  • check the team dynamics
  • jump in to help
  • be curious
• Setting expectations and delivering on schedule –
  • be aggressive about sharing estimates and updates to estimates
  • learn from the past
  • cut scope towards the end of the projects to meet important deadlines
• Handling roadmap uncertainties –
  • 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 i.e. tech debt
  • understand how important various engineering projects really are
• Staying technically relevant –
  • oversee technical investment
  • ask informed questions
  • analyze and explain engineering and business tradeoffs
  • make specific requests
  • use your experience as a gut check, read the code if needed
  • pick and unknown area, and ask an engineer to explain it to you
  • attend postmortems
  • keep up with industry trends in software development processes
  • foster a network of technical people outside of your company
  • never stop learning

The Big Leagues  –

• As CTO, VP or head of engineering your first job is to be a leader –
  • information gathering or information sharing
  • nudging
  • decision making
  • role modeling
• Models for Tech Senior Leadership –
  • research and development (R&D)
  • technology strategy / visionary
  • organization
  • execution
  • external face of technology
  • infrastructure and technical operations manager
  • business executive
• Changing priorities
• Setting the strategy –
  • do a lot of research
  • combine your research and your ideas
  • draft a strategy
  • consider your board’s communication style
• Delivering bad news –
  • don’t blast an impersonal message to a large group
  • do talk to individuals as much as possible
  • don’t force yourself to deliver a message you can’t stand behind
  • do be honest about the likely outcomes
  • do think about how you would like to be told
• Handling a nontechnical boss –
  • don’t hide information behind jargon, and be careful with details
  • expect that you will need to run your 1-1s with your new boss, so come prepared with a list of topics
  • try to bring solutions, not problem to be solved
  • ask for advice
  • don’t be afraid to repeat yourself
  • be supportive
  • actively look for coaching and skill development in other places
• Working well with cross-functional senior peers
  • first-team focus
  • trust that your peers are actively trying to do their best for the organization
  • the cone of silence – disagree and commit
• The Echo –
  • you are no longer one of the team, you need to detach
  • lead effectively, people need to take your words seriously
  • be thoughtful about where you spend your time
  • be moral compass for what the organization should be doing
  • continue caring about the team as individuals
• Guiding with trust instead of running with fear –
  • practice relatedness – sense of belonging and safety
  • apologize when you screw up
  • get curious – don’t treat disagreement as undermining of your authority
  • learn how to hold people accountable without making them bad
• True north is the core principles in a functional role. For risk analysis –
  • having a single point of failure
  • having known bugs and issues
  • being unable to tolerate high load
  • losing data
  • putting our code that is undertested
  • having slow performance

Bootstrapping Culture –

• The tyranny of structurelessness –
  • it is task oriented
  • it is relatively small and homogenous
  • there is a high degree of communication
  • there is a low degree of skill specialization
• Understand your company structure –
  • people
  • age
  • size of existing infrastructure
  • risk tolerance
• Applying core values
• Creating cultural policy
• Writing a career ladder –
  • solicit participation from your team
  • look for examples
  • be detailed
  • use both long-term descriptions and summaries
  • consider how the ladder relates to salary
  • provide many early opportunities for advancement
  • use narrow salary bands for early-career stages
  • use wide salary bands when and where you have fewer levels
  • consider your breakpoint levels – up or out, senior engineer level
  • recognize achievement
  • split management and technical tracks
  • consider making people management skills a mid-career requirement
  • years of experience
  • don’t be afraid to evolve over time
• Cross-Functional teams
• Developing engineering processes, depersonalize decision making –
• Code review –
  • be clear about code review expectations
  • use a linter for style issues
  • keep an eye on the review backlog
• The outage postmortem –
  • resist the urge to point fingers and blame
  • look at the circumstances around the incident and understand the context of the events
  • be realistic about which takeaways are important and which are worth dropping
• Architecture review –
  • be specific about the kinds of changes that need architecture review
  • the value of architecture review is in preparing for the review
  • choose the review board wisely