Your team doesn’t work for you. You work for them.

When I worked at Trilogy, one of my fellow managers seemed to have a brutal case of absenteeism. He was never at his desk. Even more concerning, when I did see him he seemed to be doing random things — talking to one person, going for coffee with another, or maybe just standing around and looking at people. Yet his teams performed excellently. I wondered if luck bestowed him with a pack of A-players, enabling him get by doing nothing as a manager. I thought he was hopeless, but then I discovered something powerful: he spent all his time helping people. Those ostensibly random activities were his way of unblocking his team and paving their way to success. I changed my own behaviour. I started to work for my team and carried that practice throughout my career. Whether I manage five (as I did at first) or 300 (as I did at Xtreme Labs), I help people do their jobs. I volunteer for the unpopular jobs. When my people are blocked, I work as hard as I can to unblock them. To an outsider, it might look like I’m doing nothing. But the value accruing to the company is tremendous. There are four main reasons: Your people need a threshold level of responsibility to get creative Your people need missions and authority to reach peak productivity You are in the best position to unblock people This is how your people learn — and how you learn 1) Your people need a threshold level of responsibility to get creative “We have to continually be jumping off cliffs and developing our wings on the way down.” — Kurt Vonnegut In order for someone to do her best work, she needs to feel and understand the problem. She’ll never grow wings if she’s never forced to fly. The conflict and struggle of fixing one’s own problems is the key to creativity. This is why people should work for themselves and ask for help from managers when they need it. This is the opposite of what most people think (people work for managers and ask for help from below when they need it). As a manager, your job is to unblock people by getting your hands dirty, showing them who to ask for help, or asking for help a level up — from your own manager. This way, the company benefits by having far more people working on creative solutions to problems. Command-and-control works for organizations like the army, but not for knowledge workers. You need each of your people to spread their wings. 2) Your people need missions and authority to reach peak productivity “You wanna fly, you got to give up the shit that weighs you down.” — Toni Morrison Your people have to shed their chains to do good work. A typical manager might give her subordinate a task and micromanage until it . I prefer to ask my people to build something that . looks like they want solves the pain For example, I asked one of our Helpful product designers, Novia, to help solve a pain: some users want to use the app but they won’t use their phones. The mission was to build web functionality for everything in our app. Her output looked nothing like I expected, but it was fantastic. Roger Martin calls this the “Choice Cascade” — choices cascade down the org chart and fall to the people that actually do the work. Missions alone, however, are not enough. Your people need to have the authority to accomplish their missions. Even if you think the output should look different, they need to be able to say “no.” Saying “no” is a skill, and like all other skills, it has to be nurtured. I encourage and reward people who defend their points of view. For example, I gave Shawn, another Helpful product designer, a specific feature suggestions. When I didn’t see it in the app, I repeated it five more times. Eventually, I asked, “Why isn’t that in the product?” He replied, “I know you’ve told me many times, but I don’t agree with you.” He has the final say. I am just one voice. 3) You are in the best position to unblock people “In most cases you will have more context than I will about a [technical] decision, but come to me when you’re blocked and I’ll unblock you. That’s my job.” As a manager, you understand who knows what, who’s done what, and who owns what. By virtue of that alone, you know how to get help for your people. At Xtreme, I spent a lot of my time learning about people. This way, I could help people quickly. My team called me “air traffic control.” My task as air traffic control was to unblock people (making sure there were no crashes), but not micromanaging (how to fly the plane). 4) This is how your people learn — and how you learn “You don’t learn to walk by following rules. You learn by doing, and by falling over.” — Richard Branson As a manager, your job is not to prevent people from making mistakes. Don’t worry about mistakes. In reality, there are extremely few catastrophic mistakes that people can make. Your job is to set a tone that making mistakes is okay — as long as people learn from them. Make your own mistakes. Bring a mindset of learning to everything. Explicitly call it out: “I thought that X was right, but turns out I was wrong and Y is better.” I learned that you have to be explicitly and emphatically advertise your own mistakes. At Pivotal, I once called someone by the wrong name and a colleague said, “Woah, you make mistakes!” I was floored, ”Do you think I never make mistakes?” My mistake was to not showcase my mistakes. This helps people get rid of their fear — again unleashing autonomy and creativity. Two Cautions 1. You can very sparingly say “no” Success for a manager sometimes requires saying “no.” Some of your creative people will sometimes create output that just won’t jive (with other departments, with the company vision, or with other team members). Your duty to the company may require you to put a bullet in such projects. Do it quickly and without remorse. As a manager, you have to be decisive — your team will appreciate it. Just use your bullets wisely — saying “no” should never become a habit. For example, I will not budge in my stance pair programming. I believe so strongly in the benefits of pairing that I simply will not allow engineers to code alone. I often say that, if you don’t like pair programming, you don’t have to work at Helpful. 2. Don’t create a leaning monolith When you have large numbers of people all working to advance their mission, you increase the risk of colossal failure. They might build a huge monolith only to have it fail in an unexpected way. To mitigate this risk, be agile (ship, test, iterate). At Helpful, everyone (not just our engineers) demos every Friday. This means nobody can work on something for more than a few days without another person seeing their output. Friday demos also force people to think in terms of short-term output. It’s okay to demo something that’s broken, as long as it’s moving in the right direction each week. Be hard on the process, not the people. Another way to avoid creating a monolith is to time box activities. For example, one of our Helpers wanted to create a new analytics report. I know that analytics can take a lot of time, so I said, “Sure, but don’t spend more than one day on it.” This forced him to hone in on the few most valuable metrics, create a lightweight report, and move on. Your org chart is upside-down. Flip it. Conclusion: