So, is it Day 2 Already?

As you may already know, Amazon is going through a transition, with the departure of Jeff Bezos triggering multiple new appointments and one of them being a new CEO for Amazon Web Services. This week’s article in The Information, documents this transition which has all the hallmarks of the evolution of a fast-growing organization. 

One of the central tensions that usually arise as a firm grows, is the conflict between the “old guard” and the new hires. 

The old guard remembers the nimbleness that brought them to their current level of success, growing a business into a large organization, and the new hires are brought in to share their experience in operating these large organizations. The new employees bring with them practices from the previous organizations they worked for, and while some of these practices might indeed be appropriate, others might just be poor norms. 

In the case of Amazon Web Services (AWS), The Information reports that:

"The new arrivals have brought their own customs to AWS, including more paperwork and stricter management styles than AWS sales teams were accustomed to, the former AWS employees said. The changes have led to internal concerns about red tape and, in some cases, departures of senior people."

And indeed, this clash brings with it a common conflict:

"Already, there are warning signs that bureaucracy at AWS is causing internal discord, leading to a higher-than-normal level of departures in the sales ranks, said the four former AWS employees. Three of those people told The Information that the amount of time they spent filling out sales reports and spreadsheets increased dramatically after Greg Pearson, a longtime former Intel executive, joined AWS in early 2019 as vice president of Americas sales."

So, one can just chalk it as a regular conflict, since the organization needs to grow. As one employee says, "Customers are not getting smaller, and AWS isn’t losing customers. They all need sales and support teams.”

As usual, I would like to go a step deeper and understand the critical issue at the heart of the debate: When is it the right time to add processes and "red tape”?

This is probably the most common complaint I hear from each side. Founders wonder when the right time is to add a "formal" process, and on the other hand, new employees, who are tasked with bringing more repeatability to the growth process, complain that they get a cold welcome, which often hampers their ability to deliver on what they were brought in to do. One side calls it a process; the other side calls it red tape. 

If you are the founder of a 50-person company, you may be wondering how AWS (counting 40K+ employees) is relevant to you. Consider what one current AWS employee said in the article, 'A lot of AWS still runs on spreadsheets'—even the large firms have a long way to go.

What is a Process?

Let's start with the obvious question: What is a process? I teach Operations Management, where processes are used as the main building block for analysis. Once we characterize something as a process, we can then measure different KPIs and improve it. So, we use the term process to describe any routine work that has an outcome. 

In this post, however, I would like to discuss the notion of a formal process. So, what are formal processes? They go by many different names: workflows, checklists, procedures, standard operating procedures (SOPs), templates, etc.

If a business process is a collection of linked tasks that find their end in delivering a service or product to a client, a formal process is a set of step-by-step instructions compiled by an organization to help workers carry out routine operations. From this point forward, I will be using the term process to describe formal processes. 

So Why do we Add Formal Processes?

Initially, firms start off with very few systems and processes, beyond the rudimentary ones. Usually, there is cash flow projection and project tracking processes. As the firm starts scaling, and as needs arise, more formal systems and processes are added to manage the day-to-day, from interviewing and finance to product, sales, and customer support. As such, I think it’s always essential to stop and think about why we need formal processes. 

Let's go back to the article on The Information:

“Furthermore, some AWS employees said the cloud unit needed a little more bureaucracy, stressing that its informality and unstructured ways had become a hindrance as it began selling to bigger customers. “Part of the reason they are making changes and adding new leadership principles is that we have a lot of internal processes that don’t scale” 

From scalability to complexity, this quote brings up multiple reasons as to why adding processes makes sense. When thinking about why we need formal processes, you may hear many opinions, but the most helpful book on this topic in my opinion, is High Output Management by Andy Grove, the legendary CEO of Intel.

Andy Grove talks about the two main reasons that firms should adopt formal processes:

First, the ability to standardize and improve routine work: One of the first observations the book makes is that everything is a process. Whether you’re compiling code, hiring staff, or making breakfast, everything can be modeled as a repeatable process. Once you model something as a process you can start improving it. You can tap into the existing knowledge in operations management and together with the domain knowledge, drive higher performance. 

