PREFACE

My favorite word in the English language is how. How does this work? How was this made? How did they do this? Whenever I see something interesting happen, I’m filled with questions that involve this small but powerful little word. And most of the answers I find center on how people apply their own intelligence and wisdom, rather than their knowledge of specific technologies or theories.

Over years of building things and comparing my experiences to those of other managers, programmers, and designers, I’ve learned how to manage projects well. This book is a summation of those ideas. It includes approaches for leading teams, working with ideas, organizing projects, managing schedules, dealing with politics, and making things happen—even in the face of great challenges and unfair situations.

Despite the broad title of this book, most of my working experience comes from the tech sector, and in particular, Microsoft Corporation. I worked there from 1994 to 2003, leading teams of people on projects such as Internet Explorer, Microsoft Windows, and MSN. For a few years I worked in Microsoft’s engineering excellence group. While there, I was responsible for teaching and consulting with teams across the company, and was often asked to lecture at public conferences, corporations, and universities. Most of the advice, lessons, and stories in this book come from those experiences.

Although I come from a software and web development background, I’ve written this book broadly and inclusively, calling on references and techniques from outside the engineering and management domains. There is great value here for people in the general business world. I’m convinced that the challenges of organizing, leading, designing, and delivering work have much in common, regardless of the domain. The processes involved in making toaster ovens, skyscrapers, automobiles, web sites, and software products share many of the same challenges, and this book is primarily about overcoming those challenges.

Unlike some other books on how to lead projects, this book doesn’t ascribe to any grand theory or presumptively innovative philosophy. Instead, I’ve placed my bet on practicality and diversity. Projects result in good things when the right combination of people, skills, attitudes, and tactics is applied, regardless of their origin or (lack of) pedigree. The structure of this book is the most sensible one I found: focus on the core situations and provide advice on how to handle them well. I’ve wagered heavily on picking the right topics and giving good advice over all other considerations. I hope you find that I’ve made the right choice.

Who should read this book

To see if this book is for you, I suggest flipping back to the Table of Contents, picking a topic you’re interested in, and skimming through what I have to say. I don’t trust prefaces much, and I recommend you don’t either; they rarely have the same style or voice as the rest of the book. But here goes anyway.

The book will be most valuable for people who fit themselves into one or more of the following categories:

  • Experienced team leaders and managers. This book is well suited for anyone playing a leadership role on any kind of project. The examples are from software development, but many concepts apply easily to other kinds of work. You might be the official team leader, or simply one of the more experienced people on the team. While some topics may be very familiar, the direct approach the book takes will help you clarify and refine your opinions. Even if you disagree with points I make, you will have a clear foundation to work against in refining your own point of view.

  • New team leaders and managers. If you look at the topics listed in the Table of Contents, you’ll find a solid overview of everything project leaders and managers actually do. Each chapter provides coverage of the common mistakes even experienced people make, with explanations as to why they happen and what tactics can be used to avoid them. This book provides you with a broader view of the new responsibilities you’ve taken on and the smartest ways to go about managing them. Because most chapters cover big topics, they often include annotated references to deeper sources.

  • Individual programmers and testers, or other contributors to projects. This book will improve your understanding of what you’re contributing to, and what approaches you can use to be effective in doing so. If you’ve ever wondered why projects change directions so often or seem to be poorly managed, this book will help you understand the causes and remedies. If nothing else, reading this book will help you increase the odds your work will make a difference (and that you will stay sane while doing it). If you are interested in eventually leading teams yourself, this book will help you explore what that will really be like and whether you are cut out for it.

  • Students of business management, product design, or software engineering. I use the word students in the broadest sense: if you have a personal interest in these topics or are formally studying them, this book should be appealing. Unlike textbook coverage of these topics, this book is heavily situation- and narrative-focused. The experiences and stories are real, and they are the basis for the lessons and tactics—not the other way around. I deliberately avoid drawing lines between different academic subjects because, in my experience, those lines neither help projects nor contribute to understanding reality (the universe is not divided in the same way universities tend to be). Instead, this book combines business theory, psychology, management tactics, design processes, and software engineering in whatever way necessary to offer advice on the outlined topics.

Assumptions I’ve made about you in writing this book

  • You are not stupid. I assume that if I’ve chosen the right chapters and written them well, you won’t need me to spend time slowly constructing elaborate frameworks of information. Instead, I will get to the point and spend time there. I assume you’re a peer—perhaps with more, less, or different experience—who has dropped by for some advice.

  • You are curious and pragmatic. I draw on examples from many disciplines, and I assume you’ll find value in lessons from outside of web and software development. This won’t get in the way, but pointers for curious minds will surface, sometimes just in footnotes. I assume you want to learn, are open to different ideas, and will recognize the value of well-considered opinions—even if you don’t agree with them.

  • You do not like jargon or big theories. I don’t think jargon and big theories help in learning and applying new information. I avoid them, except where they provide a path to useful information that will be helpful later on.

  • You don’t take yourself, software, or management too seriously. Software development and project management can be boring. While this book won’t be a comical romp (although a book by Mark Twain or David Sedaris on software engineering has potential), I won’t hesitate to make jokes at my expense (or someone else’s expense), or use examples that make points through comedic means.

How to use this book

If at any point you get bored, or find the examples distracting, skip ahead. I wrote this book with consideration for people who skim or have a specific problem they need advice on right away. The chapters stand up well on their own, particularly those on human nature (Chapter 8-Chapter 13 and Chapter 16). However, there is some benefit to reading it straight through; some later concepts build on earlier ones, and the book roughly follows the chronology of most projects. The first chapter is the broadest in the book and has a deeper tone than the rest. If you’re curious about why you should care about project management, or what other important people have said about it, then you should give it a shot. If you try it and hate it, I definitely recommend giving another chapter a try before abandoning ship.

All of the references and URLs listed in the book, as well as additional notes and commentary, are online at www.makingthingshappen.org. If you’re interested in discussion groups about the book, make sure to peek at the Appendix A in the back. It explains what groups exist and gives you advice on how to start your own.

And now, because you were smart and patient enough to read this entire introduction, I’ll assume you’re up to speed on the other mechanics of book reading (page numbers, footnotes, and all that) and just get out of your way.

How to contact us

Please address comments and questions concerning this book to the publisher:

O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
800-998-9938 (in the United States or Canada)
707-829-0515 (international or local)
707-829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at:

http://www.oreilly.com/catalog/9780596517717

To comment or ask technical questions about this book, send email to:

For more information about our books, conferences, Resource Centers, and the O’Reilly Network, see our web site at:

http://www.oreilly.com

Safari® Books Online

When you see a Safari® Books Online icon on the cover of your favorite technology book, that means the book is available online through the O’Reilly Network Safari Bookshelf.

Safari offers a solution that’s better than e-books. It’s a virtual library that lets you easily search thousands of top tech books, cut and paste code samples, download chapters, and find quick answers when you need the most accurate, current information. Try it for free at http://safari.oreilly.com.

Get Making Things Happen now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.