There are so many great books that I could recommend for a new manager. Narrowing down the list has been challenging!

We’re fortunate that much is written on the practice of management. In addition to that, many Engineering Managers have detailed the specifics of working with technology teams. However, this makes it difficult to know what to focus on first.

I’ve picked the first 10 I would recommend to a new manager. These are all books I’ve read and have influenced how I think out management and leadership. As ever, if you disagree or want to add your recommendation then please let me know!

Moving to a management role #

The Manager's Path by Camille Fournier

I wish that this book had been available earlier in my career. What’s so great about it is that it covers all levels of the Engineering career path, so there’s something in it for everyone. For those starting on their management career, there’s detailed information on how to mentor others, how to manage projects and how to start managing people. The content is actionable, so the book becomes a useful reference as your career grows and responsibilities change.

Behind Closed Doors by Johanna Rothman, Esther Derby

This book is another good one for “getting started” with management. The book is in the style of a business novel and follows the journey of Sam as he joins a company as an Engineering Manager. Using this context, the reader learns about the core principles and practices of managing people, teams and projects. For new managers, the book accelerates them through many of the challenges they are likely to encounter as they make their career change.

First, Break All the Rules by Marcus Buckingham, Curt Coffman

Unlike the first two books in this list, this text covers a broader perspective of management – not only that of Engineering Managers. In it, the authors have bought together many years of research from Gallup on what makes exceptional managers and workplaces. For new managers, it’s a source of inspiration for developing a style of management which promotes the development of traits seen in good mangers and teams covered by the research.

Motivation and Empowerment #

Drive by Daniel Pink

This book has probably been one of the most impactful on how I think about working with people and teams. I read it when I took my first Engineering Management role and the details on how intrinsic motivation is an indicator of performance alongside the information of how to nurture this kind of motivation in people has greatly influenced how I manage teams.

Turn the Ship Around by David Marquet

A story of leadership from a military setting (the U.S Navy) that has a surprising amount of overlap with leading engineering teams. Naval Captain David Marquet took over command of a struggling submarine, and the book tells of how he engaged the crew to such an extent that it became the best performing ship in the fleet. Key to the story is the idea of empowerment and intentional leadership, showing that in your new management role, there’s an alternative to top-down management to getting things done.

Communication #

Crucial Conversations by Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler

There are many exciting challenges when it comes to moving to management, and for me, one of the essential skills to develop is a way to communicate effectively. It is especially true when it comes to those high-stakes conversations – performance reviews, feedback, negotiation – where our emotional responses often cause us to be less effective. This book helped me deal with those situations more positively. It’s something I suggest that new managers read early in their career so that they’re aware of the challenges and techniques to overcome them before that crucial conversation comes up.

Radical Candor by Kim Scott

Alongside Crucial Conversations, Radical Candor helped me develop techniques to have better, more impactful conversations, with my teams. Perhaps the most cited aspect of the book is the quadrants describing the styles of feedback conversations. You can probably pick this up from a blog post, but by reading the full text, you’ll get more depth into the different styles and advice on how to have more productive feedback conversations.

The Coaching Habit by Michael Bungay Stainer

For most, by the time you become an Engineering Manager, you’ve likely developed a considerable amount of experience you can share. One of the hard aspects of your new Engineering Manager role can be resisting the temptations to provide all the answers when someone is struggling. The Coaching Habit sets out seven questions which you can use in your conversations with your direct reports to support them in realising their potential. There is more to being an effective coach than is covered in this book, so think of it as a way to kickstart coaching skills.

Project Delivery #

The Goal by Eliyahu Goldratt

Another business novel, where we shadow a manufacturing plant manager trying to improve the performance of his factory. Which might get you thinking, “what has this got to do with Engineering Management?” As well as looking after people in your organisation, you could also be responsible for the delivery of projects. This is where this book helps. The Goal shows us how to discover the true nature of our business and then goes on to explain how we can improve the way we produce outcomes. The factory in the book is manufacturing parts, but the ideas of the Theory of Constraints are directly applicable to software delivery.

