Managing a Team in the Early Days of AI

Sebastian Mallaby, author of The Infinity Machine, wrote that “Artificial Intelligence heralds a transformation more profound than anything since homo sapiens acquired the capacity for abstract thought some 70,000 years ago.” Adam Becker, author of More Everything Forever, says that AI is “a threat that doesn’t exist, and…a utopia that will never come.” I’m more in the Adam Becker than the Sebastian Mallaby camp, but I don’t know whether it will do more harm or more good in the world; I don’t know if it will prove transformative or over-hyped.

What I do know is this: if we are going to leverage AI to improve the efficiency of our businesses or, more interestingly, to invent new products and services that would have been impossible without AI, we need to treat our employees like assets we are investing in, not costs to be cut. We need to get on the same side of the table with our employees to figure out which agents to build and how to redesign our workflow so we are not paving the cowpaths when we automate with AI. If we create a human v machine contest, setting AI against our employees, we’ll fail at best, create AI that comes for us next at worst.

The fastest way to turn your employees into AI luddites is to announce you’re laying people off thanks to AI efficiencies. If you’ve done that, you’ve just created a massive incentive for them to sabotage your AI initiatives rather than coming up with creative ideas to use AI to work more efficiently and come up with new products and services that will ensure future success. If you want your team to be truly innovative, you’ve got to prove to them there’s something other than a pink slip in it for them.

Automation is not a new phenomenon. Borrowing lessons from past innovations may help us move forward wisely. In 2004, I took a job at Google, where I asked the team to figure out how to automate much of the customer support work for the AdSense product. I had never automated any business processes before. I borrowed inspiration from what I’d learned about how Toyota had gotten the best ideas out of front-line workers in order to become the world’s leading auto manufacturer. You couldn’t achieve “continuous improvement” unless you showed respect for everyone on the team.

Thucydides wrote that “an exact knowledge of the past” can serve “as an aid to the interpretation of the future, which in the course of human things must resemble if it does not reflect it.” In that spirit, I hope that some of what I learned back in 2004 may help you as you lead teams through the current round of disruptive technology.

#1 Listen to your employees, and make sure they are listening to each other.

Most of the great ideas about how AI can revolutionize an organization are not going to come from you if you’re the leader. They will come from your employees, especially if you’ve hired well. There’s no point in hiring great people and then refusing to listen to their ideas.

Listening is hard work. If you are the only one doing it, you’ll burn out. Leaders must create a culture of listening. It’s hard enough to get yourself to listen to your team members and let them know you are listening; getting them to listen to one another is even harder. My suggestion is that you develop a simple AI idea-generation system for employees to share ideas and voice complaints. They need to talk about new ideas for how AI can benefit the team. They also need to have a way to complain in a very public way and without fear of retribution when AI is going awry—which it inevitably will. Unlike people, AI has no feelings. Public criticism of it won’t trigger a fight-or-flight response. Criticizing AI publicly and in writing will help your team improve it—and doing so can be cathartic for the whole team. In a Radical Candor survey, we learned that 73% of employees have noticed AI errors, and more than half say AI quality concerns are only sometimes or rarely acted on. I suspect this is because they are not pointing out the mistakes. An AI luddite doesn’t have to destroy anything—they simply have to let the mistakes happen…

For such an AI ideas system to work, ensure that at least some of the issues raised are addressed quickly. You don’t want to make decisions about what ideas to implement and what ideas to back-burner simply based on a vote. So identify a team of people who will review the ideas; empower them to take action on some of them, and to assign action items to you if you’re the one who needs to take action. Also, ask the team to explain to submitters why some of the issues raised (whether they are new ways to use AI or AI trainwrecks) aren’t being addressed. This system should not merely empower anyone to point out what could be improved, but also enable the team to help fix problems or make changes. You don’t want to be the bottleneck—but that doesn’t mean you get to absent yourself from the work. You have to agree to let them ask you for some help. Define clear boundaries on how much time you can spend—and then make sure that time is highly impactful and visible.

Here’s a story from Radical Candor of how such an “ideas team” worked back in the 2000s.

“At Google, people constantly came to me with good ideas—more than I could handle, in fact—and it became overwhelming. So I organized an “ideas team” to consider them. For context, I circulated a 2008 article from Harvard Business Review (HBR) that explained how a culture that captures thousands of “small” innovations can create customer benefits that competitors cannot imitate. One big idea is pretty easy to copy, but thousands of tweaks are impossible to see from the outside, let alone imitate.

Next, I talked through some key principles that ought to guide the ideas team, first among them empowerment. The ideas team had to commit to listening to any idea that anyone brought to them, to explain clearly why they rejected the ideas they rejected, and to help people implement ideas that the ideas team deemed worthwhile. If somebody’s idea seemed especially promising, they could even negotiate with the person’s manager to give them some time off from their “day job” to work on implementing it.

They were encouraged to assign me up to three action items a week. After this innovation, instead of feeling stressed whenever I would hear a cool idea in a meeting or receive an inspired email, I could react enthusiastically and delegate it to the ideas team. Soon, lots of people were submitting ideas they had for improving the product, growing the business, and making our processes more efficient. We created an ideas tool (basically just a wiki) that allowed people to submit an idea, have it reviewed by the team, and voted up or down. That was a form of listening, and people whose ideas got voted up definitely felt heard by their colleagues. People whose ideas were not voted up knew that their ideas had been explicitly rejected: a much clearer signal than radio silence from overburdened management.

However, a vote is not always the best way to identify the best ideas, or to make sure people are listening to each other. Therefore, I asked the ideas team to read all the ideas and talk to all the people who submitted them—to listen. After that development, the team used a combination of votes and judgment to select the best ideas.

