(Work-in-progress) Summary of “The manager’s path” by Camille Fournier.

This is more a set of personal take-aways than a full review of the book. If the ideas sound interesting, it’s often well worth reading the chapter in more depth for persuasive examples.

Intro

This is a beautifully organised book. As it explains, the chapters follow the path someone may follow during their career. As such it offers advice and explanation for each level and what you should be demonstrating for the next level. It highlights some anti-patterns and directly answers common questions.

Chapter 1 - Management 101

  • What you should expect from your manager
  • What your manager should expect from you
  • You are responsible - not your manager - for how you perform.
  • 121s are very important - don’t move them. If your manager misses them how about emailing them earlier “you look busy - are we still on, or how about tomorrow at 2pm?”, non-manager should be driving them more than the manager. As you become more senior they become more about projects than the person. Shared docs are useful. Not a status meeting - but perhaps can be about how a project is going (then focus in on a particular aspect which needs improvement and/or feedback)
  • Old adage of “bring a solution, not a problem”
  • Your manager is human - they have problems and bad days too. Help them, don’t expect the assistence to be in one-direction only. In fact I’d go further - as I read someone else “your job is to make your manager look good”.
  • You should demonstrate working at the next level before being promoted to it. (This is both a good expectation to have and avoids the “Peter principle” where people are promoted before they demonstrate and hence stop at the first level where they are incompetent)

Chapter 2 - Mentoring

  • Mentoring a new starter is an important role - not a chore
  • Mentoring takes time - ensure the mentor has sufficient time or get someone else
  • Mentor should ideally be on the same career path as mentoree, just further along
  • Mentoring helps develop the mentors listening and managing skills - it’s the first step to being a tech lead
  • Mentoring is not about demonstrating your knowledge, nor overruling mentorees. Listen to their suggestions and allow them to try alternative ideas
  • Listening - are you really hearing the intern - what’s difficult, what concerns them, what interests and motivates them
  • Communication - do they understand what the goal is and your expectations (e.g. how/when to ask for help)
  • Feedback - giving appropriate feedback. Giving only praise at first can help to build rapport, then later start adding in constructive feedback (for problems)
  • Interns - ensure everything & everyone is prepared for their arrival, have a specific project they should be able to easily do, get them to present it when they finish. Cut scope early to ensure they have something finished. If you are looking to hire interns afterwards they’ll need to be in their final year of uni.

Chapter 3 - Tech Lead

  • Time to step back from looking at solely technical issues.
  • Project management, what to prioitise, scope (creep etc), MVP, deliveries, risk management, tech debt management, architecture - all become increasingly important.
  • It’s about the team, not about you
  • Represent your group to management
  • “Influence without authority” - give others a chance to speak.
  • Understand the architecture and lead technical decisions. Write design docs and get feedback.
  • Planning is hard and takes time. Push through the details and unknowns until you understand it all to get more accurate estimates and milestones. This will allow you to check and show if/that you are on track. Don’t skimp this. Ensure it’s thought about in depth - dependencies, requirements - best to find out early.
  • Don’t forget to include testing, rollout, training, decommissioning etc.
  • Breaking down the plan into smaller deliverables (MVP, Agile etc) is a really good idea as it makes this much easier (and lowers the risk)
  • Adjust the plan as the project progresses - especially towards the end.
  • Don’t become a process czar! Communicate. No two teams or people are alike. People often respond better to a computer saying “you’ve not reviewed this” than a person chasing them.

Chapter 4 - Managing People

  • Regular 121s. Don’t move them, start weekly, can change later. Mondays/Fridays are bad days (holidays etc). Also see chapter 1.
  • 121s: shared doc - both parties add “I’d like to talk about” during the week. Keep notes. Check how you did vs last week. Mostly driven by reportee, feedback from manager. Stop 121s being stale - go for a walk, coffee etc.
  • Build trust and rapport. Understand the person - what motivates them? Do they care about tech/career/praise? As a person - how do they prefer to receive feedback (good or bad) - email/in person/in public. http://lara.hogan.me/blog/first-one-on-one-questions/
  • Create a 30/60/90 day plan with both personal and company goals
  • New hires: have new hire docs, get them to improve it. Ask for what was good/bad early before they become indoctrinated.
  • Set goals and delegate (don’t micromanage). Check teams understanding of what they think the goals are.
  • Use systems (e.g. git/jira) for status summaries before checking in with people. This also helps to ask useful questions “I see that… had problems?”
  • Treat the open sharing of information in a neutral to positive way. i.e. if you hear “bad news” this is a good thing (cf not hearing about it)
  • Continuous feedback - take notes about what people do well and badly (really useful for 360 feedback). Start with observing what went well (as it’s too easy to notice the bad and miss the good) - so find at least one good thing per person per week. Provide feedback regularly. Anything seriously wrong should have immediate feedback - don’t wait! Provide coaching - ask them what they could do differently.
  • Performance reviews - cover the whole period (not just last month) - much easier if you have 121s and continuous feedback notes. Use concrete examples. Include plenty of good and focus on just a few areas to improve.

