Managing Creative Teams with Facebook's James Everingham | Greymatter

This episode of Graymatter is in partnership with sfelc, a curated community of engineering leaders working to evolve the way leadership is implemented in the tech industry. At the annual SFELC Summit, Facebook's head of engineering of Blockchain, James Everingham shares leadership advice for new managers and the surprisingly similar factors between quantum mechanics and and today's management styles. Thanks for the warm intro and thanks everyone for having me here today to talk. Today I'm going to talk about management and quantum mechanics. But before I talk about what the heck these two things could possibly have in common, I wanted to set the stage for how I came up with this crazy concept in the first place. So let's go back a little bit. I really wanted to be a physicist before I was a computer scientist. But it turns out like as a prerequisite to being a physicist, you have to kind of be good at physics. And unfortunately I wasn't very good at physics, but luckily I was pretty good at computers and that was my calling. And so actually, 37 years ago, I don't know how time has gone by so much, I started working on the east coast for Penn State University as a software engineer. This is kind of what my days looked like working at Penn State. I'd come in with a button down collar and a tie, dress slacks at 8:00am, not, not 8:05 8:00am and I'd sit down and my boss would have my work all put out for me, usually APIs. And I'd sit down and I'd just start implementing the stuff that I needed to do. I was part of the assembly line. It wasn't bad. I loved building stuff and I got to learn a bunch of new things. But from what I saw of management, I didn't have much interest in it. Managers sort of seemed to do this weird people stuff and were being very prescriptive with me and would kind of reprimand me when I'd come in late. And I didn't really like telling people what to do and I certainly didn't like yelling at people for coming in late to work. But then a little bit later on, in 1992, I was recruited into Borland. How many people here remember Borland? Wow. Okay, that's great. And luckily I moved to California from Pennsylvania. This was life changing for me. Borland had some of the smartest people in the industry. In fact, a lot of the companies in the Valley today can be traced back to roots at Borland. It was my first experience working with a team that wasn't being treated Like a bunch of factory workers. This is the team I worked on up on the screen. It was the Borland C language team, and I was a total Borland fanboy. I learned on the tools and I couldn't believe I was getting to work on these. These people were brilliant. They were eccentric, they were creative, and they all seemed a little wacky, and I felt like I was a little wacky. So I thought I had found my people. They weren't coming to work in suits. Some of them weren't even wearing shoes. I didn't know what was going on. And one of the best parts was that I couldn't even tell who was managing the product. Software was just sort of happening. At first, I thought from the way my new manager was working, I'm like, well, my new manager is kind of lazy. He's not telling me what to do. He doesn't seem to even care when I come in. He's asking me to solve problems instead. For example, the very first thing that he asked me to come and do was he's like, hey, you know, it's really annoying when the integrated development environment crashes and developers lose all their work. Why don't you go try to make it so that can never happen? And I'd go off and try to figure that out. The bosses here at Borland, they knew what they wanted. They just avoided being prescriptive about how to get there. And as a team, we were all super invested in the product. I remember thinking how cool it was that when we were coming up with a new version of Borderland C, we were all working hard to get the compiler to the point where you could compile it using itself. And as soon as we would get to that moment, we knew the product quality and the acceleration was going to go really fast. At that point, we were our own customers. We were developers building tools for developers, building stuff for ourselves. So we wanted to have a say in how it turned out and make it better. Now. This was a very formative experience and enabled me to see management through a totally different lens. I was interested in this kind of management. It was something I could get behind. It's like even something I could see myself maybe doing in the future. But the way it worked still remained a bit of a mystery. So when I don't understand something, I naturally get a little more interested in it. And I did that over time, and I started picking it apart. I had a few more jobs and I eventually became a manager, but was still looking for a cool way to help teach some of the things that I had learned over time. Then one day, much later, I was reading about quantum mechanics, and physics was still my first love. And it all sort of came together for me that many quantum mechanics concepts are like perfect metaphors for managing creative teams. So what do managing creative teams and quantum mechanics have in common? First off, do we have any physicists here today? Anyone? Any physicists? Oh, good. For those of us who aren't physicists, thankfully it's all of you. It's really hard branch of physics to understand. Even Richard Feynman, one of my idols, one of our most celebrated Nobel prize winning physicists, once exclaimed that nobody at all understands quantum mechanics, but I'm going to try to give a simple explanation. Classical physics, kind of what I learned when I was growing up, deals with large macroscopic objects, from projectiles to parts of machinery and astronomical objects such as spacecraft, planets, stars, galaxies, all very predictable things. Quantum physics is the science of the very small subatomic particle. Small particles we didn't even know existed 30 years ago. Classical physics breaks down at this level. Subatomic particles can act in very strange ways, often very unpredictable ways. So classical physics and quantum physics have a strong parallel with the two types of management that I experienced back in the east Coast. At Penn State, I experienced classical managers using classical management techniques. And at Borland I had, for lack of a better term, quantum managers. Let me try to illustrate two types of managers with a couple of historical examples. Henry Ford was a classical manager. Before Ford, cars were already invented. Cars were hand built. But Ford wanted to build a whole lot of cars and it wasn't possible to do by hand. So he pioneered the assembly line technique for mass production, also known as the line, back in the day. And this was the first operations management. Ford scaled production using humans for labor, doing repetitive tasks. He knew exactly what he wanted, he knew what the outcome needed to be. He didn't need to invent anything. Classical management techniques made total sense in this context. On the other hand, Robert J. Oppenheimer, I think he was more of a quantum manager. He was a theoretical physicist and he was a director of Los Alamos National Laboratory that designed the first nuclear weapon known as the Manhattan Project. He just had this idea that he could create a massive explosion by splitting the atom. Unlike Ford, Oppenheimer had no idea how to achieve this outcome. But he believed it could be done. And his approach was just to start recruiting the smartest scientists that he could find and tell them what the end result needed to be. He trusted them to just go figure it out. For over five years, Oppenheimer kept the team focused on what the outcome was. He kept asking good questions along the way, getting the resources the teams needed to accomplish their goals, and kept them all inspired and believing in what they were accomplishing. He grew this project and we talk about scaling companies today, but he grew this project from just five people adjust himself to 130,000 people in under five years to date. I think it's one of the most amazing examples of large scale team based innovation. Now Oppenheimer also understood that innovation can also come from very unexpected places and you want people from different backgrounds, different perspectives and even what non experts involved in your process. Sometimes experts can be hindered by their knowledge of what's possible. Innovation isn't always just thinking up something completely new using your expertise. Innovation more often comes from taking something and just applying it to a different space. The key breakthrough on the Manhattan Project didn't even have to do with nuclear physics itself. It had to do with the precise timing of detonation of lots of conventional explosives. There was something called explosive lensing. And if you look at the picture of the original bomb, all those wires that are covering it and the devices, those were used to control the detonation of the explosion. And that's the thing that can't be replicated very easily today. Oppenheimer and Ford were both very successful. Just what they were trying to achieve was very different. Ford was optimizing for efficiency, quality, reliability, cost. Oppenheimer needed to invent. So managing for efficiency, quality and reliability is very different than managing for creativity. In fact, the things that work for quality and reliability can kill innovation. Like the processes and techniques that you need to put in place can just slow things down dramatically. If you've ever implemented Six Sigma or tried to get a system to five nine's reliability, you probably know what I mean by this. Even though more creative teams are emerging across industries, the management textbooks that you read today are still basically classical management techniques. It's because management's like a fairly new field. There was no need for it before the 1900s. It actually came to be in the early 1900s with the industrial Revolution. Before then, the closest thing to large scale workforces for thousands of years were really just military and organized religion. But then Ford's assembly line was invented. Enter operations management. And the same management philosophy has sort of been parroted over and over for the last century. I still love reading books about quality and efficiency. I've learned a lot from them. But there's so much more we can apply when we are managing creative teams. Now, if you think about a lot of the breakthroughs of this last century, I like to think that these came from quantum managers. And these are some of my favorites up here. JFK with let's put a man on the moon by the end of the decade. Elon Musk, well, you know, where do you start? He's like doing electric cars, commercializing space, trying to colonize Mars. In his spare time, he's building transportation tunnels under Los Angeles. Walt Disney pioneered bringing animated feature films to the screen. We've talked about Oppenheimer and Steve Jobs has changed the way we interact with, with computers and communicate. And when you look around, you start seeing it in more and more places. For example, university research is a type of creative team management. We're going to write a grant to go solve this problem. It's research. We don't even know if we can solve this problem. But go for it. Good. Venture capitalists are a type of quantum management. I like the direction you're going. I like the space you're in. Here's some money. Go try to figure it out. This is a recipe for innovation. When managers get too prescriptive, it can stifle innovation. And you can also demotivate the next generation of managers. So we've outlined the difference between classical and quantum managers. Let's get down to some concrete concepts. The first theory I want to talk about is the observer effect. It's an idea that simply observing a situation changes the outcome. So in 1935, Erwin Schrodinger, another physicist, in order to illustrate this, proposed a theoretical experiment. In Schrodinger's thought experiment, a cat. I don't know why I used a cat. I don't have anything against cats. Is placed in a sealed box with a device that has a 50% chance of killing this cat. Here's where it gets confusing. As long as the box remains unopened, the experimenter has no idea if the sequence that kills the cat has been triggered. Thus, according to the principle of superposition, the cat is in both states. It's both alive and dead. There's multiple answers existing at the same time. That is, until someone opens the box. In quantum mechanics, the act of observing changes the outcome and forces it into a single definitive state, alive or dead. And if you're confused, well, welcome to quantum mechanics and management. I think at this point. So today we're trying to actually leverage this principle of superposition in quantum computers to solve impossibly hard compute problems such as cryptographic and network routing problems with a classical computer. It's very binary. It's a world of bits 0 and 1, on or off. Quantum computing allows for massively parallel problem solving by leveraging all possible states simultaneously. And what this means is there's a lot of states. Quantum computing increases the information density by not just limiting to 0 or 1, but all the gradations in between 0 and 1. And there's an infinite scale of possibilities that can all exist at the same time. And if you're an engineer, one way to think about this is if you have an algorithm and you have some variables, if you can instantly run through all permutations of all variables at once, you'll instantly have the answer. And that's sort of the premise of some of the qubits in quantum computing. So how the heck does this translate into anything useful for management? Well, let's talk about this. Quantum managers manage for multiple states as opposed to singular outcomes. And we want to try to expand the number of paths to success by expanding the definition, by expanding the thinking about what is defined as success. For example, increasing revenue might be one definition of success, but so could increasing engagement or time on site. We want to avoid prescribing specific paths by focusing the teams on the outcomes and not how to achieve it. We want to let our teams come up with the ideas. And I'm passionate about this. One is managers should be hyper aware of the observer effect, Especially if you're in a position of authority and you're a manager. You have to be aware of how when you try to add value, you might limit the path to success dramatically. And this can be really hard as a new manager when you're so used to being a contributor. So often you want to be part of the team and you want to be part of the creative process. And I've seen it before, and I've done it before. A manager will take their team when coming on to a new project and walk into the room and go, okay, how are we going to do this? Well, here's an idea, here's what we're going to do, and inevitably start writing on the board. But when they're the manager, they really buy into the team with authority bias. And it's really dramatically reduced the number of paths to success. Chances are they're going to do that solution and not come up with their own ideas. Another example is sometimes you want to save your team from what you believe is the path to failure. I've done this as well. I remember having a time where I Believed that what the team was going to do wasn't going to work. I had a mentor that told me, hey, you know what? Just let your team fail from time to time. Stop trying to save them. They're not going to learn unless they fail. People don't learn by giving them the answers. They learn by failing and thinking for themselves. It took everything that I had to let my team fail, but it turned out that letting my team fail was also empowering them to redefine what success looked like. I was wrong, like, half the time, and the team was coming up with ideas that I didn't think were possible when they were working. It's very likely that someone on your team will think of a better solution than you. Now you have to know when and how to open the box. You'll eventually have to open the box and see what the state of your project is. But if you do this prematurely and not in the right way, you might kill the chances of success. Open slowly, using probing questions. Don't give up your solution yet until you think your project is dead. Back to Borland. This is how my manager had opened the box. He had come in and he was like, hey, Jim, how's it going with that project to protect engineers from losing all their work during a crash? And I was like, well, I'm trying to autosave periodically, like, every minute, but that's slow. It's causing the editor to, like, freeze, and you still lose some of your work when it crashes. And instead, he just came to me and he's like, okay, well, technically, what really happens when the program crashes? And that got me thinking, and I'm like, well, I know, like, technically, that causes an operating system exception. And then the light bulb went off. He wasn't operating systems expert. He didn't know that. But I knew enough that, like, hey, I can go take over that interrupt vector and write code to flush the buffer to disk. And the problem was solved. Ask probing questions. Even if you have a dead cat and you have some investigations to do, use it as a learning opportunity. Another quantum mechanics concept is entanglement. Einstein called this spooky action at a distance. And I think it's a really weird thing. What it is, is we can entangle two particles in such a way that when you do something to one particle, it has an effect on an entangled particle, regardless of distance. This is one of the things that they think that they'll be able to use to communicate over long distance in space, instantaneously. It turns out we can create entanglements in our teams and projects that have effects even if we're not there to cause them. I'm going to steal from Einstein here and I'm going to call it spooky management at a distance. So how do we create analogous of quantum entanglements in our company? Well, here's just a few ways that I've thought of and there's a lot more ways. Reciprocity, I think is a good one. It turns on that organizations take on the characteristics of their leader. So you want to exhibit the behaviors that you want your team to have. For example, making yourself accountable. One thing I like to do is I'll go into a one on one and I'll ask my team members what they think I should do better and then I'll follow up the next week and I'll ask to them, I'll try to make active progress to it and I'll ask if they saw the progress. And when you're accountable to your team like that, believe me, they're going to be a lot more accountable to you. Empathy is a really important one and building good software is an act of empathy. And if we as product developers can truly feel the customer pain, we can make it go away. Companies are dogfooding their products, but the more you can get your developers using the products in any way, the the better the software is going to be. At Borland, we built Borland C Using Borland C. At Facebook we use our consumer tools to communicate and share information internally. Incentives. A lot of people think incentives are monetary, but it doesn't have to be impact. Visibility, a pat on the back, recognition from your manager. The more approval that your team gets from you and visibility in the company, the better they'll do. Camaraderie is an important one. Building relationships between your team members increases communication and increased communication leads to better products. Encourage people to get to know each other on a personal level and you can do things like set up happy hours, dinners, team building events. Co location is very important. Try to help foster building relationships. The work environment itself is important. Tech companies don't have all these perks just to be nice. They attract and retain talent. But really what we're trying to do is they're designed to allow people to focus on their work. Humor is actually important. Strategic use of humor in workplaces releases stress, boosts engagement and fosters creativity and collaboration. It turns out we don't have to be dry and boring as managers. So I've talked about getting better results out of our teams, but we're also part of that team. So how do we get better results out of ourselves? And it's almost impossible to observe ourselves. It's very hard to get better all alone. And we are in our own sealed boxes and we're in our own constant state of both success and failure. In order for us to be successful, we have to be constantly seeking feedback from outside. Have a manager or a board member run a process. Get 360 degree feedback. Consider anonymous feedback mechanisms. Get external mentors and coaches. There's lots of ways to do this. Today I highlighted two very different management philosophies, classical and quantum. I think we're gonna see less classical management in the future. Companies are not gonna be competing on repetitive work that is becoming more and more automated. At Facebook, we try hard to start by letting ideas come from the bottom up and focus our teams on customer problems, not on our solutions. As managers, we look at our jobs as quantum. Managers are to hire and inspire great people and to facilitate success by increasing the paths to success. By setting up the environment and the entanglements to increase the chances of success. In this process, we find out that our teams may lead us somewhere that we hadn't imagined. I know my teams have thanks.