I TRIED HARD TO come up with a way to sugarcoat this but I couldn’t, so here’s the bombshell: shipping great software is damn hard and crazy stressful. It’s also incredibly rewarding. The energy you spend is worth it. But the stresses placed on those called upon to ship can be extreme. Sometimes you’ll be asked to balance multiple competing priorities without guidance. You may be asked to do the job of three people in half the time it would take one. And throughout the project you’ll probably have to deal with feature requests, changing corporate priorities, politics, and general unfairness. But wait—there’s more! There’s hope!
There are tricks that can help you cope with these shipping life challenges. I’ve spent many years working with colleagues who were all trying to ship, and there’s a small kernel of battle-hardened advice that I’ve gathered and held on to. I think it helps, and it’s broken down into these five categories:
How to balance shipping, quality and impact, and your team, so you deliver great software.
How to handle randomization, so you can continue to ship a great product in a timely way. Randomization is what happens when your management throws you a curveball, or your team wanders off into the weeds. Randomization is one of those words that everyone at Google and Amazon understands because it’s the opposite of helping a team stay focused on shipping.
How to manage your energy deliberately, so you can do the job of three people.
How and when to escalate, so the right work gets done by the right people.
How to eat the s#!@ sandwich, because sometimes, you’re just gonna have to.
Let’s pretend you’re the CEO for a moment. (If you are the CEO, please buy copies of this book for everyone at your company.) If your team lead happily announces to the world that your new product is ready, and it’s actually a steaming pile, you wouldn’t consider that team or that team lead successful. Neither would I. That lead is fired.
If your lead, through charisma or knowledge of dark secrets, manages to ship something pretty good quickly but leaves behind a burned-out, disheartened team, you would also consider that a failure and sack that person. If you don’t, the board is going to fire you.
If your lead, in a fit of aggressive cost cutting and schedule pressure, reduces the feature so much that you have no bugs and the team can ship early, but users don’t care about the product, the lead is fired.
A successful team lead must balance team, quality and impact, and a desire to always be shipping. As you work through the different phases of your shipping process and the details in this book, remember this balance (shown in Figure 12-1). Maintain it, and you will remain employed. Understanding that you can’t have perfection in all dimensions, but that you can have balance, will help you manage your shipping life. You also now have tools you can employ to see if you are out of balance, like the vibe in your weekly team meeting, the High School Embarrassment Test, and your product requirements document: are you still solving a big problem that lots of people share?
Since you’re not the boss, and life isn’t fair, your product will probably suffer from a constant stream of well-intentioned but nonetheless disruptive suggestions. Unfortunately, as your product becomes more important and your deadline grows closer, the volume of suggestions will increase, because your software will get more visibility through the dogfood process. You can’t eliminate these suggestions, but you can stop them from distracting or “randomizing” the team. Randomization feels like you were on stage 2 when someone rolled an 18-sided die and said, “Go do stage 13 instead.”
It’s generally not your fault when this happens. There are many sources of randomization. Feature requests are common. Corporate priorities may shift. And you may even be forced to accept some substantial infrastructure change. You have to take this randomization in stride and try to continue with business as usual.
To deal with feature requests, create a simple, shared document into which you’ll aggregate them. Make this document public to everyone because transparency will reduce fear-based concerns and the volume of incoming questions. When someone suggests a new feature, say, “Thank you sooooo much! I added your idea to our feature requests; here is a link.” This technique works like the technique you apply in meetings, where you write everything your team says on the whiteboard; writing down the feedback is an explicit form of acknowledgment (but not commitment).
When randomizing suggestions come from management or investors, you can help defuse the suggestions with the Version 1 test. Ask, “Would you block the Version 1 launch on it?” In some cases, you’ll hear an unequivocal “yes,” and you’ll be scared right to the marrow of your bones. Don’t freak out yet—there’s still hope.
When the founder or the board says, “Yes, it must be in V1,” your next step is to pull your development lead aside to share what’s going on. Ask the lead to figure out what the engineering impact of the change will be. You want to assess the cost in terms of engineering weeks, systems design, capacity, and any other functions on which you depend, like legal. If the estimate is small, don’t worry about it and add the feature. The exception to this rule is when you’re very close to launch and the “just say no” protocol is in effect (see Chapter 7). If the cost estimate generated by your development lead is large, go back to your senior management with the estimate and ask, “Are you willing to block the launch for six weeks and buy 100 more computers for this feature, or can we add it to the immediately post-launch list?” At this point, you can have a real, rational conversation about cost and benefit. There is no point in pushing back on a requirement until you have an estimate of costs, unless the requirement is evil.
If the suggestion is really wacky, and also must be in V1, sometimes the best thing to do is not fight the suggestion. If it’s a terrible idea, your trusted testers will tell you, and your senior management will have a very hard time arguing with vocal customers and user data. In situations like these, you can work with your team to invest a minimum of engineering effort, deploy the feature as quickly as possible to your trusted testers, and then wait and see. You might be wrong, but if you’re not, bring the data back to your management and go from there.
Listening well in your review meetings can help you avoid some randomization. Remember, if the Big Boss says you should do something, you probably need to do it. If you fail to either tackle this head-on with that manager or fail to deliver on expectations, you’ll be randomized. It is a mistake to assume that your bosses will forget the requirement they communicated; if you’ve taken verbatim notes in your meetings, you’ll know precisely what expectations are and you can manage to them. Doing so will substantially decrease your odds of being randomized.
There are, of course, sources of randomization you can’t control, like changing corporate priorities. Diving deep into the tricks and tips for dealing with corporate politics is beyond the scope of this book. It seems to me that some people are innately good at dealing with politics, and others don’t have a political bone in their body. I fall into the latter group, so I can only offer four basic coping strategies, in sequential order, for dealing with shifting corporate priorities. Remember, your goal is to ship, so you want the engineering team to carry on as if nothing has changed:
Find out if the priority change is real. Sometimes leaders state that priorities are shifting, but the company has no intention of following through or lacks the ability to do so. The people who will know if the changes are real are generally only one level removed from the people who initiated the change. Talk to these one-level-removed individuals and get their honest assessment, one-on-one, and not in writing. You may hear something different than the party line, and find out that the senior leadership is trying to appease some external group. You may even hear that the decision isn’t final yet. If this is the case, you can carry on as usual, and you’re done coping. For now.
Recast your product to align. In some cases, you can easily recast your product so it aligns with the new priorities without actually changing your engineering work. Rework your short presentation and see if acknowledging that you understand the new world order gives you and your team room to breathe. If it does, you can carry on as usual.
Change as little as possible. If you want to carry on as usual and ship, and you must take a change, you need to make the smallest change you can possibly make. The bigger the change you take, the greater the randomization you will experience and the greater the risk to your launch. Work with your engineering team to find a low-cost quick win. Generally doing something small and quick proves that your team is paying attention and buys you enough time to ship. In fact, if you can be the first to show reasonable progress conforming to the new priorities, you may buy your team disproportionate leeway to proceed at your own pace, since you’ve made it clear that you will get the job done. Make the small change, and you’re back to business as usual.
Ask for an exception. Sometimes asking for an exception can be the best way to move forward. Getting a wholesale exception is particularly important if the only way to move forward involves major ship-stopping changes. A variant of asking for an exception is asking to respond to the new corporate priorities in Version 2. Explain the cost of responding to the new priorities in the same way you would when the Big Boss asks for a change. If you get an exception and can push the changes into V2, you’re done. Once again, carry on as usual.
Suck it up. If you try all of these techniques and make no headway, I’m sorry. You’re in a tough situation, and this is one of those s#!@ sandwich–eating times, which we will cover soon. Eat the sandwich and write a new product requirements document. Remember to reset your milestones—it would be deeply unfair to your team to forget to do so.
All of these coping strategies apply to big infrastructure changes, too. There’s one additional rule of thumb for working with infrastructure on which you depend: you want to be in the middle of the train. Infrastructure projects steam into town like a big, screeching train. It takes a long time to start these kinds of projects, and they’re loud, pushy, and obnoxious for the most part. If you’re right at the front of the train, an early adopter of the infrastructure, you’re going to run into bugs, cows, and the occasional Karmann Ghia—none of which is fun. You don’t want to be an early adopter of a major infrastructure project.
On the flipside, if you’re the caboose you’ll likely get whiplashed. Your management will ask, “Why aren’t you done with porting to X yet?” Your systems will likely start to break in funny ways. Support for your old infrastructure will become obsolete, and you’ll generally be in an uncomfortable place. You don’t want to be at the tail end of the train.
You want to be in the middle of the train—right near the club car where they keep the cocktails and pretzels. Find two to three other teams whose progress you can monitor. When you see a team go through the process of switching to the new infrastructure relatively painlessly, it is time to start switching to the new infrastructure. The documentation for the new infrastructure is probably decent at this point, but you can also ask that successful team to guide you through the switch. The guidance you get from users is almost always better than the guidance you’ll get from the infrastructure developers.
One Amazon engineering manager I know once spent only 20 minutes building an important presentation for an executive review. This was unlike him, but he’d been fighting production fires all week. I turned in my chair and said, “Really, that’s it?” And he shrugged. “Time to go,” he said.
A half-hour later, he came back from the meeting, sat down, and said, “Well, I spent the right amount of time on that deck.” This was a seminal moment in my career because it taught me that I must learn how much time was the right amount of time to spend on each task. In this case, he was pretty sure that the execs had already made up their minds, so why bother spending a lot of time on a presentation when he’d only get to the first slide? There are many things you need to do if you’re going to ship, most of which are described in detail in this book, but you won’t be able to do all of them.
Kim Rachmeler, the former VP of Worldwide Discovery at Amazon, once said to me, “When I hired the first program manager into Amazon, I sat her next to me and every day I would get up from my desk and say, ‘That’s another day where I didn’t get everything done,’ because I wanted her to understand that the work of a program manager is never done—what’s important is doing what had to be done today.”
Since you can’t do everything that the team needs, you need to do the right stuff, and be OK with not getting everything done. Peter Drucker echoes this sentiment in The Effective Executive. He says that the things you should do first are the things that you, and only you, can do. Working in this way will help you maximize your effectiveness and prevent you from becoming a blocker.
One small example of how this works well at Google is that there’s a culture of very fast expense report approvals. Good managers understand that they are the critical blocker on that one task, so they deal with it immediately.
I used to worry more about my energy. So I asked Eric Schmidt how we planned to help product managers who were burning the candle at both ends stay at the company. Eric said, “I think many product managers are initially inefficient in their time management.” I was chagrined—I thought I was doing a pretty good job, and I was definitely feeling stretched pretty thin! In hindsight, when I look at the volume of work that Eric completed, and contrast that with how I’ve learned to prioritize doing the things that only I can do first, spend the right amount of time on any given task, and be OK with not getting everything done, I think he was right.
If you’re having a tough time learning to be efficient with your time and your energy, or recognize that this is a skill you are completely missing, consider learning from Tony Schwartz’s Energy Project.[8] Schwartz wrote a great Harvard Business Review article entitled “Managing Your Energy, Not Your Time” and subsequently developed a book and a whole business around the notion of optimizing your personal energy.[9] He’s a major advocate of understanding where you spend energy, how to optimize where you spend it, and how to establish greater reserves of it. Many effective executives are beginning to adopt his approach because it really works. It’s a bit crazy, what with some CEOs keeping pillows in their offices, but it seems effective.
A final trick you can employ to help manage your energy is scheduling time to work. Because you’re trying to ship, most, if not all, of your time is consumed with meetings. This means that you have little time to write a product requirements document, review the user experience, and talk with your engineering team about your systems design. And for some strange and wonderful reason, people who would otherwise book your calendar solid until late at night are unlikely to book over your “work time.” Tony Schwartz would suggest that you schedule the first hour and a half in the morning to make progress against your hardest task. An hour and a half is a nice amount of time to work intently before taking a break, and the morning is when most of us have our best energy. Generally, your hardest task is also your least reactive and the task you’re most likely to postpone, so if you’re a procrastinator, using this scheduled time is a nice way of pushing through. It’s worth trying, right?
We’ve established that you’re not the boss—but somebody, somewhere, is. That bossypants can be a valuable asset! Knowing when to escalate is a key skill, just like “over” is a key part of “over, under, and through,” which you should have learned in kindergarten.
You probably want to escalate when any of the following conditions is met:
You’re trying to defend an otherwise silly executive mandate. You shouldn’t have to stand up for bad ideas. You might have to in the long run, but do your best to make the bosses defend their bad ideas.
You honestly don’t understand why you should do something. In situations like this, it’s best to get an explanation one-on-one because the Big Boss will likely be more transparent. If you ask for an explanation over email, don’t cc the team.
It’s not your responsibility to solve the problem. One of the classic times when you need to escalate is when your engineering team is making a decision you think has dubious technical merit. Most leaders with an engineering background have good enough instincts that they know when the train is going off the rails. Rather than trying to go head-to-head with your tech lead, let the engineering manager with the legitimate authority, and the responsibility, deal with the engineering team. In addition, taking the engineering team’s side in this manager-staff crisis can help you build equity with the team.
I think it’s important to point out that I’m not advocating that you eschew all responsibility for things that aren’t purely in your job function. If there’s something you can fix, and your team is willing to have you fix it, fix it! Be proactive and assertive in your fixes, and don’t let your title or job description limit you. But when you get into a situation where there’s a problem that is someone else’s responsibility to fix—and that person would be unhappy with you fixing it instead—escalate.
You’re dealing with senior managers who don’t want to listen. They may not be listening to you because you don’t rank high enough or, more likely, because they don’t know you. However, your management or investors probably have an existing relationship with the troublesome senior managers. They’re in meetings (read: golf) together frequently and have developed trust. Leveraging the trust and understanding that your management has built rapport with other executives is an efficient way to lead.
There’s no way around it: you are going to need to eat a certain number of s#!@ sandwiches as you try to ship your product. Some of these sandwiches come from partners. Some come from your bosses or investors. Some come from whiny engineers or competition. You need to accept right now that there are times when your life as a team lead is going to really suck.
I once worked on a project at Amazon and had a crisis in which my senior management freaked out. It was painful. Customers were sending email to Jeff, and you never hear about the thank-you notes they send, only the rants.
The thing that helped me survive this near-career-apocalypse was what the guy sitting next to me said as I waited for the VP to come down the elevator and deliver my special sandwich. My colleague said, “This is going to suck for a while, but then it’ll be over.” That stuck with me, and I’ve said it to others many times—probably more times than I care to remember.
You can think of these sandwiches like high school. Surviving them is the point. Your goal, when offered a sandwich, is to keep smiling, eat the sandwich, and move on. Matt Glotzbach, a product management director at Google and one of the coolest cucumbers in the patch, once said to me, “The time to keep your cool is when everyone else is losing theirs.” So eat the sandwich, keep smiling, and remember what it felt like so that you’re less inclined to prepare those sandwiches and hand them to your team.
There is one small caveat in my deli advice. In some bad environments, you may find that you’re eating these sandwiches all day, every day. This is a bad sign. William Gibson, author of the cyberpunk pioneering book Neuromancer (Ace) and understander of tech culture extraordinaire, once said, “Before you diagnose yourself with depression or low self-esteem, first make sure that you are not, in fact, just surrounding yourself with assholes.” Sometimes the volume and quality of the sandwiches you are required to eat is a direct product of the assholes you’re working with. When this is the case, it’s time to go ship something else, somewhere else.