Managing software teams: the definitive reading list

Frederick Brooks once wrote:

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds castles in the air, from air, creating by exertion of the imagination.

In his classic essay, “No Silver Bullet”, he also wrote about software’s “essential” complexity:

The complexity of software is an essential property […] Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence. For three centuries, mathematics and the physical sciences made great strides by constructing simplified models of complex phenomena, deriving properties from the models, and verifying those properties by experiment. This paradigm worked because the complexities ignored in the models were not the essential properties of the phenomena. It does not work when the complexities are the essence.

It’s therefore no surprise that once a team develops expertise in a technical domain and starts to evolve a product from that foundation, there is still a huge heap of complexity left over.

This is made worse on bigger problems where more people are involved, thanks to Brooks’s Law. In addition to the software’s essential complexity, you also need to navigate the built-in complexity of human communication, and the associated combinatorial explosion of information pathways on growing teams.

Modern software management practices have thus evolved two distinct skillsets for navigating the problems of team coordination around complex software delivery. These two areas are product management and software engineering management.

Product management centers around areas like market positioning, product strategy, and customer-focused iterative development. The product manager, working closely with the engineers, determines the “what”, aligns the team around the “why”, and acts as a liaison to users and the wider market.

Software engineering management focuses on the practice of coordinating teams of programmers in the delivery of high-quality shipped software, often leveraging programming languages, tools, frameworks, cloud services, and lots of open source technology. Pithily, this is “the how”, as well as the art of making informed engineering tradeoffs, e.g. as relates to time-to-market, performance, quality, and cost.

This post will cover some of my favorite reading materials spanning product management and software engineering management, as disciplines. A preview of some of the titles is here:

I have curated these resources carefully, and I have recommended them at various times to my own product managers and my own software engineering managers over the years. I hope you find this a useful starting point for your own study.

It’s organized into a few sections, each featuring a few relevant books:

Here’s the full listing of book reviews, as well, for easy navigation. If you want to skip over this listing and jump right to the first review, click here.

Alright, let’s dive in!

Books about management as a high-leverage activity

The first thing to recognize about management activities of any kind is that they are “high leverage” activities. What I mean by this is that a management decision can ripple through an organization and have long-lasting effects on the day-to-day work of many members of your staff. This is very much unlike the decision of a single programmer, which is often (though not always) isolated in scope or impact. There is a nice short summary of the first book on my list available on Medium, “Top Takeaways from Andy Grove’s High Output Management”. This breezes through the concept of managerial leverage, and can help set your expectations for the rest of the readings on this list. It’s recommended. Once you get that high-level overview, these books can further solidify effective techniques at delegation and leverage in your organization.

High Output Management: the leverage of delegation

High Output Management, A. Grove, 1995.

For all intents and purposes, this is the “canonical” text on Silicon Valley company management, written by an engineer who worked his way up the ranks to become the CEO of Intel. This is the book most commonly recommended to startup founders by “in-the-know” Silicon Valley VCs. I recently discovered some nice notes on High-Output Management based on a presentation given by the VC, Keith Rabois. It’s entitled “How to be an effective executive”, and there is a corresponding slide presentation that is worth clicking through after you read the notes.

You might think between the summary/takeaways linked above and the notes linked in the last paragraph, you might have enough to be able to skip this book. But, that would be a mistake. Instead, I suggest you buy the book and use it as a starting point in your management journey. I recommend this to managers regardless of department (even spanning support, sales, finance). I find the book resonates particularly well with company founders and product/engineering managers.

Beyond Entrepreneurship: the leverage of culture and mission

Beyond Entrepreneurship, J. Collins, 1995.

One of my favorite business books overall, it covers businesses growing from 1-2 people to 10 people to 50 to 100, and it sort of “ends” there. It’s cool because it studies the early scaling of companies whose names you will recognize, but specifically centers around the mission/vision/strategy of founder-led companies, and how that emanates out from the founder to the rest of the employees via culture. I believe that managers of all kinds can learn lessons from this, as well-run teams are really “little” startups in disguise.

I first heard about the book when, in a video interview, Netflix CEO Reed Hastings was asked to give advice to new entrepreneurs, and he said, “Memorize the first 86 pages of Beyond Entrepreneurship by Jim Collins.” He went on to say, “Using the book’s lessons, you can fight the idea that as you get bigger, the culture gets worse.” Note: a second edition of this book will be available via Kindle and Audible, as well as print, in December 2020; it’s called BE 2.0 and is available here.

Managing Humans: the leverage of human connection

