Introduction.

Shipping IS greatness.

Designing, building and launching the right software is referred to as “Shipping” in the software industry.  “Shipping” is a magical word that describes one of the few truly new crafts of our century.  It’s newer than management because managers have been managing people for a long time.  Business Execs have been waving their hands at strategy for just as long, if you count stockpiling mammoth bones as inventory control.  And marketers have been trying to sell another sprocket or cog since before sprockets and cogs existed.  But shipping?  Shipping software didn’t exist when you and I were born.  Heck, it barely existed when your kids were born and there are no classes you can take in school that will teach you how to do it.

Shipping is new, but it’s also incredibly meaningful because it solves many problems.  Shipping solves money problems, because your investors are always looking for results before they give you more money.  It solves customer problems because the features and fixes your customers need are tied up in your ability to ship.  It solves team problems because nothing is better for morale than making progress.  If fame, fortune, and the pursuit of happiness is the question, shipping is the answer.

If you can ship you can make nearly any software business successful, and you can compete with businesses that have deeper pockets because you can get to market faster.  But if you screw it up - by missing your date, by launching a product nobody cares about, or by building a beautiful product that nobody hears about - your team will be grumpy, customers will write to the Big Boss, and best case, you don’t get promoted.  Worst case, the next project on which you and your team work will involve resume polishing.  Or maybe polishing cars.

So if you can ship you’ll be personally and professionally successful.  But it’s damn hard for teams to ship, which is where you come in.

This book is your shortcut to a degree in shipping.  Think about it like this: McKinsey and Company, the world-famous hyper-expensive fancy-pants management consulting company hires a new crop of science PhD’s each year and puts them in a 2 week “mini MBA” program.  They then expect these PhD’s to do pretty much what the MBAs do, even though the PhDs have 2 weeks of training to the MBAs 2 years.  The goal of this book is to provide you with the same simplified, no-BS approach to doing your job – or understanding your team lead’s job.

This book exists because I needed it when I started trying to ship software, and I see product managers, test leads, engineering managers, and team leads of all types who are struggling, just as I did.   I see them going through the same special torture that I underwent when I entered this industry – but I had the good fortune to have great teachers attendant at my hazing: Dartmouth, Amazon, Google, and my own mistaken ventures.

My first teacher was my own company – I was arrogant enough think that since I could write software I could do everything else required to ship it.  You know, define the minimum viable product, manage the project, iterate, release, market, and so on.  I learned many valuable lessons, hubris among them.  I then joined another startup as the Chief Technology Officer, and spent years trying to make it big.  I learned (mostly) different lessons there, but repeated the class in hubris. Abashed, I went to Dartmouth, and studied at the Thayer School of Engineering and the Tuck School of Business, earning a Master of Engineering Management degree.  I spent those two years figuring out what McKinsey teaches in two weeks.

I left Dartmouth and joined Amazon, where I was a Technical Product Program Manager and a Two Pizza Team Leader (a.k.a Engineering Manager).  On projects like customer reviews, identity, and fraud-fighting infrastructure, I saw how Jeff Bezos and his lieutenants worked and learned to mimic how some of the best in the business did the job.

I eventually went to Google and as a Senior Product Manager I spent over five years focusing on scalability, business strategy, and the interpersonal dynamics inherent in software teams.  I grew Google Pack, shipped the Google Update service used in dozens of products, and helped build the Google Apps program through mobile sync services, connectors for Microsoft Outlook, and data import tools.  I launched Google’s innovative multi-way video products, now featured as Google Hangouts.  I even worked on Maps for a while.  I saw the company grow and change, but more important, I saw successes and failures and both discovered and practiced the best ways to ship software.

If you don’t think Amazon and Google know what they’re doing, and that the best engineering and product leaders at these companies have something to teach, stop reading now.  Remember, this business is new, so the techniques, processes, and tricks you need to ship software weren’t developed until after Windows became dominant.  Microsoft’s old approach to shipping software was rendered obsolete by the development of rapid application development frameworks, usability studies, and new process frameworks like scrum.  As a result, most of us are making this shit up as we go along, and the guidance you can glean from the relatively few executives that are part of the Amazon and Google success is critical.    

The lessons I’ve learned and distilled in this book cover the entire software life cycle because you will face challenges in product, program, project, and engineering management.  Shipping is not just project management and convincing engineers to work faster.  If your job is shipping software you must have an extremely broad skill set that ranges from deeply technical to highly creative, and along the way you must provide cogent business insight.  You’ll do everything from managing people to writing test cases to making mocks in Photoshop.  Most important, you’ll do all of these things.  If you’re up for a challenge that’s second to none, this is your gig.

To put this in perspective, shipping is a painful, confusing, and difficult job that’s generally only rewarding if you’re really good at it.  The job is like playing golf on gravel fairways – if you suck at it, you’ll spend all day grinding your clubs to bits and wandering around in the pounding sun trying to find your ball, which will be hopelessly unidentifiable amidst the rocks.  But if you’re a great golfer, you’ll hit those sweet shots that put you onto the soft green and when you look around, surrounded by sweating, confused duffers, you’ll know what it’s about.  It’s glorious.

This book covers two major things that will help you be great at shipping.   In Part One describes a process for shipping that many of the best teams from Amazon and Google use.  I work from the beginning – a customer problem - through the details of user experience design, project management, and testing to the end-result of launching. Part Two contains techniques, best practices, and skills that a team lead who’s been asked to ship software needs.  While Part 1 is arranged in the order in which you’ll follow the process, you can read Part 2 in whatever order you like, and refer to it when you have a particular challenge.

The tools and tips herein are blunt and directional – it’s up to you to sharpen them and make them your own, just as Wyatt Earp would remove the safety and polish the hammer cam of his Colt so he could shoot faster. If you’re looking for an in-depth analysis of software strategy, this book is not for you.  But if you’re looking for a tried-and-true rubric that will get you through a 3-day strategy offsite and align your team for success, among other things, read on.

Comments