The purpose of this document is to provide a framework for leaders to build and optimize their operations. The document was written from the perspective of a Head of Operations, not a COO. Thus, it’s focus is on the Operations function, not the overall company’s operations (which include Sales, Marketing, Tech, Finance, etc.). Also, it was written from the perspective of a Head of Operations overseeing many markets, each with it’s own respective General Manager or Operations Manager leading a local team of hourly supervisors and associates.
https://www.loom.com/share/56a3113775f74cf29b255efab126ac65
<aside> 📖 In the autumn of 2001, just as Good to Great first hit the market, Amazon.com invited me to engage in a spirited dialogue with founder Jeff Bezos and a few members of his executive team. This was right in the middle of the dot-com bust, when some wondered how (or if) Amazon could recover and prevail as a great company. I taught them about “the flywheel effect” that we’d uncovered in our research. In creating a good-to-great transformation, there’s no single defining action, no grand program, no single killer innovation, no solitary lucky break, no miracle moment. Rather, it feels like turning a giant, heavy flywheel. Pushing with great effort, you get the flywheel to inch forward. You keep pushing, and with persistent effort, you get the flywheel to complete one entire turn. You don’t stop. You keep pushing. The flywheel moves a bit faster. Two turns… then four… then eight… the flywheel building momentum…sixteen…thirty-two…moving faster…a thousand…ten thousand…a hundred thousand. Then at some point - breakthrough! The flywheel flies forward with almost unstoppable momentum.
</aside>
As Jim Collins describes the flywheel, building the Operations Management System at first was hard. We needed the right people, systems and culture to slowly make that first turn, then the second turn. We made a lot of mistakes at first. But then, as we learned from our mistakes, as he described, the flywheel got easier. It was easier to hire great operators, because all we had to do was show them how we worked and for them to talk to future peers. It was easier to bring on new great tools, because we had set up the technology architecture in a way to do so. And it was easy to see our wins and hold everyone accountable, because our scorecard was extremely clear.
Unfortunately, the flywheel didn’t have a happy ending. We were acquired and the flywheel was almost immediately disrupted (a story for another day…). And that is why this document was created - to document the flywheel so we can replicate it again in the future.
We also only hire and retain what we call “A Players.” We know A Players only like to work with other A Players and are never threatened by a new A Player on the team. But B Players hire C Players because they want to look better. And what does a C Player do? They hire a D Player. This is what Steve Jobs called the, “Bozo Explosion Theory.” It is why it’s so important to only have A Players.
What defines an A player? It isn’t experience or capabilities. A “A Player” can be at any level of the organization. They are defined by two characteristics.
Integrity is hard to evaluate in any candidate. The quality of references provided will usually provide some insight into integrity. Integrity boils down to someone who acts with the interests of the company in mind and never does anything they wouldn’t be proud to see in the Wall Street Journal.
Growth mindset is the opposite of a fixed mindset. A fixed mindset is one that thinks in terms of absolutes, such as, “This is the way things are, and this is the way they will always be.” People with fixed mindsets believe in limited resources; they believe that people have an innate and fixed level of intelligence and that effortless success is the badge of the truly talented. If someone has to put forth enormous effort, it reflects a lack of skill or talent. It seems that effort is a bad thing and reflects that a person is not smart or talented. In summary, a fixed mindset is held by those who believe their talents are innate and worry about looking smart.
On the contrary, a growth mindset is one that views the world as more malleable, believing success is achieved through effort. Growth mindset people embrace rather than avoid challenges, and they persist during times of setback. They learn from criticism and are inspired by the success of others. They put their energy into learning.
The knowledge that things are malleable inherently creates an interest for solving problems, generating innovative solutions, and implementing ongoing improvement. When individuals possess this mindset (which can be cultivated), the organization then becomes one of collaboration, growth and innovation.
The role of Technology - in the way it relates to the Operations Management System - is to eliminate manual work and enable processes to scale in a sustainable manner. Any process handled in a spreadsheet or with pen and paper is to be replaced with a tool that ensures scalability.
Our organization evaluates the “buy vs. build” software question by understanding if its needs are truly unique to the organization, in which case it should build the tool, or if it’s a common process and best used with a third-party provider. For example, third-party software can be used for associate scheduling, payroll and fleet telematics, as these are processes thousands of companies require and aren’t unique to our company. The key to choose the best third-party software is to review the quality of the provider’s API documentation and third-party integrations. If the provider is a cloud-native, API-first company, their data can be ingested into our central database and linked to other data to drive insights and continuous improvement.
Below is a sample outline of what a technology ecosystem could look like. Note there are three notable logos missing: Oracle, SAP or SalesForce. Oracle and SAP have ERP systems which are massive and require their own internal engineering teams to manage. SalesForce has a wide variety of options, but in general I’ve seen SalesForce prefers development within its own ecosystem rather than prioritizing first rate connectivity to other platforms. This makes sense given its position in the market, but it’s better to have flexibility to plug and play the best third-party software as needed, rather than to lock into one ecosystem.