A Few Days of OP1 — Perspectives From Middle Management
OP1 is a massive bureaucratic monstrosity, where billions of investment and over a million employees are allocated to projects across Amazon. And this is a bit of what it feels like to be buried in the organizational structure.
I wrote A Day in the Life of a Senior Manager at Amazon recently. It became one of my most popular articles of all time. It was fun.
But perhaps more fun than the traffic, was the volume of emails I received from people saying that they loved to read the "day in the life" style articles. Since they enjoyed it (and it's fun to write), I decided to do it again. This time, I am focusing on the annual planning process at Amazon - AKA OP1.
First, some background information.
Amazon's annual planning process is called OP1, or Operating Plan 1. At a very high level, each organization begins somewhere around June, and comes up with a plan for what they'll be doing over the following year, starting in January. That plan is a 6-page document (with a massive appendix), explaining in very crisp language what they'll be doing.
That plan includes goals, metrics, new investments, and how their existing investments (particularly headcount) will be spent across projects and maintenance.
That plan is iterated on, almost continually. Interspersed in there are finance reviews, VP reviews, top-down changes, and S-Team reviews. Some organizations are important enough to get CEO reviews, but many don't go that high.
At some point, the plan becomes OP2 (or Operating Plan 2), which always amused me because it meant nothing apart from a naming change to the vast majority of the company. You continue making smaller and smaller edits until at some point, often all the way into February, the plan is finalized.
At that point, teams generally have approved headcount, a list of projects they're supposed to execute on, goals they're supposed to achieve, and it's time to execute for a few months before OP1 starts.
The system is both functional, and a bit insane. But as Benjamin Franklin said, "OP1 is the worst annual planning process, except for all the others that have been tried." You try to come up with a more sane process which coordinates the allocation of literal billions of dollars, headcount changes across a million employees, and still retain a somewhat agile massive corporation.
That all being said, I'm going to walk through the experience of being a mid-level leader involved in the OP1 process. This comes from a time when I was a Senior Manager.
To be clear, I don't intend to detail every part of OP1 because a mid-level leader does not participate in every part of OP1. Instead, I intend to communicate the feeling of being a part of the process, and some random observations I've made participating in this process a dozen times.
Wednesday in Early July, 9:32am
I walked into a meeting labeled "OP1 Kickoff". Doreen, one of the TPMs (Technical Program Managers) in our organization, had sent out the invite. I assumed they were tapped to organize our OP1 document this year.
Milton sat in the chair next to me, and popped open his laptop. Milton is another Senior Manager.
"Are you excited?! I'm so excited! I love OP1!" Milton said excitedly. "And it's been at least a few weeks since we edited this year's OP2 document! I've missed it so much!"
I like Milton.
"Yes, I wish they'd just add OP3 and get rid of this strange gap where we're supposed to execute for a few months." I said. "Why can't we just edit docs year round?"
Milton nodded. "I'm going to ask for a pony in our doc this year. I've always wanted a pony."
"Ok folks, thanks for attending!" Doreen said to the room full of 25+ managers, senior managers, and Directors. "This is our first of many OP1 meetings. I know many of you have been through this before, but the timeline changes each year, so please bear with me while I walk through the current dates."
Doreen proceeded to go through a calendar of dates, including when headcount requests are due from each team, when they'll be finalized, when the narrative would be finalized, and more. While it's a great start to have a list of dates, I'd also been here long enough to know that most of those dates would go out the window shortly. Because plans continually change. And TPM schedules are helpful, but optimistic.
"Our first step is for everyone to fill out the associated template with your headcount, planned projects for next year, and maintenance requirements." Doreen said. "That will enable us to begin figuring out our overall department ask. Please get those spreadsheets uploaded into Sharepoint by next Tuesday. We'll get them consolidated, and review the overall ask with finance on Thursday."
If any process favored managers who knew what was about to happen, it was this one.
Doreen was suggesting that the spreadsheets being filled out would be useful to finance as a way to gauge how much our organization would need to grow. I knew that was nonsense. I usually speak up when a process doesn't make a ton of sense, but there were too many people in the room to disagree with Doreen in public.
Thursday in Early July, 11:57am
"Hey Doreen, have a moment?" I asked. I'd just popped my head into Doreen's cube.
Doreen was at her desk, and looked up from her laptop. "Yeah Dave, what's up?"
"I'm a bit concerned about this spreadsheet plan. Without constraints or a list of department wide projects, it's likely to be a bit of a mess." I said. "Unless the managers have guidelines, the results will be too random to be useful."
Doreen shook her head. "We need a baseline to start from. We can update the numbers as we go along if things aren't fitting in our budget."
It's not my process, and I didn't feel I was going to get anywhere, so I nodded and left.
Friday in Early July, 4:52pm
I worked with the managers reporting to me to come up with a reasonable, but aggressive growth plan. It's a mixture of maintenance, some technical work to improve our systems, and some projects I'd heard about from the product managers. I know most of it will be thrown out, but we need a starting point.
Manager who continually asks for more headcount. "I think the number of engineers on-call needs to double if we'll have more customers next year."
Me. "What did you do so poorly to make your on-call scale with the number of customers?"
Manager. "Well... I'll look at that more closely. Maybe we won't need to do that. That was just an estimate."
Manager who recently was an engineer. "If the PMs want to add that feature, I'll call it 2 weeks."
"Does that include QA time?" I ask.
Manager. "Oh. no?"
"This needs to be an all-up estimate." I say. "That includes every phase. Requirements. Meetings. QA process. Design. Plus, remember this is calendar time, not effort."
💡 It's an important piece of context that even Amazon employees frequently mess up. Imagine you have meetings, emails, tickets, discussions over coffee, and slowly code one feature over that week. The feature might have been 8 hours of coding, but 1 week of calendar time. For the purposes of budgeting a feature, it's said to cost 1 week. The 8 hours of actual time (or productive time, or task time, or effective time) is interesting to know, but not useful when budgeting.
Any year is assumed to have 48 weeks of calendar time, as it creates some simple math, and assumes a few lost weeks due to holidays, vacations, etc.
Manager. "Oh. Right… Perhaps half an engineer? 24 weeks?"
Me. "Yes. Good."
Yes, that's frequently how fast these estimates are decided.
Another manager on the team. "For the launch in Brunei, I'm going to estimate 24 weeks."
Me. "There's no way the Brunei launch will be approved. I'll leave your estimate in there, but we'll put it below the line, so it won't be in the aggregate ask."
The manager. "But a PM said Brunei was essential."
Me. "Yeah, I'm sure it's important to them. If I'm wrong, it'll be brought above the line."
After working with my managers, and making arbitrary guesses of which projects would be approved and not, I ended up with around 40% growth for each of my teams. Unlikely to happen. But during these processes, people don't tend to increase your headcount. It's like negotiating for salary. You always ask for more than you expect to get. But you try not to ask for anything crazy because it'll annoy people.
I submit my spreadsheet, and go back to doing my normal job.