Book summary - The manager's path (Camille Fournier)

2019-09-25

Summary of the excellent “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.

Introduction

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

One more level of abstraction between you and workers
Prioritize and maximize your leverage
Initially spend time checking details (recruitment, are 121s happening, project status, postmortems etc)
Identify problems pro-actively - don’t expect people to tell you until it’s too late
Skip-level meetings (121 with managers reportee) - feedback on missed opportunities, manager, business strategy (or if it doesn’t make sense)
Skip-level lunches can work well (many more people in one go)
Manager accountability - they should be making your life easier, bringing problems before they become critical (and not hiding problems)
People pleasers are bad - they’ll burn themselves out and won’t push the team to become truely excellent.
Listening to people’s concerns is good, but be careful not to amplify negativity
Hiring managers - skills + culture fit. Good idea to get potential reportees to ask them how they’d handle a (specific) past problem. Get references and ask if they’d work with the person again, also what they love/hate.
Cultural values is how people make decisions (if they value group interest above self-interest)
Handling teams outside your expertise (e.g. QA/ops) - get curious. You aren’t expected to know it all, ask them to teach you, to shouw you what they do so that you can appreciate it better.
Don’t ignore areas you don’t know - sooner or later you’ll have to and by then you’ll feel guilty about having avoided it. Start to fill in the gaps in your understanding and get acquainted with the team.
Debugging teams: check the data (check team dynamic, team chat, tickets, code reviews, code, meetings). Sit in some meetings (too many/long, dominated by manager or good discussion) - remember your presence changes the team dynamic
Ask questions: what’s the team’s goal, why is that the goal (business reason), do they influence choice of goal or how to accomplish it (motivation)
Jump in and help (not too soon), don’t undermine the manager, work alongside (mentor)
“Late” projects - often not late, but when mgmt dislike estimates or change their mind. So always share estimates (even when not prompted). Be patient and understanding if it is late - remind them people are working as fast as they can, look at opportunity to cut scope (features, don’t just add tech debt) or re-prioritise.
Estimates - even if inaccurate, they communicate complexity to the business and team. Identify up-front work that de-risks and reduces the unknowns - this helps the business to plan.
Roadmaps - be realistic about changes (how often has company changes priorities). Break down large projects into smaller deliverables (better to have it 100% complete than never done or 50% done).
Maintenance - dedicate 20%. Perhaps call it “sustaining engineering” (refactoring, bugfixing, improving process, ongoing support). Large improvements will need to be planned separately (and in addition to the 20%).
Championing engineering projects - get data to show why they are valuable (e.g. to deliver features faster, support new business requirements)
Push for engineering projects to be done early in planning to give engineers something interesting to do once they’ve finished the current project.
Staying technically relevant - you are accountable for making sure the team is placing the right technical bets. See how these investments have paid off (or not). Read the code, get someone to explain/walkthough an area you don’t know well.
Ask informed questions (of the team and business) - what’s working well, badly. What’s worrying people?
Analyze and explain engineering/business tradeoffs. When something is too technically difficult, or when it’s sub-optimal but business justifies it, or when technical change has business impact.
Make specific requests - focus on projects that’ll have the most impact, rebalance as needed.
Attent postmortems (and ensure they are followed up)
Network with peers outside the company - prevents insular thinking, keeps you up to date with trends.

Chapter 8 - The Big Leagues