This brings us to the second, more critical reason Andy Grove outlines. Formal Processes increase managerial leverage. Managers are responsible for increasing the output of their organizations and the adjacent units they influence—managers “leverage” their time by spending small amounts of it to have a significant impact. Processes allow managers to delegate work, supervise others, train workers, all by creating and improving processes.

The book acknowledges one of the most important aspects of processes. As organizations grow, speed decreases while leverage increases. Businesses become more complex as they grow. Duplication and redundancy increase — multiple products may lead to various marketing teams. For example, decisions are made to centralize functions for consistency and greater leverage or to keep them decentralized for greater speed. In other words, you gain leverage while becoming less nimble. And this is precisely what the people at Amazon are saying. 

The approach taken by Andy Grove is driven by management, a top-down approach to the value of processes. The approach that Sutton and Rao (both Professors at Stanford) are taking in their book, Scaling Excellence: Getting to More without Settling for Less, is bottom-up, thinking about the employee first. 

The idea in their book is that the main goal of processes is to reduce the cognitive load of employees and decision-makers. Their main argument is that, as the organization grows, the volume and complexity of changes often overwhelm the working memory of individuals who do the work. This, in turn, produces blind spots and bad decisions. That’s what they call cognitive load. “Scaling requires a penchant for parsimony, for understanding the nuances of an organization and its people so you can make things as simple as possible – but no simpler.” 

As usual, easier said than done. 

But this is the essence of workflows: reducing the need to make decisions when decisions take time and attention away from what truly matters. 

There are several other reasons to add processes. 

For example, processes allow us to have labor arbitrage. Employees that are less skilled can deliver equally good outcomes when guided through the right process. Primarily, and as the firm grows, labor arbitrage is going to be crucial, especially given the significant shortage of highly skilled employees in almost every area of technology. 

Another view of processes is well articulated by Ben Horowitz, who provides the following definition: “A process is a formal, well-structured communication vehicle.”

Allow me to illustrate further, using my own experience. 

At ForClass, a venture I co-founded, one of our first formal processes was the customer acquisition funnel. One of the main challenges we faced as a venture was that, in order to convince instructors to adopt the product, we had to have many touchpoints. Initially, my co-founder and I did most of this work. I would speak with the instructor, demo the product until the instructor was willing to try it, and then hand it off to my co-founder. He would take over and do the rest of the work until the instructor was almost ready to use the product, whereupon I would rejoin the process to help with the final on-boarding.  

This routine was very informal but worked well. We were fast and nimble, and had great results, which brought us more customers. In turn, this increased our appetite for even more customers - faster. So, we hired people to help us out.

As we started hiring inbound sales reps and operations people, and expanding to new instructors, we realized that the customer acquisition process was quite more complex than it initially seemed. It required several touchpoints: from the first email to a call, to a demo, to another demo, to another call. The main issue with our decision-makers (customers), which at the time was mainly faculty, was that they did not want to think about teaching too early, while focused on research, or too late, when they had already committed to their syllabus. This gave us a very narrow window where we could convince them to use the product. There was very little room for mistakes or miscalculations. 

The other problem we faced was that these steps required different people and roles. We started to realize we were losing sales because customers were falling through the cracks. We were moving customers from one stage of the acquisition process to the next, ensuring their interest, but we were failing to follow up and ensure the sale within the time frame we had identified as our window. I am sure that for some of you this may sound trivial, but the amount of work we had due to new and existing customers didn’t give us much time to think about how to improve the process and fix what was wrong. 

Until we realized that we were spending too much time working on the day-to-day, customer to customer, and were losing sight of the big picture (and with it too many prospective customers). We identified this as a critical problem and built our first formal process: the customer acquisition funnel. We established a process, identified at which stage of that process each customer was, and monitored them closely. We monitored how many touchpoints we had, what progress was made, and which steps were needed next, to close the sale. 

We built a dashboard around this process, measuring the inputs, outputs, and their quality. Following the advice outlined by Andy Grove, we established a new Monday morning meeting where we would look at how much progress was made, where the bottlenecks were, and what could be done to improve the outcomes, and as co-founder, I managed this process to identify obstacles where my actions could have leverage.

This example illustrates that the primary goal of a process is not only to streamline or standardize work, or to ensure that resources are used efficiently. It is also about communicating that all these are important aspects of a specific activity (as per Ben Horowitz’s definition). It is about communicating that we care about the replicability of the work and the speed, that we see this area as critical.