Accelerate by Nicole Forsgren, Jez Humble, Gene Kim

If you’re not already managing a team practising Continuous Delivery, or even if you are, this book provides the science behind why these practices are so valuable to building well-performing teams. You might not learn any new techniques of how to make the change from this book (I’d recommend Continuous Delivery, The DevOps Hanbook or Site Reliability Engineering for that), however, you will leave with an understanding of the benefits that can be gained from taking such approaches. You’ll also learn about some useful starter metrics for measuring the performance of the teams you work with.

You can find more recommendations in the I’m New to This series.

Recently I got into a conversation about measuring the performance of Engineering teams. The teams in question are following the Scrum framework and have decided to use story points for estimating the complexity of the work.

In the conversation, we were talking about the validity of measuring individual team performance and whether one should use this data to compare the performance across teams.

Now, for anyone that’s even taken more than a passing glance of any of the literature surrounding agile development, Scrum or estimation, the idea of measuring team performance and comparing performance between teams is a clear anti-pattern. Specifically, we’re told, “don’t compare velocity between teams”.

And I broadly agree. In most cases when this topic is raised, the drivers for comparing team performance are dangerous - to discover which teams are delivering as expected and which aren’t, which teams are good and which aren’t, and inevitably, to performance manage those teams and individuals in bad teams.

However, as with all arguments, there’s nuance, and I think there are some excellent reasons why understanding the performance of teams and comparing between them can be useful.

My approach to managing teams of teams has evolved over the past couple of years to consider more greatly the way the system as a whole is operating. I’ve been inspired to change by reading and development in the areas of system thinking. The rest of this post will pull on some ideas from system thinking.

If you’ve not come across the concept, then what follows might not resonate with you. Good background reading on the topic is Thinking in Systems by Donella H. Meadows, or for a quicker read, there’s the Introduction to Systems Thinking .

No matter how hard we work to eliminate cross-team dependencies, a group of engineering teams working towards a common goal operate in the same system of delivery. Therefore, it can be said that the performance of this broader system (the Engineering team) will be directly related to the performance of its constituent parts (a Scrum team, for example).

Furthermore, systems theory tells us that the performance of a system will be directly correlated with the performance of that system’s bottleneck. To improve overall system performance, we need to focus our attention on the bottleneck. Improvements elsewhere in the system are likely only to have negligible effects on the overall performance of the system and in the worst cases, some local enhancements will make the system performance worse.

With these thoughts in mind, our attention needs to be drawn to discovering the bottlenecks in our system and applying maximum leverage to these areas.

Although the system is more than the composite of the individual teams, the teams should be one place we look for our bottleneck. Measuring and comparing the performance of teams helps us understand if one of them is a bottleneck in the system of delivery.

Additionally, we can also learn whether there’s a local (team) issue that needs addressing, or whether there’s a systemic issue affecting more than one team needing our attention.

Let’s look at some examples to demonstrate these points. In these examples, I’m going to use throughput as a measure of performance. Throughput is the count of the number of tickets a Scrum team completes in a week. Increasing throughput is one of the goals of improving this system.

Below is an example chart plotting throughput for a team over 10 weeks. In this chart, we can see that this team has a steadily increasing throughput over this time.

Now we add a second team to this chart.

What conclusions can we draw from this? We could say that the blue team is better than the orange team because their throughput is higher. Yet, is this really true? Perhaps the orange team isn’t splitting their tickets down as aggressively as the blue team?

We also see that both teams are improving - so using these two teams as a sample set for the overall system, we may be able to say that the performance of the system as a whole is improving.

So far, comparing teams hasn’t really shown us anything more useful than not doing so.

Let’s add a third team. In this example, the green team has a higher throughput than both the blue and orange teams. We can also see that unlike blue and orange, the green team throughput is decreasing. As two of the three teams are continuing to improve, we might conclude that we have a local issue with the green team that we should look into.