More importantly, the ideas team helped people get the selected ideas implemented. Occasionally, this was about getting time for people to work on them, or getting some input from me, but often all it took was just the validation and encouragement that came from listening and responding. “Yes, that’s a cool idea! Do it!”

#2 Celebrate successful automation not in terms of cost savings but in terms of new opportunities—for employees, customers, and the company.

Find ways to ensure your AI initiatives improve your employees' lives. Understand what matters to them, not just the cost savings that matter to Wall Street. Ironically, shareholder primacy is a fast track to AI failure.

Here is a story from Radical Candor about how that worked back in the 2000s

“Sarah Teng, a recent college graduate on the AdSense team, came up with the idea of using programmable keyboards to create shortcuts for phrases or paragraphs they used repeatedly when communicating with customers. It seemed like a good idea, so the ideas team asked me to approve the budget to buy programmable keypads. I did as they asked, and this simple idea increased the global team’s efficiency by 133 percent. This meant that everyone on the team had to spend far less time typing the same damn words over and over, and had more time to come up with other good ideas—a virtuous cycle. Bam!

When Sarah presented her project to the team, I didn’t just thank her; I also showed a graph of how this idea would improve our efficiency over time. But efficiency is not what people care most about, so I also stressed to the team how her innovation would make people’s jobs more fun and help them grow in their careers, since they’d get to spend less time doing grunt work and more time doing work they found interesting. I explained that Sarah would have an opportunity to share her idea with leaders from another, much larger team, to achieve an even greater impact. And I sent around an HBR article showing how competitive advantage tends to come not from one great idea but from the combination of hundreds of smaller ones.

Why did I add all that context? First, to demonstrate just how great the impact of her idea was. The use of programmable keypads by itself was hardly revolutionary, but when people saw the cumulative effect of that idea and others like it over time, Sarah’s innovation felt a lot bigger. Second, it inspired people with other automation ideas to be vocal about them. Third, and most importantly, it encouraged people to listen to each other’s ideas, to take them seriously, and to help one another implement them without waiting for management’s blessing. It’s so easy to lose “small” ideas in big organizations, and if you do, you kill incremental innovation.

Hundreds of really smart people had been working in Online Sales and Operations for years. It was hard for me to believe that nobody else had ever had the programmable keypad idea before, but if they had, management hadn’t listened. If you can build a culture where people listen to one another, they will start to fix things you as the boss never even knew were broken.

Most meaningful to me was that the team's morale soared. They felt they could automate away the annoying parts of their job so that they could focus on work that would take them where they wanted to go in their careers.”

#3 Telling people what to do doesn’t work. Caring about them does.

Obviously, the situation I found myself in working at Google in 2004 was fundamentally different from the situation that the leaders at Toyota were in when they came up with TPS in the 1970s. The situation you are in leading a team today is very different from the situation I experienced back in 2004. However, I was glad I’d learned how much better a collaborative system worked than command and control. There’s a lot of “founder mode” hype today. Don’t buy it. Telling people what to do doesn’t work. Never has, never will. Founder mode might work on AI agents you build. But it won’t work on people you hire.

Here’s another story from Google 2004 that I told in Radical Candor about that. “At first blush, it seems like achieving results is more a matter of challenging directly than caring personally. But the ultimate goal is to achieve collaboratively what you could never achieve individually, and to do that, you need to care about the people you’re working with.

Steve Squyres, who led the Mars Exploration Rover Mission, described perfectly the thrill of collaboration: “Over four thousand people have worked on this mission. There’s no one person who can really get their arms around the whole thing and say, ‘I understand everything about this vehicle.’ It burst the bounds of our brains.” I was sitting next to Larry Page when I watched the documentary, and he turned to me and said, “Wow, that really makes you feel like you can achieve something, doesn’t it?”

On the one hand, I agreed wholeheartedly. On the other hand, it seemed nuts that the guy who cofounded Google needed to watch a documentary to make him feel like he could achieve something.

If you want your team to achieve something bigger than you could achieve alone, if you want to “burst the bounds of your brain,” you have to care about the people you are working with. You’ll get more done if you take the time to incorporate their thinking into yours, and yours into theirs. Don’t let your focus on results get in the way of caring about the people you work with.

#4 AI is not sentient. Employees are.

The weirdest AI hand-wringers worry about what we will do if the bots they are creating become sentient. Those same hand-wringers spend 0 time thinking about the impact of AI on their employees, who are indubitably sentient now. The question behind the question these people are asking is, "What if it turns out that I am inferior to my AI, and it starts to treat me the way that I've treated my employees, whom I consider to be inferior to me?" To which my answer is: 1) you are not superior to your employees and 2) treat everyone around you with respect.

We must build AI agents and systems that serve human needs, not ones that spy on them or default to distrust. If we build a Taylorism’s arrogance into the systems we build in a bid to exert absolute control over employees, we are greatly increasing the risk inherent in this technology. If we instead build the kind of respect for all the humans working in our organizations espoused by Toyota, we are much more likely to ensure that AI makes life better, not worse.

Too often, it feels like humans are serving the systems that govern our lives. Instead, we need to build systems that optimize for the human experience, systems that save people time—and then pay them more per hour so that they can work fewer hours. Systems that allow people to quit doing the aspect of their jobs they dislike most—so that they can spend more time on the work that has meaning for them. Too often systems are not optimized for efficiency—they just pass the costs on to someone else. And when we optimize for efficiency, we need to think about the why behind what we are doing. Do we want to increase human well-being, or simply raise the stock price? If we optimize for “number go up” blindly, we will fall prey to the measurement problem: we will reward what we can measure at the expense of all we value.