Chapter 5 - Managing a Team

  • Engineering management is technical as well as people mgmt.
  • You should be delegating more work (not just adding mgmt work on top of existing work)
  • You need to be technically credible - both up and down mgmt layers
  • Stay sufficiently involved to see issues (e.g. tests are weak/slow or deploys brittle). e.g. 2nd code reviewer or minor changes
  • If managing a former peer, acknowledge that it’s awkward, give them more tech, take on more mgmt, be very cautious about overriding tech decision
  • Responsible for identifying bottlenecks and roadblocks and clearing them for the team
  • Identify highest-value projects and keep team focused on them. This means partnering closely with the product lead (scope, deliverables)
  • Roadmap - improvements and paying off tech debt - cost/benefit analysis, communicate plan up the chain
  • Set standards (e.g. how much unit testing)
  • Headcount - planning and recruiting
  • Holding people accountable for their decisions
  • Ensure decisions “pass the technical smell test”
  • Negativity can be fear - e.g. “deploy breaks”, poor docs, have a plan to improve these this
  • Too much work on - tactical debt, promise (and deliver) break after current project. Budget 20% time for maintaining code and fixing debt, 10 work weeks/quarter. “Doubling rule” for estimates (even better, add time to plan properly - but don’t overwhelm the team with detailed requests (it’s partly your job to estimate). As deadlines approach say “no” more often.
  • Collaboration issues with other teams - as manager you cannot blame them (it’s undermining them) - however you can gather actionable feedback from your team, or see how your team can help, or concentrate on your team’s problems. How much does the other teams issues really impact your team - and how significant is it? Meet with other team regularly, get actionable feedback from your team
  • Yes you should shield your team from crap happening elsewhere, unless it gives context (e.g. big sales deal, legal issues etc)
  • Don’t ignore trouble elsewhere (e.g. layoffs) - acknowledge them.
  • Create a data-driven cultture - this will help to justify your decisions (and sway them in your favour)
  • Everything is a product - so product manage “internal” products and tools just a PM would for an external product.
  • Look into the future - two steps beyond. e.g. plugable components, avoiding lockin - check with product team what changes they think might be important in future
  • Retrospectives - of sprints, of decisions, of projects. Create a learning culture (and one that’s not afraid to experiment and try something new)
  • Avoiding conflict - concensus can be useful (but think carefully if it’s appropriate - e.g. is it fair to vote out a project someone is passionate about?). Team adopted standards (and automated tools) can be useful to depersonalise conflict. Deal with simmering issues before they have a wider effect.
  • You are not a parent - don’t mollycoddle people, but do acknowledge everyone is human and errs. Be kind not nice. If something harsh has to be said, don’t hide it - make it clear but in a kind manner.
  • Don’t be afraid - of making a decision, of seeming too demanding, of people not liking us, of taking a risk. These things need to happen, hiding from them makes them worse. “Get curious” to work around this - are we delegating decision because others are better or becuase we are afraid of making the decision?
  • Psycological safety - people shouldn’t be afraid of other team members (of what they think, of asking for help, of trying something, of making a mistake). Do the team have coffee/drinks/chat together?
  • Rockstar jerks - tell them in private, but if needs be, call them out in public “please treat other kindly”. Priorities - protect the team, protect individuals, protect yourself (in that order)
  • Non-communication - often comes from fear, so deal with this first. Information should be out in the open.
  • Lack of respect (for you or team) - tricky, ask what they expect, may need help from your manager to resolve

Chapter 6 - Managing Multiple Teams

  • You should be the “technically savvy voice” (asking questions of both engineering and product teams to ensure the right decision - e.g. scaling too early?)
  • Cross-functional collaboration (short and long term roadmaps). Where do we need to be and how will we get there?
  • Ensure sustained deliveries (inc. that tasks were actually accomplished)
  • Manage vendor relationships and budgets
  • Create and grow talent in the team (coaching them and delegating to them)
  • Explain tech to non-tech and business direction to techs
  • Management has few quick wins (vs coding) - they often take time and patience. It’s often “plate spinning” and being overwhelmed is normal/expected/fine- remember you must prioritise and delegate
  • Frequent tasks - delegate (even if complex - it’s developing the team)
  • Infrequent tasks - maybe best to DIY (especially if quick)
  • Prepared meetings (e.g. agendas, people should walk in prepared, expected outcome)
  • Don’t skimp too many meetings - it’s essential to check the team dynamic
  • If people start reducing their hours, being quiet, taking breaks, something is wrong (might be personal however normally people would say)
  • Ensure tech lead gives detail in status update (no detail = problem), clarify goals, milestones. Project list shouldn’t change weekly.
  • Lack of energy in team - boredom, lack of say in decision making process
  • Saying No. Do it quickly - don’t stall. “Yes (we can) and (all we’ll need to do is delay the other project. Create a policy (preferably one that says what’s required to get a “yes”, rather than reasons to say no). “Help me say yes” (ask them to persuade you- e.g. what policy change). “Not right now” - budget or time constraints (don’t guarantee later). Teamwork - present a united front via other groups (e.g. CFO)
  • Team health: do they know what’s expected of them, do they have the equipment/info, do they have the opportunity to do a good job?
  • Measuring health: release cadence (if bad do timeline), release failures (what went wrong, where do we need more confidence (e.g. testing), ability to rollback), frequency of code check-ins, frequency of incidents. Measure these and also measure “code quality”.
  • Team happiness: not just about praise, more about ensuring that they can fulfil their potential (give them a challenge, something interesting and enough time/equipment/budget)
  • “Purpose-based binding” for team - they know their purpose and have shared values
  • Behavioural guidance - go home on time, don’t work/chat late/weekends.

Chapter 7 - Managing Managers

Chapter 8 - The Big Leagues

Chapter 9 - Bootstrapping Culture

Chapter 10 - Conclusion