To be more responsible with our charting, we can remove the axis and normalise the throughput counts. Doing this helps us to draw attention to critical differences and focus on the right conversations (it’s also why I used dotted lines for the actual throughput lines). If we look at the revised chart, it’s clear that we need to spend time with one team seeking improvements.

Looking at one more example, we see that every team in this system has decreasing throughput. Seeing this, rather than starting to work with individual teams to improve their throughput, we should focus our energies on developing a better understanding of the system they are operating in.

In this example, efforts to improve a single team’s performance is likely to have limited impact on overall performance. Had we not compared teams, we would not have seen this, and each one would likely have focused on locally optimising their own throughput.

In conclusion, making comparisons between teams isn’t inherently wrong. It can be done in a way which develops insight about the broader system and better understanding within teams about the issues that can and can’t be solved locally.

I have to pass a tremendous amount of credit onto Troy Magennis of Focused Objective for inspiring my thinking on this article. In 2019 he visited the company I worked at to teach us about statistics, estimation, forecasting and reporting. His work inspired my further discovery into this area and my thoughts on team comparisons are built upon the insights and ideas he shared with us.

I’ve been spending a fair amount of time recently reworking our career paths. Our current documents are heavily based on the work by Radford , which defines 6 levels for each job family. Whilst our career path was very well defined and comprehensive, we are finding that the documentation is a little incomprehensible and causes difficulty as people try to self-assess their position on the career path.

Through conversations about this, it’s clear our team members want something simpler against which they could measure their progress and plan their development. This is one of my key tasks for the coming weeks, and I’ll drawing inspiration from the many public career paths that exist, such as the one from Rent the Runway .

In the meantime, in conversations with our engineers I’ve found myself boiling down the career path to a few key competencies. Two of these are impact and influence, and I’d like to focus on these here.

As I talked about the changes in expectations across I have for the impact people have, and the influence they exert across the levels, I found I need for a visual aid. So, I took to drawing a set of concentric circles on the whiteboard to demonstrate my arguments.

We start from the centre of this diagram, where we find our entry level engineers (Engineer I), and slightly further out our Engineer II’s. At these levels, your impact and influence is expected to be on an individual level, as you use your new and existing skills to be a competent individual contributor and collaborative team member. Your focus here is on growing as an engineer, taking opportunities to learn and develop new skills.

Moving outwards, our Senior Engineers are expected to have impact and influence over their individual scrum and delivery teams. At this level, you’ll be expected to be co-ordinating others to solve problems and motivate the team to achieving their goals. To do this, there’s an expectation that you’ll need to have achieved a strong base of knowledge in our products and in at least one of key technologies.

Looking to our Staff Engineer circle, this is the first time your influence and impact starts to transcend your immediate team. Here you’ll be expected to be defining the approach for not only your delivery team, but also starting to influence other members within your own discipline. For example, as a Staff Test Engineer, you could be helping to define the approach to testing RESTful services across the group.

In the Principal Engineer circle, you’ll be starting to change the agenda for the engineering group. This will involve working across boundaries of disciplines or delivery teams to define processes, practices and behaviours or to deliver large pieces of work co-ordinating amongst several groups. Alternatively, as a Principal Engineer you could be the one using specialist knowledge to solve particularly sticky issues for teams.

Finally, at the edge of the diagram we find out Distinguished Engineers. At this level, engineers are supporting technology initiatives at a company or industry level. Your impact and influence is no longer limited by the boundaries of the company, and you use your skills to drive significant change to not only the company, but also to the wider industry.

I’ve found this 5 circles approach as a good way of showing the expectations at each level in a way which is simple and understandable. It clearly shows the differences between each level, and gives people a lens with which they can better understand their own position on the career path.

In doing some research for this piece, I was pleased to see other companies use similar mechanisms to describe the progression through an engineering career path. One such example is Spotify whose process is described in “Spotify Technology Career Path ”.

