SPEAKER

James Everingham - Head of Engineering, Calibra @ Facebook

James is an engineering leader at Facebook. Previously, James was the Head of Engineering at Instagram. Throughout his 35-year career as a manager, entrepreneur, and technology developer, James has led many world-class engineering teams. At Yahoo he was Vice President of Engineering for Yahoo media properties after the company acquired Luminate, an interactive image technology company which he founded.

His approach was just to start collecting, recruiting, the smartest scientists he could find, and tell them what the end result needed to be. He trusted them to just go figure it out.

<cite>- James Everingham </cite>

Some of his other previous roles include CTO and founding team member of LiveOps, Senior Director of Engineering at Tellme (acquired by Microsoft) and Senior Director of Engineering at Netscape Communications where he was responsible for the flagship Netscape browser. Before joining Netscape, James held engineering and management positions at Oracle and Borland International.

Show Notes

• James’ early introduction to management at Penn State & Borland. (4:14)
• What managing creative teams and quantum mechanics have in common. (8:33)
• A simple explanation of classical physics and quantum mechanics. (9:19)
• Henry Ford and classical management. (10:25)
• Robert J. Oppenheimer and “quantum management.” (11:12)
• The distinction between classical and quantum managers. (13:33)
• Other examples of quantum managers. (15:06)
• The observer effect. (16:19)
• Translating the principle of “superposition” into management. (18:42)
• Quantum entanglement, “spooky action at a distance”. (22:37)
• Creating positive “entanglements” and “spooky management at a distance” in your teams using reciprocity, empathy, and camaraderie. (23:09)
• How to get better results for yourself using feedback. (25:29)

Transcript

Alright, good morning everyone. Can you hear me okay? We got the mic on? All right, thanks for the warm intro and thanks everyone for having me here today to talk. Today, I'm gonna 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, a prerequisite to being a physicist you kinda have to 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 kinda 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:00 AM, not 8:05, 8:00 AM, and I'd sit down, and my boss would have my work all put out for me, usually API's, and I'd sit down and just start implementing the stuff that I needed to do. I was part of the assembly line, you know. 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 seem to do this weird people stuff and, like, 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!

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 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, like, who was managing the product. Software was just sort of happening.

At first, that's me up there. 27 years, 28 years ago, I don't even know anymore. At first, I thought from the way my new manager was working, I'm like, "Oh, my new manager is kind of lazy, he's like not telling me what to do, he doesn't even seem to 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 things 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.

But bosses here at Borland, they knew what they wanted, they just avoided being prescriptive about how to get there. And, as a team, we're all super-invested in the product.

I remember thinking how cool it was that when we were coming up with the new version of Borland 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 gonna 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 it enabled me to see management through a totally different lens. Totally different lens. So, 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 then I eventually became a manager. I 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 a 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 he believed that nobody at all understands quantum mechanics. But I'm gonna try and 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 way. 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.

Now, Robert J Oppenheimer, anybody know Robert Oppenheimer? Excellent, okay on the other hand, 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 collecting, 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 that they were accomplishing. He grew this project, and we talk about scaling companies today, but he grew this project from just five people, and just 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 want 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 experience and your expertise. Innovation more often comes from taking something that you know 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 explosions. There is 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 are 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-nines 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 centuries, 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 and I've learned a lot from them, but there's so much more that we can apply when we are managing creative teams. Now if you think about a lot of the breakthroughs for 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 where do you start? He's doing electric cars, commercializing space, trying to colonize Mars, and 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 computers and communicate.

And when you look around you'll start seeing it in more and more places.

For example university research, it's a type of creative team management. We're gonna 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 wanna talk about is the observer effect. People hear of the observer effect before? Superposition? Good, it's an idea that simply observing a situation changes the outcome.

So, in 1935 Erwin Schrödinger, another physicist, in order to illustrate this proposed a theoretical experiment. And Schrödinger's thought experiment, a cat, I don't know why he used a cat, I don't have anything against cats, is placed in a sealed box with a device that has a 50% 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 are 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 and 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, zero and one, 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 zero or one, but all the gradations in between zero and one. 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 wanna 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 wanna be part of the team and you wanna 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 onto a new project and walk into the room and go okay, how are we gonna do this? Well here's an idea, here's what we're gonna do and inevitably start writing on the board. But when they're the manager, they really bias the team with authority bias, and it's really dramatically reduced the number of paths to success. Chances are they're gonna do that solution and not come up with their own ideas.

Sometimes another example is sometimes you wanna save your team from what you believe is a path to failure. I've done this as well, I remember having a time where I believed that what the team was gonna do wasn't gonna 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 gonna 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 and 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 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 auto-save periodically like every minute, but that's slow, it's causing the editor to freeze, and you still lose some of your work when it crashes. Instead, he just came to me and was like Okay well technically what really happens when the program crashes? And that got me thinking and I'm like, well I know technically that causes an operating system exception, and then the light bulb went off.

He was an 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 particles in such a way that when you do something to one particle it has an effect of 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 distances 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 gonna steal from Einstein here and I'm gonna call it spooky management at a distance.

So how do we create analogous quantum entanglements in our company? Well here's just a few ways that I've thought of and there are 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 wanna 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 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 a way, in any way, the better the software's gonna 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.

Comradery 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 setting 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, humor's actually important and strategic use of humor in workplaces releases stress, boost 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 celled 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 mechanism, get external mentors and coaches, there are lots of ways to do this. Come on, all right there we go.

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, that's all I have, and if we have a few minutes I'm happy to take a few questions. Thanks.