I wish the book Become an Effective Software Engineering Manager existed when I moved from development to management. I was one of the luckier ones: I had a formal apprentice management program with plenty of training, access to senior engineering leaders as mentors within the company, and a circle of hands-on engineering managers to learn from. Even so, this book would have helped me be more strategic about my learning and would have given me more confidence early on.

Note that none of the below links are affiliate links or sponsored ones. See my ethics statement on the lack of such links.

What I most like about the book is that it is a “modern”, 2020 take on engineering management – with the focus being on the “hard to get right the first time” parts. I have yet to read a book on engineering management that covers 1:1s, performance reviews, hiring and laying off, diversity & inclusion, workplace politics, remote work, and the need for managers to relax. I have definitely not seen all of these in one place. As I read, I kept nodding along with the experiences and advice. It’s similar advice to what I’d give to anyone wanting to build a great team with a strong developer culture, being a thoughtful manager.

The author, James Stanier, moved into management from an academic development background. He joined a startup, working his way up to SVP Engineering, managing a team of 60 people, going from line manager to manager of managers, and responsible for the whole engineering organization. The book follows along a similar path: the first part covering things a brand new manager should know, the second part going into topics more experienced managers should master.

Each of the 18 chapters starts with an engaging story. This approach makes the book and easy and engaging read. “You hold the ID card out in front of you so you can read it. Fortunately they’ve spelled your name correctly. Shame about the photograph, though. You return it to your pocket. You’ve arrived. It’s day one”. And you don’t get bored later on either: illustrations and exercises continuously spice things up. I found myself skimming through the book on the first read, then coming back to the chapters and reading them in-depth, later on.

I strongly recommend this book to people looking at their first engineering management role, as there is a wealth of practical and genuinely good advice written. It is the kind of advice you get in your first two years as a manager – assuming you have one or two great mentors and are surrounded by multiple peers who continuously give you well-intended feedback. Which – unfortunately – is not the case for many people. How do you manage your perception? How do you decide what information to broadcast? How do you do good 1:1s? Grow people? Do perf reviews? Hire? Let people go? These topics are not only valuable reading for first-time managers, but I find myself looking these topics up when I am mentoring less experienced managers, drawing inspiration on activities to suggest for these managers to take on to grow.

More experienced managers like myself can also take away good parts, especially in the second part of the book. How do you manage high-stakes “The Eye of Sauron” projects? How do you get the news through the grapevine? How do you make workplace politics work for you? What are ways to communicate well within a larger group? How should you design career ladders? What about diversity, inclusion, remote working and work-life balance?

I’m adding this book to the shortlist of engineering management books I’m recommending engineering managers to read. These books are:

• The Manager’s Path by Camille Fournier. A short reference handbook for managers at all levels.
• An Elegant Puzzle by Will Larson. The most hands-on read on engineering management I’ve picked up. See my in-detail review and notes.
• Become an Effective Software Engineering Manager by James Stainer

If you buy the paperback book, you’ll find a quote on the back of it from me, which sums up this review more concisely: “This is the book I’ll be recommending to new managers transitioning into the role, managers starting at a new company, and experienced managers looking to make an organizational-wide impact.” You can buy the book from the publisher here.

My book notes

As I read the book, I took notes for each of the chapters. Read on to get a glance of the topics the book touches on.

“The technology industry is facing a skills crisis. This isn’t because we don’t
know how to write software or how to scale our infrastructure. We’ve been
getting a lot better at that. Instead, it’s because we don’t know how to manage
people. Computers don’t create software, people do. We need to make more
people succeed. Good managers can solve this problem. You can be a great one.” – part of the introduction. I like the tone: and I agree that we need more great software engineering managers.

Part 1 – Getting Oriented

A New Adventure (Chapter 1)

• A strong kickoff with an engaging story on starting as a new manager. I could almost feel myself being the new manager of infrastructure at this unicorn company. Except when I started at Uber, I had not one, but 25 unread emails already.
• Impostor syndrome is normal for managers. Yes it is, I also felt the same way when I started my management journey. “You were given this role in the first place because you were qualified for it. Remember that. You will feel more confident with time.”
• Practical advice on things to do the first week and finding misalignment signals on your first week – and later. The section on creating a snapshot has a novel approach on how you can figure out where there’s misalignment between the team, your new manager and you, early on. It’s a tool that is useful well beyond the first week.

Manage Yourself First (Chapter 2)

A good reminder of how getting your things an order comes first – this is a pre-requisite to you being efficient, as a manager.

