Bob Sutton: Keep it Simple to Reduce Cognitive Load

When you think about the problem of more, a lot of what you're doing is you're doing things that add cognitive load to people. You're adding more procedures, you're adding more process, you're adding more people. We'll talk about that more. And so there's a lot of rhetoric, and it's probably correct, that if you're doing that, you should follow A.G. Lafley's model and keep things Sesame Street simple. And there's a great set of studies by a guy named Bob Ashiv who now actually teaches at the Stanford Business School. He did it earlier in his career. I think it was at Duke. And he did a pretty simple experiment where basically he had two groups of people. In one group, typical undergraduates, you randomly assign them to conditions, memorized a 16-digit— or a 6— I'm getting this wrong— a 2-digit number, I'm sorry. And so just like 16, that's why I said that, like 16. And the other ones did a 7-digit number like 324-2257. And then what they did was they walked to like the end of a hall, so about where the guy in the back is standing, and they reported the number, but in between was cake and fruit. So the question is, what's the effect of the cognitive load? Because trying to remember that 7-digit number is much more difficult than remembering the 2-digit number. And the ones who did the 7-digit number ate 50% more cake. So what happens is when you give people cognitive load, that they sort of lose the will and concentration on what's important. So you got to be careful with cognitive load. And one of my favorite examples, another Stanford graduate. This is an attempt at Intuit— and no, you can't read this, you're not supposed to be able to read this— to bring essentially design thinking to Intuit. This is, they call it the D4D or Design for Delight movement. And again, at one of these early sort of kickoff things, what they did was, this was presented by Karen Hansen, who has a PhD in psychology from Stanford, and Scott Cook, who's the largest shareholder and co-founder of Intuit. And even the title was convoluted, Evoking Positive Emotions by going beyond customer expectations and ease and benefit delivery throughout the customer journey. So when we talked to Karen, and Karen let us talk about this in the book, she'll let me say this here, she says it to our classes, she comes in and gives lectures, she said people had two reactions to this. One, they couldn't understand what the hell we were talking about, and number two, they had this reaction that this too shall pass. And so we sort of had a problem, and Pretty quickly they went to this, and this is what they still use. This is their model. This is the only picture in the book. It's the light, really simple. And this is a case, I think, of sort of learning that making things as simple as possible, but no simpler, is the way that you do scaling. And here I hasten to add, and there are certain management theorists, and I have sort of a running polite squabble with Gary Hamel over this, who's a well-known management guru. He's always talking about tearing down the bureaucracy and tearing down the hierarchy. The fact is that as your organization or project grows and gets more complex, you do need more roles, you do need a little bit more hierarchy, you do need a little bit of process. It's unavoidable. And one guy who learned this is Mr. Larry Page. And it turned out when— this is about 2003 or so— when Google got up to about 400 people, he started longing for the good old days when they didn't have those annoying managers around. So he got rid of all the annoying managers because he's Larry Page, so he could get rid of them. And he had a situation where there was one executive who had more than 100 engineers reporting to him. This did not last very long. She's laughing. Well, he learned the hard way. And now, by the way, I was just at Google yesterday doing something with a guy named Parshad Setty who runs sort of people analytics, and now they're totally into essentially first-line supervisors. They're totally obsessed with them and think it's one of their keys to their success. So they have learned. So the lesson here is that as systems and projects get bigger, you've got to add more complexity. But you've got to find some way to deal with it that sort of acknowledges and incorporates human limits. So Ben Horowitz of Andreessen Horowitz has got a great line that what you do is you put in just enough structure or process so you're giving ground grudgingly. So in his perspective is you wait for things to crack a little bit but not break. Another expression, this is one of the heroes in the book, really interesting guy, Chris Fry, who before he was at Twitter, he's now head of engineering, but before he was at Twitter, he and another guy named Steve Green, they grew the development organization from 40 to 600 folks. He's got this great line that the purpose of hierarchy is to destroy bad bureaucracy. I think that's about right.