Reasonably smart people, given enough context, do reasonably smart things.

I remember a particular time at Netflix where we had a site outage. Of course we had more than one of those as most companies do at that scale. In this case the outage was caused by the decision of a single engineer. I don’t actually recall the specific details that led this engineer to make the fateful decision he made. But he made a mistake that appeared innocent enough but ended up impacting millions of customers.

This isn’t though what makes the story interesting. It is the response by leadership that taught me a lesson that I still learn from each and every day.

At the time Kevin McEntee, the VP of Engineering, was my direct manager. The morning after the dust settled and the site was back up, he called us all to gather in his office. I was pretty sure this was going to be a painful conversation. After all Netflix has a reputation for only keeping the highest performers. What would happen to this engineer?

After Kevin went over the details of the outage, I remember him making a statement that completely took me by surprise. He said “the failure is not really with this engineer, the failure is with us as leaders”. Huh? He went on to add that it was his belief that if the engineer had had the context that all of us have, then he would have most likely made a different decision. The outage was really caused not by incompetence, but by a lack of context.

He said something along the lines of reasonably smart people, given enough context, do reasonably smart things. It is our job as leaders to give the necessary context to our teams.

Context Will Make Teams Healthy

In an earlier post, I shared about a team that I once was tasked with turning around. The team was starved for context. All contact with the customer (the product was a key internal platform used by a couple dozen other product teams) came through a single person. That person communicated what the customers wanted done through stories (in agile methodologies, tasks are framed as user stories). The problem is even though a story is supposed to capture context, in this case, they became just tasks once it made its way to the engineering team. They became tasks that had a shadow of the original context. Why? because humans need to be able to discuss problems with the people who have the problems. This is why primary user research is so important. Once you pass customer needs through a few gate keepers you are playing the game of telephone and by the time it gets to the designer or developer it has been stripped of context. And there is no easy way for the them to explore deeper which prevents them from being able to use the many tools of their craft to create a truly innovative solution.

Context is Key to Creating Products People Will Use

Early in my career while working at American Airlines, our team was tasked with developing a next generation airline forecasting system. We had huge funding. We hired the best people that could be found. We used massively parallel processing systems for crunching the algorithms. We had a team of analysts that did nothing but model the new system all day and every day. Yet for all of this amazing brain power, it seemed we made no real progress. When you are in the midst of a project like this, you initially feel like you are making amazing progress. Lots of deep discussions, lots of code being written, lots of energy expended. Because our systems were going to be used by a small group of scientists & top business analysts at the company, we were warned not to talk to the customer. They were just too busy. Do you see the context issue?

After about a year our executives became very frustrated. There was still nothing actually being deployed to our customers. So I decided enough was enough. I quickly pulled together a prototype for one area I was pretty sure was a sticking point for them. I then walked over to the main user of this massive tool (it was a bit scary to be breaking protocol). I asked if I could just sit with him and hear what his biggest challenges were. Then I had enough to go an iterate on the prototype and promised I would show him something the next day. When he saw the prototype he got excited as it sparked some new ideas with him and his team. That began a strong relationship where they began to iterate with me on the prototype and suddenly we had a deeper insight & context into what our customers needed. It led to developing some simple tools that began to make their tasks more manageable. All we needed was a bit of context and an ongoing dialog.

Gate Keepers Often Hoard Context

In early 2000, I joined a startup in Dallas near a hip part of town, Deep Ellum. The company, NextJet, had created a same day logistics software system. There was one lead engineer in particular who seemed to know everything about the customer and dictated to the rest of us how the system had to be. The problem was he was focused on the backend systems and I was beginning to suspect that we were building things our customer (a highly specialized call center that managed these time sensitive orders) probably didn’t need. Recalling my experience at American Airlines, I began to ask questions about how the customer did certain tasks. It became obvious that they really didn’t know the answers. Now the crazy thing is these internal customers were just down the steps from our second floor cool startup loft. I discovered that not a single person designing or engineering the systems had actually met or talked with any of the customers! So I informed the team that I was going to spend a couple days sitting with our customers. Taking notes. Asking questions. And listening. And gain context. From that we started to tailor our experiences based on the needs at hand. The customers downstairs discovered there was a team upstairs that they could talk to. And before long we were building tools & experiences that radically improved the business. All because of context.

Context is Not Evenly Distributed