• Organizing your calendar. Pragmatic advice on not using your calendar for other than meetings and booking out spots when you’re busy or OO. “Your calendar it is both for you and other people to use. Keep it tidy and meaningful. It represents you. Making meetings public by default can help others reason better about how to schedule time with you.”
• Categorizing your work to feel productive, as a manager. “If you’re unable to frame all of your managerial work in a way that is able to
  make you feel productive, then, with time, you may feel like your job is happening around you rather than feeling like you are doing your job.” Caregorizing activities as information gathering, decision-making, nudging or being a role model, following the model outlined in High Output Management, by Andy Grove. Also, to-do list and email inboxes.

Part 2 – Working with Individuals

Interfacing with Humans (Chapter 3)

This chapter covers a lot of ground on how to communicate with others, as a manager.

• How to communicate well. Mediums of spoken, written and nonverbal communication. Choosing between face-to-face, emails, documents, chats, JIRA and others. Being aware of your perception as a manager. Managing your energy and not carrying over frustration / emotions from one meeting to the next. This is easier said than done, but this is a key skill to master for any decent manager.
• Think twice before broadcasting information. “Don’t communicate when you want to. Communicate when you need to” I agree, and this is a mistake most first-time managers do, in eagerly over-communicating, then having to backtrack.
• Be consistent in your communications style. “Fundamentally it’s up to you, your team, and your workplace culture as to how formal you are in your interactions, but nobody wants a manager who is also the class clown. A useful way to approach this is to start formal and gradually ease the formality with time to a place that you are comfortable with that allows you to still be authorititive and critical when needed. Once you’ve slipped down to extreme informality, it can be hard to come back up again.”
• Giving good feedback. Referencing key points from Radical Candor, a book that is also on my reading list. Delegation and working with your manager.

One-to-Ones (Chapter 4)

• Your first 1:1 and contracting. “Let’s have a look at each of the questions. They’re the same ones that I use in my own contracting sessions. However, they should only serve as a guide.”
• It’s their meeting, not yours. “Try and get your direct reports to do 70% of the talking. If you feel like solving their problem for them, don’t. Ask another question and let them arrive at the conclusion themselves. This is an art that takes some practice.” (Gergely: while I agree with the premise, I’d add that you’ll need to do a lot more coaching for less experienced people until they feel they own the 1:1s. Also: if you have key information to share that impacts people significantly, do it here, that also builds trust).
• Making updates more interesting. “Instead of just nodding and listening to what they’ve been doing, why not probe deeper by asking some questions?”. Taking notes and assigning actions, and doing this via a shared document. I also do this, though more as a supporting action, than a main focus.

The Right Job for the Person (Chapter 5)

An overview on things that can help with working with people. Motivation, learning theory and thoughts on stability/chaos. I’ll be honest: this chapter was more academic than practical for me, though I’ve used all the tools described in this chapter before.

• Motivation and the hierarchy of needs. Developing skills with some practical examples on doing so. Skill tree: an interesting idea I’ve not heard laid out in this format before.
• The zone of proximal development (I call this challenging people with things that are just out of their comfort zone. Also, see my article on stretching, executing, coasting covering a similar topic, without the academic background) “However, as their manager, you can work with them to place these career achievements at the bottom of their own skill tree, and then plan out the milestones along the way that they can aim for in order to make measurable progress. thus pushing the frontier of their zone of proximal development further and further.”
• Platform vs product mindset/interest – or, as James puts it, the Cathedral vs the Bazaar. I’ve written about the product-minded software engineer, who I relate more to the Bazaar type.

Performance Reviews (Chapter 6: The Most Wonderful Time of the Year)

This is a good section – especially when you’ve not done many performance reviews before. I previously wrote in-detail about how I do performance reviews for software developers. My take and approach is slightly different to how James suggests doing perf reviews, which – I guess – is to be expected.

• Myth busting on performance review myths. A fun read.
• Preparing for perf reviews and preparing ahead of time. Getting peer feedback, and doing this e.g. via email. Note that if you’re working at a larger company, you’ll probably have automated tools in doing so, using an out-of-the-box system like Reflective, Avature or something similar.
• How to talk about money was an interesting read for me. At places like Uber, Facebook, Google and large tech companies, this is quite different, as pay is not directly controlled by managers, but rather performance outcomes impact these. There’s a standard script managers share on the company’s compensation philosophy, with all questions on pay raises, bonuses, equity being standard across all employees. My two cents is decoupling the performance and salary discussions: James doesn’t touch on this specifically, but I feel pretty strongly about this, at least at a mature tech company with standard pay practices.

Hiring (Chapter 7: Join Us!)

There are countless articles about how hiring is broken – from a candidate’s perspective – so I was looking forward to this chapter, from the hiring manager’s perspective. It’s an important chapter, more applicable for smaller companies and places where hiring managers have more autonomy / less of a well-beaten path to follow typical of large tech companies.