Embrace and drive change (as needed) - this also means questioning how things are currently done
Not just about making change - create an organisatin that can follow through
You are the leader - what to do, where to go, how to act, how to think, what to value. Fast judgement calls.
Understand the current landscape - and the multitude of potential futures (and how to plan months/years ahead for them)
You can disagree with a decision and still deliver it well
High Output Management: information gathering or sharing (meetings, emails, identify key elements and disemminating them appropriately, nudging (by asking questions not giving orders), making decisions (especially with incomplete information or conflicting stories), being a role model for company values.
Job isn’t to be the smartest person in the room - it’s to help the team make the best decision and get the best outcome
Technology alone doesn’t make a happy or productive team
VP of engineering is more about execution, CTO is more about tech and business strategy
CTO must both guide tech to meet and anticipate business challenges. Also where tech can create new business.
Find biggest tech opportunities/risk and meet them - recruitment/retention/process/… Risk management (what’s acceptable, what isn’t)
Push direction of business - tech arm shouldn’t just be an “execution arm”
Prioritise by making changes - postpone or kill other work, hire more people, etc
Say everything three times - say it in person, email it, ask them about it, say it in a team meeting
Sell all change as a good thing (even if you disagree, if it’s late, or urgent)
Don’t just too quickly to fix everything - often things resolve by themselves (but third time it’s raised, do something)
Equally, if you raise something, expect to do it three times before the escalation happens
Setting strategy - find pain points, expected growth, tech landscape, which areas to concentrate (front end, backend, mobile, sales support), consider possible future directions. Work down to the detail for the next 1-3 years, tech stack, team structure, data silos.
Presenting strategy - consider audience (detailed slides or talking slides)
Deliver bad news personally, give them time to absorb and ask questions. Ensure people are onboard even if they don’t love it. You must back the message (even if you don’t like it). Be honest, don’t sugarcoat.
Non-tech boss - solutions not problems, but don’t hide bad news, ask for advice.
Peers - they own their areas, don’t offer advice unless asked. You must trust them (and they must trust you). They aren’t being irrational no matter how it might seem, be aware of analytical/creative spectrum.
Disagreement between peers should not be visible outside the leadership team. Commit to the decision.
Detach from your old team, socialise a bit, then leave them to it. They need breathing space (and you need to avoid potential “favourites”). Is a throwaway comment their boss talking or idle chat?
You are the role model - what you do is by definition “good”, so behave in ways you want others to emulate.
Small talk is important - don’t just talk about improvements, people need to feel “safe” and not afraid of failure, to talk about problems in front of you.
Apologies should be short - admit your failings, move on (don’t turn it into a rambling excuse)
Disagreement - use your curiousity - what are you missing or not understanding?
Accountability - if people be curious - did they understand, did they have what they needed, what can be done better?

Chapter 9 - Bootstrapping Culture

Many people think structre = process = slow/bad/boring/rigid. Reframe this - it’s learning from what worked (or didn’t). It’s transparency, sharing, scaling.
(Personal one - it’s how you stop doing the same thing all the time and let someone else take over, or automate)
Code often becomes a bit spaghettified and then gets refactored - putting structure in place. Same with our systems (teams, process).
Great analogy - startup is racing car (feel everything, responsive, fast, high risk), then become a commercial flight (stability, low risk), then spaceship (can go far, but need planning).
Top level management should set goals rather than make explicit decisions
Older companies often have more entrenched habits.
Failure is often a great place to look at what needs to evolve (process, structure). Especially repeated failures (e.g. why are lots of people leaving?)
Not everyone will fit at a company (or may no longer fit as values change). Doens’t mean they can’t belong, but there’s more friction for them.
Subteams values are layered over company values, each team may have different layers.
About praise: “Reach through the part of you that is shy.. into the part that cares about the people you work with”
Use values to spot conflict or areas of “ambiguous friction” - phrase the discussion around values.
Values should be part of your interview process. Be explicit - e.g. do the candidates demonstrate the values you hold dear? (e.g. independence or collaboration with other teams)
Career ladders - involve the team in what they value, split tech/mgmt tracks, more levels early on (with narrower salary bands)
Cross functional teams - great for breaking down “us-vs-them” mentality. Removes friction, eases communication. Remember Conway’s law - “designs are copies of the communication structure”. One warning - cross-functional teams may not product the best or more efficient code.
Good to keep some people in a “core” team for critical pieces. People on CFTs still need 20% sustainability/meeting/interview etc time.
Leaders in tech teams are often good techies. Leaders in CFTs are often the best communicators, more efficient or best product sense. So what’s most important to the business - product or tech?
When adding process (e.g. code reviews) you must ensure people understand (and agree) with why and the benefits
Add process with a risk management hat - you don’t need to elimiate all risk, just the most critical or frequent ones.
Process should have value even if “half-baked” - i.e. if not followed exactly it should still be useful
Depersonalize decisions - e.g. test gates, linters.
Code reviews - more about communication (and “missing test case”, “please update docs”), generally doens’t catch bugs (that’s what tests do). Keep an eye on metrics (outstanding, timescales)
Postmortems (or “learning review”) - blameless, look at circumstances - do we need new tests, new tools, new alerts. Be realistic about what changes to be made (risk management)
Architecture review - aim is to socialise the changes. Choose affected people, not a “cabal”. Choose specific things to review (e.g. new language, new datastores) - you don’t want a review of every single feature. Half the value is in the preparation for the review “do we really need this?“, “would it benefit others projects?”, “what are the risks or doing/not doing this?”

Chapter 10 - Conclusion

Must be good at managing yourself if you want to manage others. What inspires you, what upsets you?
Should be a “master of conflict” - removing your ego (stop telling stories), clarifying complex situations, “telling people hard facts by not embellishing”
Being curious can help in many situations. e.g. thinking from the other perspectives

My conclusion

I really enjoyed this book, especially the way Camille shows the change in focus as the role becomes more senior. She’s very candid about problems and why not to go for a more senior role. The inter-personal aspects are well explained - I think it helps that she had past struggles and her explanation resonates well with me.

“Get curious” is her motto and she applies it to avoid falling into the trap of “that person is stupid” - something that I’m certainly going to adopt.