When I last wrote about 
what to do instead of quarterly planning, I did not mention the word “budgeting” and its relationship to planning. While everything said in that post is true, to dismiss budgeting leaves a huge gap that has to be addressed. The US Securities and Exchange Commission (SEC) requires that publicly traded companies file both quarterly and annual reports on an ongoing basis. While financial forecasts are not a part of these requirements, it has become the norm to do so. In order to provide more accurate financial forecasts, most publicly traded companies adopt a budgeting process. However, budgeting only tells one half of the story: spend. To get the other half – revenue – you want to understand projected product and feature releases with associated revenue forecasts. This gives you both sides of the coin for your overall financial forecasts. However, it leads to the conflation of budgeting and planning, and creates a game to be exploited no matter how you slice it.
First things first: no, Amazon isn’t perfect…
Let’s start with the elephant in the room. The combination of budgeting and planning has been most popularized by Amazon’s Operating Plan 1 (OP1) and OP2 process, which I experienced for about 6 years in Amazon Retail (which admittedly was very different from AWS when I was there). This process occurs every 6 months and was led by the Software Development Manager (SDM) function, typically at the Senior Manager level (Amazon L7) with support of the SDMs and TPMs they supported. Effectively, spreadsheets were created that said what was planned in the next 6-month cycle, and what could be done with additional headcount. If this sounds output vs outcome focused, well, I argue that the process did not dictate either way – it was up to the SDM how to leverage it. The reality is it was a mix of both; the reason this process worked (works?) at Amazon is because they have the culture to handle the flaws in the process.1
This is why when people ask me about my experience with the OP1/2 process at Amazon, I rarely give them the answer they wanted. Typically, they are hoping that this process will solve their C-suite’s desire to combine budgeting and planning, as they hear it works at Amazon. But this is why it is nearly always wrong to assume that a process that works with one culture can just be dropped into another and have the same success; it can’t. The reality is Amazon’s OP1/2 process allowed for massive, unaccounted for overhiring that then led to over 30,000 people laid off. Why do we uphold this process as a model to copy still? 🤷♂️
Amazon’s process – like others – falls prey to the first of the games that get created by combining budgeting and planning, detailed below.
Game #1: Empire Expansion
The output of a combined budgeting and planning process is increased organizational size, which leads to managerial promotions through increased scope. In other words, the combined budgeting and planning game is directly tied to managers’ financial incentives, which means that this game will always be played.2 While I had an entire writeup to detail this game, I found it has already been described online:
The game worked as follows: The objective was for each manager to build the largest organization possible and thereby expand the importance of his function. Through the transitive property of status, he could increase his own importance as well. Now you may be thinking, “That wouldn’t happen in my company. Most of my staff would never play that game.” Well, that’s the beauty of the game. It only takes one player to opt in, because once someone starts playing, everybody is going in — and they are going in hard.
Ben Horowitz in How to Ruin Your Company with One Bad Process
My personal experience has seen this game being played every time, meaning that the larger an organization grows, the more leadership has to work to weed through all of the forecasts and make decisions. This, however, is hard as forecasting is often inaccurate, and leaders of large organizations may not have the detailed knowledge to know when to trust a forecast or not. In other words, this game both encourages organizational growth and scales linearly with organizational size, making it an inefficient game by design.
Let’s take an example. Imagine team A says that new feature A’ will result in $10 million of additional revenue, but will require 10 additional employees to complete next year. Meanwhile, team B says feature B’ will result in $1 million of additional revenue and will require 1 additional employee next year. Do we have enough information to decide between the two? Absolutely not. Do we trust team A and team B equally? More importantly, is one of the features riskier than the other? Usually the larger changes are, but the reward can often be higher. How about the forecasts? How much weight should be put into these numbers; do we believe them? Now imagine doing this not for two teams, but 200 teams, 2,000 teams, or more. You can see how no individual can possibly have all of the information to choose across these, and this is the simple case of comparing apples to apples. Now imagine comparing net-new revenue to existing feature improvement to reducing technical operational load to increased security to increased reliability to increased performance – OK, you get the point. The reality is these comparisons are often not apples to apples, and the choice of options becomes even harder.
But this is why layers of management exists, Straker. No one person has to make all of these decisions. Except somebody does, as there isn’t infinite money to be spent. Decisions across teams and organizations have to be made, and these decisions will break organizational hierarchy at scale. Yes, management should help filter the decisions from the team-level to the organizational-level, and yes, this can work well at smaller companies, but this bottoms-up process is an expensive, slow way to inform these decisions. Additionally, it codifies Conway’s Law by design.
Game #2: Ignore Learning and Execute on the Plan
The other game that can be created by combing budgeting and planning is a plan that is incentivized to be executed against no matter what. For example, imagine teams’ being graded on how well they executed against their plan as an input to future sessions to see if a team should continue to be funded as-is, grow, or shrink. Note that this game is not mutually exclusive with the first one; both can be true at the same time. When I went to describe this game myself in detail, again I found I was beaten to the punch:
Every year, we go into a yearly planning cycle. The management of the organization asks all the VPs what they plan to deliver. They have the product managers write business cases, which they choose to fund. Those business cases are based off very little data, and they have some wild estimates on them. They turn all these business cases into a giant roadmap for the year, give them out to each team, and fund the projects. At the end of the year, if they do not deliver what’s on the roadmap, they do not get as much funding the next year.
Melissa Peri in Escaping the Build Trap
This game simply forces the Waterfall model on teams, even if they learn early on that the plan should evolve. I already blogged about the issues of the Waterfall model for software teams plenty in Please, Stop Quarterly Planning: it’s Just Waterfall in Disguise, so I don’t need to repeat myself here; go checkout that post if desired. For a real-world example, in the book, Melissa goes into further detail about her experience with Kodak and how they refused to evolve quickly after the emergence of the iphone. This game was a major reason why – they could not evolve their plan until the next annual cycle 😖.
So…what should we do instead?
My advice should come as no surprise: stop coupling your planning and budgeting. Instead, first create a strategy to work backwards from.3 Then, you can follow a flexible/continuous planning process to execute against the strategy. Keep your budgeting a completely separate exercise that uses both the strategy and continuous planning process as inputs.
The reality is forecasts are estimates. Even the best ones I have seen are far from accurate, and it’s why my favorite post about forecasting recommends the Fermi Solution. Detailed product plans 6-12 months out give false precision as an input to forecasting, and thus are better to be avoided altogether. Forecasts simply a guess into the future, which is why it makes sense to keep them simple and lightweight at first. From server capacity requirements to headcount requirements across functions such as marketing, design, engineering, sales, operations, and others, there is too much room for error that stacks on top of itself to do a bottoms-up forecast.4
For example, if your strategy involves growing the company through a new product line, your financial forecast can take both the increased spend and revenue forecast of this new product line into account. The initial effort for this does not need to be pushed down to every individual team, but can be done at the strategic level. Then, as the new product line becomes more defined, and actuals can replace estimates, you can iterate on it through communication at the plan level. In summary, the further out the new product line is from launching, the less the continuous planning process is used as an input to the forecasts, and the more the strategy is used.
Appendix: Good External Resources
These are other relevant articles I found after writing this post. I will update this in the future as I find more, so you may notice this change:
- How Companies Incentivize Layoffs – This ScarletInk post talks about how manager promotions are directly tied to organizational size which eventually leads to layoffs from the overhiring it leads to.
Footnotes
- Admittedly, I have not verified how this process has evolved since I left Amazon in 2017, but the layoffs mentioned happen in just the past year. ↩︎
- I have alluded in past posts that I disagree with any system that rewards organizational scope over impact, but that is a discussion for another post. ↩︎
- I don’t have a reference post for a vision to precede a strategy, but if needed, have a vision first for the strategy to work backwards from; perhaps I’ll make a future post and add this step. ↩︎
- I recall anecdotes of capacity forecasting back in my Amazon days when I ran Retail Website Availability. If you asked every team the capacity they needed for an upcoming peak day (Prime Day, Black Friday, Cyber Monday, etc) they would ask for more capacity than were possible to produce before the peak day and would cause massive operating loss given the spend of said capacity. Supply chain issues are important to consider as well, such as the hard drive shortage in 2017. ↩︎
1 Comment
Leave your reply.