I believe that one of the most powerful things you can do as a leader is to own your mistakes. Nobody is perfect, and therefore it’s inevitable that you will make mistakes. Often, holding a leadership or management position means that these mistakes are magnified and have a impact on many more people.

So why admit your mistakes?

Wouldn’t this be showing a weakness? Wouldn’t it show that your infallible? Won’t people judge you closer? Surely, you’ll lose their trust and respect.

In fact, in my experience I’ve found the exact opposite to be true. Being able to admit to your mistakes creates the impression of a more confident leader, gives you the freedom to take more risks and helps foster a culture of trust and respect.

Building trust #

In The 5 Dysfunctions of a Team, Patrick Lencioni describes the common issues which lead to team failure. The base of this pyramid is “absence of trust”. Lencioni goes onto explain that individuals need to achieve vulnerable trust, a trust that the intentions of their peers are good which in turn gives people the freedom to express different opinions or ideas.

As desirable as this may be, it is not enough to represent the kind of trust that is characteristic of a great team. It requires team members to make themselves vulnerable to one another, and be confident that their respective vulnerabilities will not be used against them. The vulnerabilities I’m referring to include weaknesses, skill deficiencies, interpersonal shortcomings, mistakes and requests for help.

As ‘soft’ as all of this might sound, it is only when team members are truly comfortable being exposed to one another that they begin to act without concern for protecting themselves. As a result, they can focus their energy and attention completely on the job at hand, rather than on being strategically disingenuous or political with one another.

Owning your mistakes will act as a catalyst for building trust in your teams. By going first and showing your vulnerability, you implicitly give permission to others to do the same. Building vulnerable trust creates a basis for better decision making and team-work, as described by Lencioni.

Building accountability #

When you’re accountable for a decision, you’re the person who’s responsible for explaining the reasoning behind those decisions. Many people are afraid of taking accountability as they fear the consequences of getting something wrong. By freely admitting your mistakes, you show that being accountable for something isn’t a position which people should fear.

Removing the fear encourages others to make themselves accountable for decisions. When this happens, decisions get driven down to the lowest rank in the organisation and as a consequence the cohesion between the group improves and your role as a leader changes to that of an enabler. You move from the person making all the decisions to the person who continually improves the understanding of the context within which decisions are made so that others can make those decisions.

As more individuals take accountability the organisation grows with greater autonomy and empowerment. Due to the strong correlation between autonomy and motivation, this has a positive affect on the happiness, engagement and motivation of the group. The sharing of accountability also improves organisational efficiency as you remove yourself as a bottleneck to decision making.

Building a culture of experimentation and learning #

A team that isn’t experimenting and learning is a team that is destined for mediocrity, and eventually will be a team that fails. There’s a lovely quote which sums this up.

If you always do what you’ve always done, you’ll always get what you’ve always got.

Whilst “getting what you’ve always got” might have been a reasonable way to do business in the past, the increased pace of change and lower barriers to entry mean that continuing with the status quo is likely to result in you or your industry being disrupted.

To stave off the possibility of something like this hitting your business you need to continue to innovate and experiment. The process of successful innovation and experimentation is built upon the shared understanding that most experiments will fail. All innovation carries a degree of risk, and it’s unlikely that anyone will be willing to address this risk in a culture that doesn’t tolerate failure.

Owning your mistakes shows that when failure occurs, it’s addressed and celebrated as an opportunity to learn from. Building this learning culture will encourage innovation and experimentation within the team. People will be more willing to take risks, knowing that the consequences of getting something wrong won’t result in career limiting repercussions.

Enabling this learning loop in the organisation will also give the tools to make better decisions in the future. Someone that can realise when they make a mistake, admit to it, and then learn from it becomes a powerful agent for change within an organisation. The act of making mistakes and surviving them adds to our experience of handling situations, which can be drawn upon the next time a similar decision point is reached.

Owning your mistake #

Those are the reasons why admitting to your mistakes is a good thing to do, so next we should address how you handle this situation when it inevitably occurs (and it will, no-one is infallible).

Your reaction to your own mistakes will have an impact on the way your organisation culture develops. When the time comes, you need to step up, and be honest about your mistake. Apologise, resisting the natural urge to excuse yourself by attempting to explain your rationale. Also, don’t look to blame someone else - you need to show accountability.

Importantly, follow up your apology with a clear plan showing how you’ve learnt, and how you’ll correct the situation or ensure you don’t end up making the same mistake again.

Last week, I hosted a talk at our department all-hands. During one session, I needed to talk about a new team being set up in the group. I’d had feedback that my approach in building this new team lacked transparency which in turn enabled the rumour mill to go into overdrive.

I opened this talk with an apology for the lack of clarity and transparency in staffing the new team. Following the all-hands, I was stopped by one of our engineers who gave me feedback that it was one of the first times that he’d seen a leader admit a mistake, and that in doing so I’d shown my authenticity. He also offered himself up to help me in opening up decision making more. Had I taken another route, either by denying the issue, attempting to explain it away or worse of all, thrown someone else under the bus, I’d doubt that anything else I said that day would have been heard.

Choosing the “best tool for the job” is a mantra that many software engineers repeat when asked to explain their choice of tool, language or framework. In some cases, this choice is right, however far too many times in my career I’ve seen “best tool for the job” loosely translate to whatever was top of Hacker News this week.

The unintended consequence of always choosing the “best tool for the job” is a software inventory which spans multiple languages, frameworks, build systems and deployment tooling. The fractured ecosystem of development occurs as each developer or team makes their decision in isolation, only considering their immediate consequence. The silos and diverse technology stack reduces the opportunity for reuse, leading to teams reinventing boiler plate code for testing, monitoring, instrumentation, and perhaps even business logic.

In this environment products become harder to evolve, developers struggle to move between teams and the bus factor quickly tends towards one. Running systems become harder to maintain as the idiosyncrasies of each language run-time needs to be understood, leading to more specialists needing to be on-call. Containerisation and 12-factor apps (itself a kind of Sensible Default) have helped, but as anyone who has been on-call will tell you having a good understanding of the apps running is invaluable when the worst happens.

A recent medium post by Ozan Onay, ”You are not Google ”, shows another side to the “best tool” argument, rightly pointing out that you probably don’t need that cool new tech you’re proposing. Often a technology which is “good enough” really is good enough for your domain. There’s no need to go further.

I believe that teams can overcome these issues by employing Sensible Defaults. A Sensible Default is a practice, language, framework or tool adopted as the default choice for an engineering team. It’s the commonly agreed approach to building products, and the first thing to consider when starting a new project, or when there’s a new problem to solve.

As an example, you may decide to use React for your Sensible Default for front-end development, Flask and Python for building web services, and PostgreSQL as your database technology.

Notice, I’m not saying it’s the only choice, it’s just your default. Engineers are still empowered to choose other technology where necessary, but alternatives need to be justified in relation to their advantages over the Sensible Default.

I’m not the only one that sees the advantage in having defaults. In 2014, Ben Vinegar wrote a medium post about how “The best tool for the job, isn’t always ” where he describes the reasons for standardization whilst he was at Disqus.

So, whilst it may feel restrictive, and at odds with everything you’ve read about motivation and autonomy (check the book “Drive” for more on this) I believe that more teams should embrace the power of Sensible Defaults.

Documenting your Sensible Defaults #

The choice for the Sensible Default is one that should be carefully considered, both in relation to the technical problems it will need to solve and the skills in the organisation. A Sensible Default choice has wider ranging impacts that just the local team, so the candidates for the default need to be assessed against different scenarios aside and with the wider team. I’m not going to go into the process of making technology choices, as this topic probably deserves it’s own blog post, but I do want to comment on how decisions should be documented.

In agile environments, decisions around architecture and technology have a habit of being lost especially as teams move to more evolutionary ideas of architecture development . The motivations and context behind decisions become difficult to track, and it becomes difficult for team members, both new and existing, to keep track of them as projects develop.

