The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change

Describes the different roles in technical organisations, what their responsibilities and challenges are. Excellent read for people who want to become team leads or managers. Also for engineers to understand what their managers are actually doing.

Chapter 1 - Management 101

The experience of being managed is the foundation on which you build your own management philosophy.

p. 1

Good managers

  • Care about you as a person
  • Actively help you grow
  • Teach you important skills
  • Give valuable feedback
  • Help you navigate difficult situations
  • Help you figure out what you need to learn
  • Help you understand what is important to focus on

p. 2

At a minimum, managers should do

  • 1:1s: Create human connection, speak privately, not a status meeting
  • Guidance and feedback: bad and good feedback
    • Good feedback can be in public, but ask beforehand
    • Manager should be number one ally
  • Training and career growth

p. 2 - 6

CTOs have to create strong networks across companies.

p. 7

How to be managed

p. 7 - 9

Having a network and being able to navigate the company's politics is important for strong managers.

p. 9

Good engineers may make great mentor-managers but bad advocate-managers.

p. 9

Chapter 2 - Mentoring

Mentoring is a safe introduction into management.

p. 12

Great talent is often squandered by weak mentors.

p. 12

Mentoring an intern

  • During the first days, check in a few times per day (p. 13)
  • You're a person of huge power in your mentees yes. They're nervous about screwing things up, trying their best to please you and to not look stupid. (p. 14)
  • Communicate clearly what needs to happen, e.g. if he asks too many questions, not thinking on his own, telling him to work alone on an encapsulated task. (p. 14 - 15)

p. 12 - 16

Mentoring a new hire

  • Mentors job consists of onboarding, helping to adjust to life in the company, and building their network of contacts in the company. (p. 17)
  • Help your mentee updating (onboarding) documents, don't let them do it alone (p. 17 - 18)

p. 16 - 18

Technical or career mentoring

  • The best mentoring relationships evolve naturally in the context of large work (p. 18)

p. 18 - 19

Alpha geeks are extremely good engineers, but easily threatened, which makes them bad managers.
They want (and need) to be the best.

p. 20 - 21

When assigning a mentor, treat it like any other responsibility. Particularly time commitment and how well it is done.

p. 22

A common pitfall is viewing it as low-status emotional labor.

p. 22

Mentors should be curious and open-minded, listen and speak the mentee's language and make connections.

p. 24 - 26

Chapter 3 - Tech Lead

Tech lead is a leadership, but not management position.

p. 27

I watched him [tech lead] go down rabbit hole after rabbit hole, and in the meantime the product manager took advantage of his absence to railroad the rest of the team into committing to feature delivery that was both poorly designed and way too aggressive.

p. 27

Tech lead doesn't have to be a point on the career ladder, but rather a set of responsibilities.

p. 28

Besides people skills, tech leads need one major additional skill: project management.

p. 29

Being a tech lead is an exercise in influence without authority.

p. 30

Main roles of a tech lead

  • Systems architect and business analyst
  • Project planner -> more details p. 34 - 36, 38 - 39
  • Software developer and team leader

p. 32 - 33

Explaining things (to everyone! business, product, sales, marketing) to involved (or interested) parties is highly important.

p. 37 - 38

Imagined vs real life of different roles.Particularly the imagined life of a manager is totally on point. It's exactly how I pictured it.

p. 40 - 44

Process Czars focus strongly on processes, with all the benefits and drawbacks.
More description and advice for dealing with them p. 45 - 46.

p. 45 - 46

Characteristics of great tech leads

  • Understand the architecture
  • Be a team player
  • Lead technical discussions (lead, not do)
  • Communicate

p. 46 - 48

Chapter 4 - Managing People

In the period of adjustment to manager should be to figure out the management style.

p. 49

1:1s scheduling tips

p. 52 - 54

1:1 styles
Which one to choose depends on both manager and managed.

  • Todo list meeting
  • Catch-up
  • Feedback meeting
  • Progress report

p. 54 - 57

Allow them to get to know you and the other way round. Family, friends, hobbies, ...

p. 56

Keep notes in a shared document. Notes, takeaways and todos, with manager as a note taker.

p. 56

Difference of micromanager and effective delegator

p. 57 - 58

The difference is not taking over, but helping to get a good result.

p. 58

When you strip creative and talented people of their autonomy, they lose motivation very quickly.

p. 58

Continuous feedback is important
As a manager it is training you to pay attention to individuals.

p. 61

Steps to take to become great at continuous feedback

  • Know your people
  • Observer your people
    • Practice looking for talents and achievements on your team
  • Provide lightweight, regular feedback
    • Start with positive feedback
    • Use it to guide to better behavior
    • Good feedback makes it more likely they'll listen to critical feedback