Managing Humans, M. Lopp, 2016.

This book is focused on people management in software projects. It is written by an engineering manager who is known online as “Rands” (with a great blog, randsinrepose.com), whose career spanned a number of classic Silicon Valley companies, including Borland, Netscape, Palantir, and Pinterest. After this book’s publication, Rands went on to leadership roles at Slack and Apple.

The book provides the engineer’s perspective on good vs bad managers. I find that for programmers-turned-managers this book provides a relateable explanation for why basic management practices — like running regular and effective 1:1’s, moderating team meetings, and listening deeply to problems reported by individual contributors — is key to team performance. I also find that for product managers, and managers of other teams, it provides an interesting window into the programmer-turned-manager, and the way they approach problems. It also provides some empathy for what it feels like to be managed well or poorly, as a programmer. Note: The author has a new book published in 2020 called The Art of Leadership, but I haven’t checked it out yet.

Books about product marketing and product management

Once you understand that management is a high-leverage activity, you might become more curious about how, exactly, to make the right high-leverage decisions in your management role. These books cover product marketing and product management, two areas that center around unlocking the value that your programming team can deliver through software. One way to think about this is that, if you have a talented programming team, they can build pretty much anything. So, as Brooks once said:

The hardest single part of building a software system is deciding precisely what to build.

Understanding product marketing is thus your first stop on this journey. You first need to understand how customers perceive software markets. This sometimes goes by the name “market positioning”, and involves identifying an ideal customer profile, or ICP. Once you have identified the category and customer persona, you can more effectively guide your team toward building for them. You’ll then need to learn about product management — which is about empowering your engineering team to build for that customer, while also acting as a liaison to the market. This is a role typically done by product managers, but is also often done by founders or engineering managers when teams are so small as not to be able to afford a full-time product manager. Finally, the last couple of recommendations in this category will center around the iterative product development process: how to actually hit your releases and get your product to market — and how to avoid a death march along the way.

Obviously Awesome: how to identify your ideal customer profile

Obviously Awesome, A. Dunford, 2019.

The (only) good book on market positioning, and it’s a very awesome book. Very helpful for thinking through the proper marketing and positioning of new features, which aids in ensuring you build stuff people actually want. Also important to understand how customers perceive your market, and how that perception often fuels your product’s adoption and growth.

The Startup Owner’s Manual: how to ship with limited runway

The Startup Owner’s Manual, S. Blank, 2012.

When I was getting going in the world of startups around 2008-2009, Steve Blank’s book, The Four Steps to the Epiphany, was passed around quietly among startup founders and their investors, as a “secret manual” of sorts for building successful software products. However, The Startup Owner’s Manual feels, to me, like a second edition of that book, rewritten to make sure it excluded dated examples and had a clearer narrative style. This might not seem like an obvious title in a list of books about product marketing and positioning. For example, should you read this book if you are working at an established company, startup or otherwise? I think so. I generally disagree with the idea that a product manager is a “CEO of product”, but I do agree with the idea that, like a startup CEO, the product manager has to worry much more than other members of the team about runway, time-to-market, and avoiding time sink activities. If you come from a big company to a much smaller one (e.g. if you used to work at a 500+ or 1,000+ employee company, and are now joining a sub-100 employee startup), this book will also be effective “deprogramming” on big company thinking.

Inspired: the one book for technology PMs

Inspired, M. Cagan, 2017.

If there is a single book to recommend to new product managers on software teams, this is it. You can get a quick sense of the philosophy in this book in the author’s widely-cited 2014 essay, “Good Product Team / Bad Product Team”. Indeed, the entire svpg blog has a lot of good essays available for free, but the book is very much recommended. This is a book 100% focused on product managers and the role they play at software companies of varying shapes and sizes. Also spends a good amount of time diagnosing one of the greatest sins of Silicon Valley: building something technically cool that no one wants to use or buy.

Shape Up: the one book on lightweight process

Shape Up, R. Singer, 2019.

Basecamp’s modern and practical (free!) book on product and project management. Takes a very calm approach to iterating on product, by being designer-led, timeboxed (6-week iterations), and light on process. If there’s one book you read on software delivery process, this is a good choice. In my opinion, there are way too many books on software delivery process (the ‘agile’ and ‘scrum’ crazes of the early 2000s are mostly to blame here), and too much process can often suck the soul out of the creative craft of building software. But, Shape Up strikes the right balance.

Managing the Design Factory: a dense read on cost of delay

Managing the Design Factory, D. Reinertsen, 1997.

Terrible title, but excellent and unique book on management of creative and design-driven projects. The key concept explored in the book is “the cost of delay”, which is to say, reconciling the real pressure you’ll get from your business to “ship whatever we possibly can, and ship it yesterday” with the internal pressure you’ll feel from programmers who will want to “ship the perfect thing, tomorrow, or whenever it’s ‘ready'”. Written in the late 90s, and takes a lot of lessons from hardware/software engineering. His second book, Principles of Product Development Flow, is much more famous. But, IMO, this is mostly due to its much better title. This book has a worse title, but is a much simpler read, and expresses many of the same key concepts. Both are already a bit dense for a business book, so I’d definitely recommend starting with this one. (Reinertsen himself has described Product Development Flow as the “double black diamond ski slope” of his principles, whereas Design Factory is the “green circle”.)

Making Things Happen: a light read on project coordination

Making Things Happen, S. Berkun, 2008.

The original title of this book was “The Art of Project Management”, but it was re-titled when “Project Management” became a bit of an anti-pattern in software teams, what with the rise of PMP certifications and similar. The lessons of the book were drawn from the author’s time acting as a product manager for Microsoft on the Internet Explorer team during the browser wars of the late 1990s, but, at that time, the term “product manager” was not in widespread usage. If I were to select a new title for this book, it’d be “The Art of Product Management.” The more abstract “Making Things Happen” does make some sense, however. Fundamentally, this is a book about spurring action on your engineering team — about acting as a catalyst, and a release coordinator, for teams that have their own essential complexity to deal with in the engineering problems and time pressures at hand. This is very much a “nuts and bolts of product management” book, and so will be especially helpful to inexperienced or young managers.

Making Work Visible: the best bits of ‘kanban’, summarized

Making Work Visible, D. DeGrandis, 2017.

Do you have a team where it seems like no matter what you agree to work on, they always end up working on something else, instead? If so, you might have a work visibility problem. I find this is especially common on teams where the engineers are expected to do “double-duty” in other more reactive roles, like DevOps, SysAdmin, Customer Integration, and/or Customer Support. It can also happen on teams where the engineers are a bit too focused on “new shiny” technologies, or where technical complexity has spiraled out of control due to poor engineering management. The kanban principle of creating visibility into all work and tracking work-in-progress can help you debug and diagnose these problems, by ensuring that rather than a “product” backlog of intentional work competing with a “shadow” backlog of reactive work, you have unified visibility into a single global backlog and global team-wide work-in-progress.

Books about debugging dysfunctional product cultures

Even the best product team cultures have a little dysfunction. We’re all human, after all. But, if you’re hired into an existing team, your first task might be to figure out just how much dysfunction, and whether you can do anything about it. These books cover various “failure scenarios” of product teams, and how to resolve them. This spans many areas: having an environment that’s not conducive to creative work; having uncollaborative programmers and/or uninclusive programmer practices; having the wrong business strategy set for a product team, such that no amount of ingenuity can lead to success; having overconfident engineers who succumb to programmer hubris; as well as, a well-intentioned and common need to ship features without purpose or customer impact, which ultimately leads to organizational waste and customer dissatisfaction.

Peopleware: shipping in spite of management

Peopleware, T. DeMarco, T. Lister, 2013.

Management of creatives in tech, distilled. Written for the 90s and aughts era of “IT”, but equally applicable to modern software teams. A bit of bias for colocation vs distributed teams in this one, however. The key insight of this book is that, often, “management” gets in the way of creatives shipping toward the company’s (and customer’s) goals, so the key task of management is to create an environment where the creatives can actually get their work done. Some parts of this book focus a lot on the physical spaces where programmers work, which might read as dated in an era of fully distributed collaboration, but we have a whole section on fully distributed teams later on.

Team Geek: moving beyond the hero programmer

Team Geek, B. Fitzpatrick, B. Collins-Sussman, 2012.

This is the software engineering management book that came out of Google’s Chicago engineering office in the early-to-mid aughts. The target audience is engineers who want to get out of the mindset that “the only thing that matters is code”, and refocus attention on the value of communication and teams. The author considers the book to be a “modern Peopleware, but from the individual contributor perspective, rather than the manager perspective.” I enjoy this book because it effectively shatters several “programmer myths”, including the genius/hero programmer, or the idea that the best programmer team size is a team of one. These myths resonate a lot with programmers, lined up with several mythologies behind open source projects like the Linux kernel (Linus Torvalds) or the Python interpreter (Guido van Rossum). But this book makes it clear that the best software is built by teams, and that though single programmers can be very productive, it’s really effective teams of programmers motivated by common purpose that are the most productive. This is also a good book for managers to recommend to the, ahem, “ornery” programmer contributors they may commonly come across on teams.