Therefore, once debated, discussed and dissected, technology choices that become the Sensible Default should be documented for future reference, using something like Architecture Decision Records (ADRs).

By keeping a versioned record of Sensible Defaults the team not only have a repository when new developers can learn about the development environment, they also have a set of records which provide details of the decisions for later review as the context changes.

It’s likely that you already have a number of Sensible Defaults in your organisation. For example, you may have settled on Java for building web services, and you may find that most of your web services have been developed using Spring Boot . If this is a case, run a fit-for-purpose assessment on the technology in use and document your new Sensible Defaults.

Deviations from the default #

Whilst the Sensible Default should be the first choice, it’s not intended to be the only choice. Engineers can deviate from the default, providing it’s a considered decision.

When describing this concept to people, I often use the analogy of a fairground ride height restrictions. Good architecture decisions are based on clear system requirements, both functional and non-functional. A Sensible Default decision builds on these requirements by adding a set of people based requirements such as cross-skilling and training. This list of requirements is the bar a new technology must get over in order to be considered for use.

There’s always a cost to introducing a new technology, and anyone wishing to do so must provide details on how they plan to educate the rest of the engineering team. They can defer this cost, by limiting the scope of the training to those directly working with the new tech, yet in doing so, they carry the risk and burden of supporting the project until the technology is more widely known.

This may seem a little unfair on the team that wants to experiment, however it helps to increase the bus-factor within the wider team, and helps to reduce the chances of a single point of failure developing who is more prone to burn-out.

Deviations from the Sensible Default should also be stored in ADRs, with the relevant context and discussion that lead to the deviation. Storing decisions in this manner help teams avoid repeating conversations and re-debating choices when new team members join, or teams change. They also provide useful information for future maintainers of a project.

The number of deviations should be kept to a minimum. Should the number of deviations continually grow, it’s probably time to consider whether the Sensible Default is the right one.

Encouraging experimentation #

Many times when I explain the concept of Sensible Defaults, I’m challenged by engineers who believe that by setting defaults I’m reducing the scope of innovation and experimentation. It’s a fair challenge, and I believe that it’s important that new technology is evaluated and considered for use, lest a team end up with difficult to maintain legacy software that is hard to recruit new team members for.

To ensure a team doesn’t end up in this situation, I encourage the use of innovation or free development time. During this time, engineers are free to use whatever technology they like to build non-mission critical applications. This is the space to experiment with the new deployment technology, or JavaScript framework which Hacker News is blowing up with this week.

By using new technology to build real-world applications, automation and tools that help improve engineering efficiency, engineers make it past the “getting started” tutorials and start to understand how the technology works in a production-like environment. Achieving this level of experience with a technology means that the debate over it’s uses can reference existing applications, rather than just replaying the top comments and opinions from the blogosphere.

From chaos to cohesion #

Whilst engineers are comfortable adhering to standards (see arguments over the correct use of HTTP methods and status codes in RESTful web services as an example), when it comes to choosing technology, the drive to use the newest technology coupled with the move to service based architectures often leads to a somewhat chaotic and overly complex development environment.

I hope that I’ve shown here that by employing critical technology review and documenting the results as Sensible Defaults, engineering organisations improve their operational efficiency and resilience. The needs of the many outweigh the needs of the few .

However, Sensible Defaults are just that - defaults. They’re the first choice, not the only choice, and deviations are still possible, providing we make these choices consciously.

We can use innovation time and non-mission critical development for experimentation, helping to ensure that the development team has the opportunity to learn about new technology in a production-like environment.

Finally, I’d like to close with a quote I found whilst researching this blog post. Whilst the post it comes from doesn’t talk about software, I feel it sums up the need for Sensible Defaults well.

Sensible defaults can reduce friction and provide simplicity anywhere one can think to apply them. They are the bedrock of minimalist practice and a quiet mind. &emdash;&emdash; @patrickhone - Sensible Defaults