One of the hardest parts of management is letting go. Not doing the work yourself. You have to temper your fear that becoming more hands-off will cause the product to suffer or the project to fail. You have to trust your team—give them breathing room to be creative and opportunities to shine.

But you can’t overdo it—you can’t create so much space that you lose track of what’s going on or are surprised by what the product becomes. You can’t let it slide into mediocrity because you’re worried about seeming overbearing. Even if your hands aren’t on the product, they should still be on the wheel.

Examining the product in great detail and caring deeply about the quality of what your team is producing is not micromanagement. That’s exactly what you should be doing. I remember Steve Jobs bringing out a jeweler’s loupe and looking at individual pixels on a screen to make sure the user interface graphics were properly drawn. He showed the same level of attention to every piece of hardware, every word on the packaging. That’s how we learned the level of detail that was expected at Apple. And that’s what we started to expect of ourselves.

As a manager, you should be focused on making sure the team is producing the best possible product. The outcome is your business. How the team reaches that outcome is the team’s business. When you get deep into the team’s process of doing work rather than the actual work that results from it, that’s when you dive headfirst into micromanagement. (Of course sometimes it turns out that the process is flawed and leads to bad outcomes. In that case, the manager should feel free to dive in and revise the process. That’s the manager’s job, too.)

One reason we managed to put together an outstanding team to create the iPod was that our team could get relatively outsized stock and bonus plans that they couldn’t get anywhere else at Apple. The other important reason was that we had Steve Jobs fully behind us. Those two things allowed us to recruit amazing people—even though we couldn’t tell them what they’d be working on before they signed on—and survive the internal antibodies. Steve

gave our tiny team an unfair advantage—gave us air cover and dropped bombs if anyone messed with us. There were times when the internal antibodies at Apple tried to expel us from the organization—we’d constantly hear “We have other priorities, we’ll help you if we have time.” Or “Why are we doing this project—it’s not core to our business.” But as long as our team was making reasonable (or unreasonable but important) requests, the teams who were stalling us would get a call from Steve. “If they’re asking for something, then give it to them for Christ’s sake! This is very important for the company!

The Google teams with whom we’d planned to integrate and codevelop technologies and products were reluctant to work with us. They kept asking their execs for more details to figure out if they really had to help us at the expense of their own projects. Why? Why? Why do we have to help a team that isn’t Google? Over the subsequent months, every time we had to clarify yet again for customers that Nest was separate from Google, our internal reputation took another hit.

I should have remembered what it was like at Apple during the very first months when we started building the iPod. It just didn’t occur to me—Nest was so much bigger and more established than my tiny iPod team, I thought this was a completely different situation. But it was exactly the same. Back then Apple’s executive antibodies saw us coming to take their time and draw away their resources, so they tried to block our way and ignore our requests.

That’s when Steve Jobs gave us air cover, dropped bombs on the teams who were slowing us down, forced the issue, yelled sometimes to make sure we got what we needed. Steve Jobs fighting for us was ultimately what allowed us to succeed.

However, what was also clear was that IBM was paralyzed, unable to act on any predictions, and there were no easy solutions to its problems. The IBM organization, so full of brilliant, insightful people, would have loved to receive a bold recipe for success—the more sophisticated, the more complicated the recipe, the better everyone would have liked it.

It wasn’t going to work that way. The real issue was going out and making things happen every day in the marketplace.

Opening up our stack (and our minds) to others had many positive effects on IBM. It cut our losses and improved our integrated offerings to customers. And it freed up resources to invest in the future. Huge sums of money and huge quantities of brainpower have been redeployed from wall-banging futility to exciting new work in areas such as storage systems, self-directing computers, bioinformatics, and nanotechnology.