My essential reading list for creating software and building teams
Learning styles differ greatly, but I learn most quickly by reading and then immediately trying to do, so here is an introduction to my favourite books:
Leading Lean Software Development, Mary Poppendieck and Tom Poppendieck
In this excellent book on leading software product development, Mary and Tom Poppendieck take you back through the history of software development and demonstrate that practices including iterative development, testing early and often, reducing dependencies and understanding your customer’s needs deeply have always worked, regardless of the project methodology they get wrapped up in or the technology being used. Understanding the message of this book will hopefully let everyone understand the practices, principles and structures you must establish for any large, complex undertaking to be successful.
Peopleware, Tom DeMarco.
Building great teams takes work, Peopleware will help guide you, but it is still up to you to make it a reality for your team. Covering everything in a little bit of detail from hiring to management to office design, Peopleware is the first book I recommend to new managers and team leads.
The Lean Startup, Eric Ries.
Successful products are not delivered by storks down chimneys, and you aren’t going to create the next revolutionary product by buying a black turtleneck. Building products that people find useful, interesting and are willing to buy is excruciatingly hard work. But if you are ready for that, The Lean Startup provides a nice insight into how you can measure and understand the mismatch between your prototype and your customer’s true need and iteratively close the gap before you run out of money. The first book I recommend to new Product Leads.
The Pheonix Project, Gene Kim, Kevin Behr and George Spafford.
If you haven’t worked on a disaster of a software project, you might not have got around enough. The Phoenix Project is written as a novel and provides an insightful look into common ways that projects (particularly enterprise software) fail and what to do about it. This is the book I would paint like a life preserver, tie a rope onto and throw to anyone who is drowning in a failing project.
Slack, Tom DeMarco.
Efficiency can be desirable, but it can also kill your team and your project. My example would be that cross-functional teams can appear to be inefficient because they are eliminating sub-optimisation (designs drawn per month, lines of code written per day), while they are actually delivering better organisational outcomes (valuable features delivered to customers, quicker service delivery). Efficiency can result in queueing, lack of responsiveness and ultimately devastating loss of effectiveness. This is the book I recommend if you are looking to improve processes and service.
High Performance Management, Andrew S Grove.
No ebook available.
Large enterprises come with large management challenges, this is a great book if you want to succeed in such an organisation. It will help you understand the dynamics and tradeoffs of functional and divisional structures, the operation of businesses at scale and make performance management processes more effective. This is a book I only recommend to people moving into management at large corporations.
Zero to One, Peter Thiel.
Available on iBooks.
Your friend has a cool idea for a product, they want you to help them build it and they say this is your chance to be in on the ground floor at the next unicorn company. Your colleague has an idea that will transform the company into a tech powerhouse. These are times to be sceptical, but they seem like cool ideas, how do you evaluate these opportunities? Zero to One says that most of your ideas and those of your friends and collleagues have no potential to achieve a monopoly at scale and are therefore capped in their potential or doomed. Thiel makes the case that unless you can monopolise a market at scale, you are not building the next Facebook. I don’t recommend this book to many friends because it would be rude in the circumstances, but I believe you should read it.
Continuous Delivery, Jez Humble and David Farley.
There are some things that I would argue are best hand delivered, flowers and pianos come to mind…production software does not. When you start hacking away on a new idea and you’re building locally and showing it to your mother, everything seems easy. It tends to stay easy until you work with other people, then it gets harder, then you get real customers with real expectations about reliability and security and performance and lots of other annoying essentials that make building, maintaining and operating software products a big job. This book describes the automation tools and practices that will eliminate the repetition and get your code into production fast enough to keep even the most demanding customers and project managers satisfied. I recommend this book to anyone making the leap from building apps as a hobby to being part of a delivery team with a serious job to do.
Waltzing With Bears, Tom DeMarco.
The average delivery duration for software projects is 150–200% of their original estimated duration, you understand this as someone close to these projects, but the business just doesn’t get it. If you are in a team or product management role, Waltzing with Bears makes you realise this is largely your fault. We have all been guilty of providing estimates without uncertainty explicitly stated and treating earliest possible delivery dates as deadlines. Waltzing with Bears eloquently makes the point that ‘Risk management is project management for adults’ and for that reason I recommend it to anyone involved in estimating or managing software projects as well as those in business management budgeting on software projects being delivered.