The Goal: identifying the critical constraint

The Goal, E. Goldratt, 2014.

This is probably the strangest business book on this list, but it’s fascinating. This is a “business novel” used to illustrate various concepts from a now very-well-understood business framework called “The Theory of Constraints”, or ToC, which has its main applications in lean manufacturing. The book is written in a super-unconventional style. In my view, the 30th anniversary audiobook on Audible is the way to go for this title, as I think it’s more fun as a dramatized audio book than as a sit-down-and-read “business novel”. The key learning you’ll take away from this one is that usually business performance is dependent on one or two critical goals/metrics (or “constraints”), and so no amount of individual ingenuity or team performance will overcome those if the strategy is set up in opposition to them. For example, given my background in SaaS, at a certain moment in my company’s history, it became clear to me that number of new leads / prospects / users / use cases of our software, not the engagement of our existing happy users / customers in a core use case that was already working, was the key limiter on the company’s growth. So if the product team only focused on building new features for existing customers in their core use case (which can seem like an obvious and “safe” decision), we would be missing out on growth in new use cases (and in new markets). This analysis led me to push our organization to hire a CRO, and this hire worked to accelerate our software sales velocity. But it also led me to focus a product manager on an emerging ideal customer profile for our product, and to reboot our product positioning and marketing, and both of these things also worked to accelerate our product’s adoption in new markets. Sometimes, you become the victim of your own success, and The Goal helps you realize how to make a high-leverage decision to get back on track.

Escaping the Build Trap: leaving behind the feature factory

Escaping the Build Trap, M. Perri, 2018.

Sometimes your team gets good at shipping, but, it turns out, merely shipping isn’t enough. It matters a whole lot what you ship. This book is focused on the perils of “build new features forever and ever” death march projects, especially in enterprise SaaS software. It has a bunch of practical tips and tricks for breaking the cycle of feature development to focus on real customer problems. Similar to “The Goal”, it’ll help you identify what the real business and customer constraints are, especially in the context of high-tech and enterprise SaaS.

Dreaming in Code: recovering from engineer hubris

Dreaming in Code, S. Rosenberg, 2008.

This is a wonderful journalistic foray into a well-funded software project — Chandler, an “Outlook-killer” funded by Mitch Kapor, the Lotus creator, in the early aughts — and everything that goes wrong up until the project’s failure. Probably the best modern “software project postmortem” ever written, focused on all the pathologies of software engineers and their managers when a project is off-track. If you’re interested in this genre, the film “General Magic” is the best Silicon Valley software/hardware postmortem ever captured in documentary form.

Books on the psychology of deep work

If you’re a programmer-turned-manager, it’ll be obvious to you that deep work is necessary for programmers to do their best work. That’s because programming is, very much, a flow activity. But, if you don’t come from a programming background, it may not be obvious to you the degree to which productivity is linked to deep concentration, and the many (many, many!) ways that modern businesses break the concentration of their creative workers. I discussed this a bit in my CTO Summit presentation, “Fully distributed and asynchronous: building eventually-coordinated teams that ship”.

These books will help you build empathy for deep work and flow.

The surefire way to earn the respect of programmers you work with in a management context is to protect them from organizational distraction and to encourage them to tackle their problems deeply and thoughtfully, with the time and space to drive their code toward a shippable state. What’s more, these books will also help you understand how good work feels to the best programmers, and why sometimes, what seems like a very small ask — a recurring status meeting, a request for regular reporting on a metric, a direct ping on Slack for a single customer’s problem — can have a much higher cost than you might initially think, and might ultimately be self-defeating toward your own goals as a manager.

Flow: the phenomenology of work

Flow, M. Csikszentmihalyi, 2008.

This is the “one book to read on productivity” that was recommended to me by a manager, when I was a young programmer, and leaning in to becoming a technical lead on a fully distributed team. It’s a thick book and is really more a work of psychology. But this book introduces two interlocking ideas: (1) that the way work feels to the creative worker is very important; and (2) that ‘flow state’ is a real physical change in the body/brain, which influences productivity and creativity directly. This is a precursor to other books on this list, like Drive and Deep Work. I actually re-read this book very recently and found it to be inspiring in a very different way, now that I am a full-time manager. It made me realize that creativity and flow is also important to me personally, and thus inspired me to mix in some “flow time” to my more reactive “manager schedule”. But ultimately, this book will help you understand what makes creative and technical people tick, from a psychological standpoint.

Drive: autonomy, mastery, and purpose

Drive, D. Pink, 2011.

If Flow strikes you as a bit long-winded or a little too academic, then this book, Drive, is the one book on engineer motivation to read. It’s sort of a like a shorter/condensed version of Flow, and more readable. Funny enough, this author also wrote an excellent book on the psychology of sales people, entitled To Sell is Human. In an enterprise SaaS context, I recommend Drive to salespeople, so that they can understand engineers. And then I recommend To Sell is Human to engineers, so they can understand salespeople. It’s an effective way to build cross-department empathy.

Deep Work: creating time and space to think

Deep Work, C. Newport, 2016.

A good friend of mine, with whom I often trade management book recommendations, once described this book as follows: “has a great title, and the title describes the key concept of the book — but! the key concept of the book didn’t need an entire book to describe it!”

I would tend to agree with this assessment. That said, if you haven’t thought much about deep work and programmers, this book will certainly get you up to speed. In it, an academic computer scientist and programmer changes his life to get back the focus required to do the computer science deep work that he loves. He documents the journey, but also uses historical examples and academic studies to showcase just why deep work (focus, concentration, long blocks of uninterrupted time) are so essential.

The book is also a nice antidote to our post-2016 era, where it feels like social media tools (like Twitter) and enterprise communication tools (like Slack) are using every trick in the book to interrupt our attention and steal our focus. If this doesn’t feel like a book you can devote to reading in its entirety, some of the key concepts that Newport describes here are humorously summarized by proxy in a talk about the “conditions of creativity” by the comedian John Cleese. The 1991 talk is linked/embedded on BrainPickings here and summarized by Quartz here.

Books about fully distributed teams

The Year Without Pants: grokking distributed teams

The Year Without Pants, S. Berkun, 2013.

A non-technical project manager (really, product manager) from the Microsoft era joins Automattic, a fully distributed team with open source DNA, and he shares what he learned in that cultural setting. Yes, this is the same author as Making Things Happen, from earlier in the list, but it’s written when he’s at a very different stage in his career. One of the few books written about the way fully distributed teams “feel” and the dynamic between in-person get-togethers vs online-first (or online-only) collaboration.

Remote: turning distributed into an advantage

Remote, J. Fried, D. H. Hansson, 2013.

The subtitle of this book is “Office Not Required”. This is the book on remote work written by the Basecamp (formerly: 37 Signals) folks. Though the team had a Chicago office, they operate that office on “library rules”. (On my team at Parse.ly, we’d refer to this as, “office as internet cafe, not office as headquarters.”) This is a short and easy read which can be used to onboard new hires to a distributed team, or to change the mind of office/colocation holdouts.

It Doesn’t Have to Be Crazy at Work: the calm company

It Doesn’t Have to Be Crazy at Work, J. Fried, D. H. Hansson, 2018.

The original working title of this book was “The Calm Company”. This is a book on “calm” work written, again, by the Basecamp founders. Though not entirely about distributed teams, this is a book that makes it clear how one can set up an “interruption-free” work culture atop digital tools. Unlike Remote, which is written from an individual contributor’s perspective, this book is written from a manager’s perspective, and emphasizes how to create the feeling of calm on your team, that allows the remote creative work to thrive.

Books on programmer mindset and philosophy

An Elegant Puzzle: product teams as systems

An Elegant Puzzle, W. Larson, 2019.

A book by an engineering manager at Stripe, focused on growing technology companies and their teams while viewing the whole company as a “system” that can be tamed using engineering modeling and analysis techniques. Note: This is a nice book to hold in your hand with an attractive hardcover printing, which is rare for books in this category. I once used this book, and its table of contents, as the “syllabus” for a multi-month software manager book club.

A Manager’s Path: programmer management as a career

A Manager’s Path, C. Fournier.

Written by a programmer-turned-manager, this book documents her path from individual contributor to CTO, and what she learned along the way about programming and management careers. Good for understanding how software engineers think about “leveling” in their careers. It covers topics like the split manager vs individual contributor paths at large tech companies; what different titles and roles mean on product teams; how to interact with the board; how to create a long-term roadmap; how to tackle key technology choice decisions; and how to manage “difficult” people on your team.

The Mythical Man-Month: team and system complexity as a liability

The Mythical Man-Month, F. Brooks, 1995.

