Even though I have a physical copy of this book, I never got around finishing it until I bought it on Kindle — power of digital convenience :)
Debugging Teams is a very interesting read, especially considering the experience the 2 authors bring to the table: large, Googl-y organizations and fat OS communities.
The authors focus (a lot) on their personal experience, adding references and elements from other publications as well (for example PeopleWare by Tom DeMarco), and suggest a framework called HRT (humility, respect and trust) to cultivate great relationships and inspire the people you work with.
Some interesting quotes from the book:
Many people work on products that have great significance, but they are kept at arm’s length from the positive effects their products may have on their company, their customers, or even the world. Even in cases where the product may have a much smaller impact, you can motivate your team by seeking the reason for their efforts and making this reason clear to them.
There’s an old saying to not let “the perfect be the enemy of the good,” and in your quest to create a high-performing team, you need to be just as vigilant about avoiding perfectionism as you are about calling out more obvious disruptive behaviors.
Always start by giving the person the benefit of the doubt
“If you don’t miss at least one flight a year, you’re getting to the airport too early.” This is a great metaphor for creating any sort of product: if you don’t fail at least once a year, you’re not taking enough risks.
If you don’t take risks in your work, you’ll have fewer failures, but you’ll have fewer big successes as well.
only rarely will you find a person in an organization who overcommunicates, so don’t hesitate to update your team’s leader on what you’re doing before she asks you what’s going on. Drop her a quick note when you hit an obstacle, score a victory, need something, or expect something.
Fear of failure is one of the most common traits of bad managers. This insecurity tends to make them very conservative, which is antithetical to the work style of the typical engineer. If your manager doesn’t want you to take risks, there is little opportunity for you to inject your own ideas into your product and you’ll usually wind up implementing (by rote) the product someone else designed.
It boils down to this: is your manager serving you? Or are you serving your manager? It should always be the former.
Even if you’re prepared to beg for forgiveness, choose your battles wisely — every time you have to plead your case for something or go up against someone else in your company, you’re spending your political capital.
Be strategic and fight for things either that matter or that you’re pretty sure you have some chance of winning.
you need to underpromise and overdeliver whenever possible.
a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide.
people will remember you as the person who helped them out in a jam.
A good Three Bullets and a Call to Action email contains (at most) three bullet points detailing the issue at hand, and one — and only one — call to action.
Google is great at this; it has a deliberate policy of not preannouncing features for any product.
“Speed is a feature.”
Is your software trying to accomplish too much? This sounds like a silly question at first, but some of the worst software out there is bad because it’s overly ambitious. It tries to be absolutely everything to everyone. Some of the best software succeeds because it defines the problem narrowly and solves it well. Instead of solving every problem badly, it solves really common problems for most users and does it really well.
think of your software as a simple toaster oven. Does it cook everything? Absolutely not. But it cooks a lot of really common food and is useful to almost everyone who encounters it without being overwhelming. Be the toaster oven. Less is more.
This is what we like to call “hiding the complexity.” You take a complex problem and break it up, cover it, or do something to make the software seem simple anyway.
Google Search is another well-known example of hiding complexity. Google’s interface (and barrier to entry) is almost nonexistent: it’s just a magic box to type in. Yet behind that box, there are thousands of machines across the planet responding in parallel and doing a search after every keystroke you type. By the time you hit Enter, the search results have already rendered on your screen. The amount of technology behind that text box is jaw-dropping, and yet the complexity of the problem is hidden from the user. It behaves like Magic.3 This is a great goal for a creative team to pursue since it’s essentially the epitome of product usability.
Give users respect by default. A common misconception that powers our fear of direct user interaction is the myth that users are stupid. They’re not writing the software, after all, so they’re just “clueless users,” right? When you finally have an opportunity to interact with them, the most important thing to remember is to avoid condescension. Being a savvy computer user is not a fair measure of general intelligence. A lot of brilliant people out there use computers as a tool and nothing more. They’re not interested in debugging or following scientific methods to diagnose a problem. Remember that most of us have no idea how to take apart and fix our cars; assuming your users are stupid is akin to an auto mechanic thinking you are stupid because you don’t know how to rebuild a transmission, nor even care how to diagnose a transmission problem. The car is a black box — you just want to drive. For most people, the computer (and your software) is a black box, too. Users don’t want to participate in the analysis process; they just want to get some work done. It has nothing to do with intelligence!
The book is not super expensive (sells between 15 – 20$) and I’d definitely recommend it — even if you’re not in a managerial position (or don’t even plan on getting there) it gives you quite a few interesting pointers on how to navigate in more structured orgs, teams and complex situations.