It works on the organizational level as well. On my second stint at Netflix (I left briefly for a startup and consulting), I was building a new team on the commerce side of Netflix. I had spent three prior years there building the overall user interface engineering organization. Now after returning, I took a smaller subset of that original team. I am sure it looked like a step down to some, but I was interested in the problem set and in my prior role had less time for this critical part of the team. One of the young engineers on my team was struggling with a problem with the signup process on our TV experiences. I asked if she had spoken with another engineer that worked on the movie watching side of the TV experiences. She said she had seen her in meetings but had never talked to her and wasn’t aware of what the other engineer was working on. That is when it really hit home to me. It is easy to fall in the trap of thinking the context you have is what others have. It is easy to assume that those on your team have the necessary context to do their best work for the customer. I introduced the two of them and it radically changed the way this engineer solved problems in our team going forward.

As organizations scale up, context sharing gets harder and harder. The first step is to be aware that context is not evenly distributed. And that context comes in many dimensions.

After that conversation, I created a small checklist of areas of context. And purposefully begin to steer conversations in future 1:1s to ensure that my team members had the context they needed and who to connect with to ensure a dialog that would continue to provide them with fresh context. 

Here are a few areas of context that I like to focus on:

• Customer context. As illustrated above, teams need to be soaked in customer problems, customer context. They need to have methods in place that ensure they are constantly exposed to customer context. As an exercise, start asking your team members to describe their customers and their needs. Often you will find that there are fairly diverging views on the customer. 
• Technical context. In technical systems there is often a lot of context outside of the technology artifacts. Why was the system built a certain way. Was it about getting the systems to scale rapidly and trade-offs were made? Did the product have some serious failures in the past that has colored the way software is now developed? 
• Organizational context. Who really are the gate keepers, the people with leverage in the system? Who are your counterparts in other organizations that can be your allies? Products get developed along communication lines outside of organizational boundaries, but a knowledge of the organizational structure is often necessary to get the right communication to occur.
• Cultural context. What beliefs inform the company? Is it a risk taking organization? A play-it-safe organization? Is it heavily process oriented? Or is it filled with people who are very individualistic?
• Business context. Do the people on your teams understand how the business makes money. How it creates tradeoffs that will affect technical decisions on the ground? One wise leader shared with me that she uses open office hours to discuss the intersection of business and product/technology decisions. It is a place to come and safely ask the questions. What she is doing is teaching them the tools to think and gather the right context to make the best decisions.

Context-Gatherers

As a leader, one of our primary jobs is to ensure that our people get the necessary context. This is frankly one of our hardest jobs. Maybe we ourselves have the wrong context. Or even if we have the right context, are we ensuring our people are given the right context.

But even more critical are we giving them the tools to continually receive fresh context from the customer and from the business? This is where teaching our people to ask “Why?” and to be first principle thinkers and not just doers is critical for teams to thrive and create the best solutions for our customers and our business. 

Frankly it is not just about teaching our teams the context. It is about teaching them how to be context-gatherers. It is about giving them the tools and processes to use first principle thinking to always ask why we do what we do. That always leads to the need to gather and process context and apply it to their daily work.

I think it starts though with a belief that reasonably smart people, given enough context, do reasonably smart things. This requires you to recognize the power in each of your people to do smarter things. then you begin to ensure your teams get the necessary context. But then you take it to the next step and begin to design your teams around how to teach your team to be context-gatherers. 

One last story to illustrate this. In early 2015, I took a new role at PayPal to create a new organization called Next Gen Commerce. It is a bit daunting to declare that you are going to be the person in the organization focused on next generation commerce. Am I saying that others are creating solutions that are not next gen? The first thing I did was admit to the organization that I didn’t really know exactly what this would look like. But I did believe in something very fundamental. If I got some reasonably smart people together who were of the DNA that liked to solve problems (in other words first principle thinkers) and I ensured that they were soaking themselves in the problems that surrounded how people were starting to use commerce in this new digital age, that they would surprise me and create truly next gen solutions.

So I gathered about 10 of those people around me. And we all took the approach that we didn’t know a lot of things but we were going to soak ourselves in problems. Within a year the team was so high functioning that I was able to hand the reigns over to my leader. She became a rabid context-gatherer and didn’t need me on a daily basis anymore. I was able to take on other responsibilities including leading the Venmo engineering organization because I enabled a team of context-gatherers. 

Reasonably smart people, given enough context, do reasonably smart things. Reasonably smart people given the tools to gather context do even smarter things.