Quoted earlier on in this post, this is one of the timeless and classic texts about software engineering management, dating all the way back to 1975 and the programmer culture at IBM, at that time. Though it talks of IBM mainframes and low-level operating system development, the lessons learned for large engineering teams has resonated through the ages. It’s the closest thing software engineering management has to a “founding text” for the discipline. Note: This book has some dated language, not just about technology, but even about business in general. For example, some don’t enjoy the term in the title — “Man-Month” — and Brooks has a tendency to reference “man”, “God”, and so forth. So you have to read it while doing a “modern dialect” translation of sorts. If you’re curious about my other thoughts on “old” programmer books, you can take a look at this lobste.rs thread.

Hackers and Painters: lateral thinking as a way of life

Hackers and Painters, P. Graham, 2004.

To me, this book served as the starter pistol shot of the race for a new world order of tech companies established 2002-2010 and beyond. This was the beginning of the era where programmers went from being a cost center for “IT organizations”, toward being the key talent (and profit center) for all modern tech-infused businesses. The author is Paul Graham, writer of many fine essays, the founder of Y Combinator, and an early founder and engineer at Viaweb, which eventually became Yahoo! Stores.

He successful predicts the programmer-centered rearrangement of the business world. In this new world, programmers (and their ideas, their creations) run most of the world around us, as is widely accepted now. Harnessing the power of automation becomes the key task of modern knowledge work. As a manager, this book will help you understand why productive programmers are not interchangeable “coding widgets”, but are, instead, unique creative artists with deep motivations and boundless curiosity. It’ll also help explain why many of the most product-minded engineers end up creating companies of their own.

The Cathedral and the Bazaar: productivity through open source

The Cathedral and the Bazaar, E. Raymond, 2001.

Although some will consider this book a historical relic, it is also one of the most influential books in programmer circles, whether directly or indirectly. This book is about the power of open source software, and the thinking behind its communities. In my view, open source is not given the credit it deserves for completely altering the fabric of our lives as knowledge workers. This book digs in on the motivations of open source developers, and how that contrasts from typical “top-down” R&D organizations. Given the timing of this book in the 1990s, the key target of ire is Microsoft (“the cathedral”), which was then seen as the monopolist and centralized approach to software management and user control. The key counter-example is the Linux kernel and its GNU utilities (“the bazaar”), then seen as a free-wheeling and decentralized approach to software evolution and user empowerment. Even if programmers have not read and internalized this book, they have probably been influenced by its thinking.

A Philosophy of Software Design: code as design

A Philosophy of Software Design, J. Ousterhout, 2018.

This is the only book on the list that contains code examples! But, it’s short and the writing around the code examples is comprehensible and eloquent. This book can help you understand the everyday trade-offs that programmers make, not in the product or the user experience, but in the code itself.

This is often the hardest part of the job for non-programmers to empathize with — after all, customers usually can’t see your code, and usually they don’t care how the code looks. But, as craftspeople and artists, programmers care deeply about the code and how it looks — and how it enables, or disables, future code evolution.

(I am personally no different; I even wrote and published a popular style guide for Python programming!)

Unlike a lot of other books on “code design”, this book doesn’t just give examples, but also explains the business reasons and product impact of code design decisions, and thus can serve as a helpful guide to build empathy with programmers while they, as Brooks put it, “build castles in the air, from air”.

Great management leads to great businesses, and happy employees

One of the things I’ve learned through my years of software team management is that even the best team will fall down with bad management.

Employee happiness isn’t linked so much to a great product, great customers, or a great mission. Those things matter. But management matters more. Interactions with managers are what really affects how the job feels to every employee. Thus, I believe one of the most useful things we can do, as an industry, is improve the quality of our management. If management is a high-leverage activity, then teaching good management to others is the ultimate high-leverage activity.

It’s often said that employees don’t leave the job — they leave the manager. And this is true. So, if you’ve got a early/voluntary attrition problem, you may just have a management problem. And that’s the first problem you need to fix before you can reliably get any work done.

But, here’s the good news. Management can be learned. And this reading list is a start. If you have other recommendations, or questions, feel free to reach out to me at @amontalenti on Twitter.

Yes, I really did read every single book in this list. I read a lot. For other similar round-ups, but more in the technical direction, you can check out my popular post on rapid web app development, which includes long-form reading, videos, and technical books covering Python and JavaScript. You can also take a look at my round-up of the 3 best Python programming books for your team.

Whenever book image art or links to book product pages were used, I provided images and links from Amazon.com, which might include affiliate link codes.

Leave a Reply