p. 62 - 63

Continuous feedback works best in combination with coaching.
Praise them for things done well, ask what they could've done better and provide suggestions.

p. 63

360 performance review model combines feedback from all people a person works with, colleagues, reports, manager, ...

p. 63

Tips for good reviews
Most importantly, spend time on it. It won't be done in 1h.

p. 64 - 67

Many companies expect you to work on the next level before promotion to avoid people being promoted to their level of incompetence.

p. 70

If there's no room for people to work in a more senior level, it may be a sign to rethink how work is done to let individuals take on bigger responsibilities.

p. 70

Challenging situation: firing underperformer
When giving negative feedback, there are managers who ignore excuses entirely, who accept all of them, and the ones finding a good middle ground.

p. 70 - 72

Generally you want to make sure that long-term employees are capable of doing their day to day work independently, without a lot of oversight or help.

p. 73

Sometimes despite your best efforts, people can't progress beyond a specific point.
This situation should be made clear to the person.

p. 73

Chapter 5 - Managing a Team

Engineering leads identify the most high-value projects and keep the team focused on them, partner closely with product lead and identify headcount needs.
Additional requirements p. 76

p. 75

Being a good manager isn't about having the most knowledge. Supporting people is far more important.

p. 77

It's still a technical discipline. Knowledge has to stay current and the team has to see you're technically proficient to be respected. You also need to do technical discussions.
Working with the code, even just for small things, helps you feel bottlenecks and technical debt.

p. 77 - 78

If you stop writing code too early, you may never achieve sufficient technical savvy to get beyond middle management.

p. 78

Debugging dysfunctional teams: p. 79 - 81

  • Not shipping
  • People drama
  • Unhappiness due to overwork
  • Collaboration problems

p. 79 - 81

Overly negative people should be ousted quickly.

p. 80

Use the word "system sustainability" instead of "technical debt".

p. 80

Managing a former peer

p. 82 - 83

Drama in the workplace is usually little more than an ego-entertaining drain.

p. 83

Managing conflict
It's important to say no to things, and to guide the team, not letting the team guide itself.

p. 86

Being kind is being nice on a more long-term level. It's important to be kind.

p. 88 - 89

Challenging situations: Team cohesion destroyers

  • The brilliant jerk
  • The noncommunicator
  • The employee who lacks respect

p. 90 - 92

Talking with people about personal lives is more than just smalltalk. It fosters relatedness and psychological safety.

p. 90

Project management

p. 93 - 95

As manager you're responsible for handling uncertainty and limiting how much of it you expose to your team.

p. 95

How to join a small team as their manager.

p. 95 - 96

Fewer notes from here on because it's less relevant for me in my current situation. Might revisit these chapters in the future.

Chapter 6 - Managing multiple Teams

Usually only at the director level do people start to manage multiple teams.

p. 99

For time management it's good to understand the difference between importance and urgency.

p. 103

Strategies for saying "no"

  • "Yes, and" (excellent technique regardless of position, use for people above you, who want something from you)
  • Create policies
  • "Help me say yes" (also great technique, use for people reporting to you)
  • Appeal to budget
  • Work as a team
  • Don't prevaricate

p. 111 - 113

Chapter 7 - Managing Managers

First time managers need a lot of coaching

p. 136

Challenging situations: Roadmap uncertainty
Also addresses how to deal with technical debt.

p. 151 - 153

How to stay technically relevant and what that means in such a position.

p. 153 - 156

Managers not staying technically relevant find themselves as a go-between for senior management and their teams.

p. 155

Chapter 8 - The Big Leagues

4 categories of management tasks

  • Information gathering and sharing
  • Nudging
  • Decision making
  • Role modeling

p. 160 - 161

What's a VP of engineering?

p. 164 - 166

What's a CTO?

p. 166 - 168

The CTO must protect the technology team from becoming a pure execution arm for ideas without tending to its own needs and its own ideas.

p. 167

It tends to happen that issues need to be raised multiple times before they get acted on (from the manager). Before that they might think they'll resolve themselves.

p. 171

Instead of getting tense and angry it's better to get curious when things don't seem to be going well.

p. 182

Chapter 9 - Bootstrapping Culture

Unstructured groups can work if

  • It is task oriented
  • It is relatively small and homogeneous
  • There is a high degree of communication
  • There is a low degree of skill specialization

p. 193 - 194

Structure is how we scale, diversify, and take on more complex long-term tasks.
We do it to software, teams, and processes.

p. 195

Think of process as risk management.

p. 212

Don't put complex processes in front of frequent activities.

p. 213