• The case for not needing the most senior candidate. I agree with this idea and I’m quite conscious on seniority in my team, to ensure good team dynamics and growth opportunities.
• Culture fit – I was happy to see Culture Fit debunked. I’d add Culture Add to the mix as well. Briefly touching on unconscious biases was a good add.
• Writing job descriptions – solid advice and I was happy to see the style, tone and gender-neutrality listed. Note though that listing salaries upfront varies by market and company. I agree with when you can do it, you should. But the likes of Facebook, Google, Uber don’t list salaries, even when they have fair pay and salary ranges in place. Sites like levels.fyi give a good sense on where some of the bigger players are with compensation, though.
• Setting up an interview process – though this section is one of the longest in the book, and solid in content, if you’ve done hiring, you realize it only scratches the surface. Still the best collection of practical advice I’ve read in a book for hiring engineers. As with before, the process at FANG companies is a bit different, and focuses more heavily on coding, systems design and the bar raiser interviews – for better or worse.

Attrition (Chapter 8: Game Over)

• People leaving is normal. “As a manager, you are doomed to failure if you think that you are going to keep everyone in your current team indefinitely. (…) Be comfortable with the fact that all of our careers are different and we are all motivated by varying aspects.”
• Voluntary resignations that are “good reasons”, aka you could have not done much about it. Voluntary resignations that are “bad reasons”, that is you could have caught – and addressed – things early like coworker conflict, lack of challenge, compensation. Good suggestions on getting ahead of these.
• Counteroffers. “You should never fight to keep staff if you cannot actually provide the conditions under which they can become happier than they already are. You’ll just defer their departure.” The tactical parts of what to do if you actually still decide to make a counteroffer is good food for thought.
• Letting people go – making staff leave. The PIP, going about it, setting objectives, delivering and implementing it. Redundancies. A thorough and important read for any manager. For many, there will be no need to use this tool – until one fateful day, when it would be good to have a place to start.

Being well-connected (Chapter 9: How to win friends and influence people)

• Building your network . Making introductions, checking in with others. All good advice: easy to write (or read), harder, but important, to make it a habit.
• Mentoring and the mentorship matrix: an interesting idea on getting mentorship started at your company org, if there’s little happening.
• Coaching and the difference with mentoring.

Part 3 – The Bigger Picture

Humans are Hard (Chapter 10)

• Scrutiny and judgement. “At more senior levels, During bad times, you will get the fingers pointed at you as you are fundamentally accountable, even though it may have not been your fault.” Getting scrutiny from multiple directions: your team or your management chain..
• Less structure, more wobble. “In addition to the unstructured and complex issues that you’ll experience through managing humans, you’ll also partake in discussions that have no clear correct answer.” I really liked the Jell-O wobble parallel: wobbling the jelly from the bottom, or the top. “Part of your job as a manager is to prevent this wobble from occurring. You
  must try your best to protect the part of the organization that reports into
  you in times of adversity. This requires a good amount of emotional intelligence, judgment, and support.”. Listening, observing, communicating and peer support.
• The whip and the carrot and why it’s not about how hard people seem to be working. Contrasting this with autonomy, mastery and purpose from the excellent book Drive: The Surprising Truth on what Motivates Us, a model that has proven to work far better for software engineers.

Projects are Hard (Chapter 11)

• The eye off Sauron” – working on high-stakes projects. Principles of managing these kinds of projects, from over-communicating, frequent iterations and inviting feedback (and – I would add, granular milestones). After the project has shipped, recharging the team (things like celebrating, cleaning up tech debt etc).
• “Lead from the front: As a leader, you need to set the example for the rest of the team. Put in the work. The hardest projects can become career-defining moments. Own them and be there.”
• Things slowing down as the team is growing. More (legacy) code, more comms overhead. Approaches to keep the slowdown at bay by e.g. always showing progress and developing software pragmatically.
• Scope, resources and time. I like to call this the physics of project management. Make constraints / levers visible. Here’s a guide on how I manage projects within my teams.

The Information Stock Exchange (Chapter 13)

A pretty important part of being a good manager is being connected and being in-the-know. I enjoyed this section: it talks openly about the elephant in the room: information and politics.

• Spies and gatekeepers. “As a manager, you will be required to make regular decisions about how much you should share with other staff and when. The easiest option with any sensitive subject is to not say anything at all. But is keeping everything a secret by default the right thing to do? Definitely not. Unless there is a critical reason for hiding information, then it should be shared, although care should be taken in how the message is delivered.”
• Workplace politics. “In workplace politics, your network of peers is important as it allows you to be more broadly informed about how the wider business feels about your own initiatives and priorities, and it also gives you a chance to trial ideas before taking them any further, allowing you to initially operate in a safe, cross-disciplinary setting. Continually foster this network and use them to make you a better manager.”

Letting Go of Control (Chapter 13)

This is so important for managers! Especially as a first-time manager, letting go is really hard.

