Book Review: Managing the Unmanageable

Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and TeamsManaging the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams by Mickey W. Mantle
My rating: 5 of 5 stars

If you are new to managing a team this is a must read for you. While the book is intended for managers of programmers (developers, software engineers, etc…) I believe this book applies to just about any sort of creative. Obviously, some sections will be less applicable to architects like the agile sections, but in general, creatives are creatives. The authors, to some extent, recognize this by continually comparing software developers to musicians. Arguing, in fact, that the best programmers are typically fantastic musicians. There’s a similarity in the way the brain works between musicians and developers. I think this applies to other artists as well, especially ones that under went rigorous training to be an artist. There are processes you need to follow to enact your vision.

Anyway, the book itself offers very candid advice on everything hiring, firing, building local and remote teams, coaching, rewarding, and having fun.

The authors argue that hiring is the most important job of any manager. I think this is true from my experience interviewing people and managing people. Whenever you hire someone the work environment shifts. So you need to make sure that whatever change the person brings is a net positive for the team. To ensure that you get the right combination of fit and skill you must have a rigorous process for finding potential candidates, screening candidates, and interviewing candidates. If you do not you will pay for it later by losing your best people or being required to fire that hire in the future for lack of performance.

All this and templates are laid out in the book. The tools and rules of thumb are fantastic for first time managers and managers that have struggled to hire the right team.

The authors argue the most important functions of a manager are Hiring/Firing, Coaching, Developing individuals and teams. I think this is right. The manager should be technical enough to help with the team as needed, but shouldn’t be expected to roll up their sleeves too much. Their skill is more important in investigating logical approaches than the specifics of coding. However, there are a lot of people that believe their manager should be able to do their job. Which i think has a lot of merit.

This book also has some great ideas of how to convert traditional managers into agile managers. Ironically, if you follow their advice through most of the book, you’ll be well positioned to be an excelled agile manager positions to remove impediments.

I highly recommend this book for any one managing programmers, engineers, or creatives in general.

View all my reviews

Methodology, managers, and projects

When working on a project there are a few different ways to manage those projects. One is the traditional waterfall approach, which is your top down project where you have to use Gantt charts to figure out how long you think it’s going to take up front, where you’re given a set date that can’t change without a lot of effort to do a certain amount of poorly defined requirements, and a set amount of money to do the project. This approach has been how Windows and many video games have been produced in the past. It’s not really extremely effective and really no one really likes working a project conducted using Waterfall methodologies. There are risks, projects get cancelled and the project management can seem to be capricious and opaque. This leads to lack of trust and belief that management has the best interest in mind for both the project and the employees on the project.

To address these concerns a group of people created the Agile project management methodology. The goal was to value working software over documentation. Which means that each bit of software is broken down into the minimum viable feature, or the smallest piece of working software that could be packaged and used by a customer. The goal is to manage the project through adjusting how many of these features are going to be finished by the go live date. Effectively you build small bits of work instead of finishing one giant massive piece of software.

This approach is effective for other types of technology that have a modular architecture. There’s some minimum viable product, where you need a minimum set of features for the product to actually work. For example a cell phone needs to have a combination of features to function properly. Things like bendable screens would not be in the minimum viable product, but an excellent touch screen would be. These minimum viable features can be modulated based on the Kano model – which is useful for determining if a specific feature is basic, a pleaser, or a delighter. If the feature falls into basic, you must include that feature if you’d like it to be a success. However, those minimum features don’t guarantee a successful product, you’ll need to include pleasers as well as delighters. Those are the pieces of scope that you will be able to eliminate to make sure you actually launch the product on time.

Issues with these projects come whenever there is a mixture of methodologies. When management believes projects must be managed through waterfall through a central project results office while the development team believes the project is being managed through the agile methodology. This creates serious issues whenever there is miscommunication, lack of information, or lack of understanding the real status of the agile team’s approach. This is exacerbated by the required openness in the agile approach (where you are supposed to continually learn from your mistakes and have a conversation about all the problems you’ve had – to fix them) while in waterfall it is better for people to hide and place blame elsewhere whenever things are not going well. Not because people are bad, but the incentives are in place to behave this way. With a single option of go/no go, it’s better to minimize the known risks as if things are misunderstood as going poorly it will drive management to take action. While in an Agile team, discussing the true status of the project is vital through self policing and partnering with other agile teams to address the problem. The greater the likelihood of success of the projects.

This conflict and a switch from governance in the agile methodology can and will destroy the trust the various agile teams have developed. An organization needs to fully commit to a single project management methodology or it will struggle to complete any project within scope and budget and will demoralize the leaders of projects being worked in agile, as waterfall would likely be the methodology that management selects. Leaders of Agile projects should leave organizations that undercut the agile teams, as it will not stop and will have dramatic impacts on their careers in the long run.