In other words, processes are a manager’s best friend. 

Why Should we Not Add Processes?

After all of this talk about the benefits of processes, I am sure you are about to ask, “where’s the catch?” 

Again, let's return to the article in The Information.

“One of those people, a former AWS salesperson, estimated he spent around 70% of his work hours on paperwork, which included writing a business review every week, month and quarter. The weekly review included a day-by-day breakdown of which customers the salesperson met with, the people he spoke with and what action he was able to get each customer to take. The weekly reporting requirements didn’t make sense for deals involving AWS services that typically take months or, in some cases, more than a year to close, such as the Amazon Connect call center product, said two of the former AWS employees.”

This quote illustrates the main reason why not to add processes too early: you add complexity to the organization. Keith Rabois, the founder of Opendoor and among the early employees at Payla, spoke in my class two years ago. Keith is one of the main proponents of the idea of radical simplicity, and one of the key ideas he discussed is that, organizations are the outcome of the balance (or net effect) between the sheer acceleration of the founding team (with its innovation and passion) and the gravitation of human complexity. When you add processes, you add unnecessary complexity. 

After discussing communication in the previous section, it is important to note that adopting processes also comes with a negative message regarding our trust in the people doing the work. There are times when we don’t feel confident that employees will properly allocate their time and resources. In these cases, processes help in measuring, documenting, and improving this gap, but may lead to employees feeling surveilled, which may potentially alienate them. 

But there are also other reasons not to add processes. Whenever you formalize a process, you do it based on your existing knowledge. Even if you use lean operations processes and have a very innovative team, you don’t update the process often enough to add new knowledge to your know-how and know-why. 

Considering these together, I will say that the main reason to avoid adding processes is that estimating the counterfactual, the unintended consequences, is a very challenging task.  

The term counterfactual is used commonly in research. We build a model which analyzes the past and we estimate parameters. Building such a model allows us to conduct a thought experiment comparing what actually happened and what would have happened in the absence of the intervention.

It is easy to see the benefits of a process after we have added that process. However, trying to predict whether the outcomes of putting that process into effect will be beneficial or not, is another story. It is hard to run a counterfactual analysis and understand, beforehand, the unintended consequences (including employees leaving) that result from adding processes. It is also hard to estimate the impact of losing knowledgeable workers due to red tape.

The trouble with processes is that once they are added, they are never removed.

They remind me of a joke that Slavoj Žižek, an important philosopher, says about a guy called Rabinovitch who wants to emigrate from the Soviet Union (it’s an old joke). When the bureaucrat asks him why, Rabinovitch says, 'I have two reasons'. His first reason, he says, is that he’s worried that the Soviet Union will lose power due to corruption. 'Never', replies the bureaucrat, 'we will never lose power’. ‘That’s the second reason,’ Rabinovitch retorts.

Even the worst processes are never erased. We only add new processes to cover the shortcomings of the previous ones. 

Is there a Solution? 

There is no simple solution. The main recommendation is to understand the counterfactual and weigh it appropriately. 

The second recommendation is to give ground grudgingly, which is Ben Horowitz’s main moto:

"When you scale an organization, you will also need to give ground grudgingly. Specialization, organizational structure, and process all complicate things quite a bit and implementing them will feel like you are moving away from common knowledge and quality communication. It is very much like the offensive lineman taking a step backwards. You will lose ground, but you will prevent your company from descending into chaos."

In other words, better be late than early. 

As a final note, it is interesting that the current AWS employees are hoping that the new CEO, Adam Selipsky, is going to reduce the amount of red tape, while if you ask his previous employees at Tableau Software, they would probably LOL. 

"While Selipsky helped show Tableau’s sales teams how to engage with large customers in a systematic way, not all employees were on board with his vision. Many senior leaders left the company in the months and years after Selipsky joined, in some cases because they felt that Tableau was losing the nimble startup culture they preferred, said the former employee."

This shows us that it is more related to the stage rather than the person. To scale, we want to reduce the impact on the individuals (and thus add processes). But the more we scale, the more we realize we depend on people and leaders. 

I would love to hear about creative solutions that you have implemented in your organizations to maintain this balance as you grow.