• “This has parallels with somebody taking part in a tennis match: they clearly want to win, else why would they be playing? However, a strong opponent or bad luck can mean that the outcome is not what they wished: they may lose. How can they maintain their inner tranquility? The answer is that for things that you do not fully control, you should set internal goals rather than external ones.”
• “Let go of outcomes that you cannot control. Be accepting of trying your best, and encourage the same behavior in your staff. Unpredictable results are normal. Failure is acceptable. As long as you are trying your best and you are enabling your team to try your best, then you have nothing to worry about. Pat yourself on the back.”
• “Try to carve out 10 percent of your time each week to do absolutely nothing other than let your thoughts emerge”
• Remove distractions and recharge properly outside work.

Good Housekeeping (Chapter 14)

• Communication is hard within a larger group. Conway’s law. Guilds and cross-functional teams.
• Turning problems into learning opportunities: this is what I’d call blameless postmortems.
• Tools to solve common problems. ADR: similar to the RFC process used at many places. Team health checks. Also: culture/pulse/management surveys. Ownership and DRIs (Directly Responsible Individuals).

Dual Ladders (Chapter 15)

On designing an IC and manager track that is vital to a healthy engineering organization culture. Building a career progression framework. Touching on good topics like switching between tracks and compensation.

The Modern Workplace (Chapter 16)

• Diversity and inclusion – refreshing for a management book to mention it. So important! Pipeline, cultural issues, biases. Good suggestions from publishing pay, equal pay and others.
• Shift towards remote working: more relevant than the author would have imagined with COVID-19 happening.
• Work-life-balance: leading by example and protecting your team.

Startups (Chapter 17)

• An honest, original and good overview of both opportunities at a startup, as a manager, and the risks.
• “Remember that start-up experience is highly sought after because being impactful in that environment involves being enterprising, self-motivated, collaborative, and quick to learn. Even if the start-up itself doesn’t work out, your next gig will be all the better for it.” — this is absolutely the case!
• Practical overview of where and why management is important. As someone who worked with one of the first managers at Uber, agree with the points (management mindset, help others grow, the management mindset). “Management doesn’t mean bureaucracy. Good management is a light touch and continued collaboration. This doesn’t get in the way of anything. Being an excellent manager at a start-up breaks the stereotypical norm.”

The Crystal Ball (Chapter 18)

• Your career vision. Looking back, looking ahead.
• Performing the same exercise with your team. I found this one valuable, some good ideas. It runs somewhat similar when I ask people “what would you want to be doing after Uber?”
• A nice wrap-up for a practical, and hands-on book for managers.

Featured Pragmatic Engineer Jobs

1. Senior Full Stack Engineer at Perfect Venue. $150-180K + equity. San Francsico or Remote (US).
2. Full-Stack Engineer at Vital. $70-120K + equity. Remote (Global, within 5 hours of GMT).
3. Backend Engineer at Vital. $70-120K + equity. Remote (Global, within 5 hours of GMT).
4. Expert DevOps Engineer at Zivver. Amsterdam.
5. Senior Frontend Engineer at Pento. £80-92K + equity. Remote (EU, EEA, UK).
6. Senior Mobile Developer (React Native) at Peppy. Remote (UK).
7. Head of Data at Peppy. Remote (UK).
8. Engineering Leader – Card Platform at X1 Card. $250K+. Remote (US).
9. Backend Engineer at X1 Card. Remote (US).
10. Senior Software Engineer, Distributed Systems at Mixpanel. $200-270K + equity. New York, San Franciso, Seattle or Remote (US).
11. Senior Software Engineer, Fullstack at Mixpanel. $200-270K + equity. New York, San Franciso, Seattle or Remote (US).
12. Front-end Product Developer at Whimsical. $94-118K. Remote (EU, UK).
13. Senior Full Stack Developer at BENlabs. $140-190K. Brazil, UK, US or Remote.
14. Senior Engineer at Sixfold AI. New York.
15. Senior Backend Engineer at Comun. New York or Remote (US).

The above jobs score at least 10/12 on The Pragmatic Engineer Test. Browse more senior engineer and engineering leadership roles with great engineering cultures, or add your own on The Pragmatic Engineer Job board and apply to join The Pragmatic Engineer Talent Collective.

Want to get interesting opportunities from vetted tech companies? Sign up to The Pragmatic Engineer Talent Collective and get sent great opportunities – similar to the ones below without any obligation. You can be public or anonymous, and I’ll be curating the list of companies and people.

Are you hiring senior+ engineers or engineering managers? Apply to join The Pragmatic Engineer Talent Collective to contact world-class senior and above engineers and engineering managers/directors. Get vetted drops twice a month, from software engineers – full-stack, backend, mobile, frontend, data, ML – and managers currently working at Big Tech, high-growth startups, and places with strong engineering cultures. Apply here.