Near the end of each year, AWS swamps customers with a veritable tidal wave of cloud service announcements.
For a while now, I’ve said AWS would do well to take a look at a calendar and realize that there are 49 other weeks in the year besides the three weeks leading up to and including re:Invent. With this new discovery, I’ve said, the cloud provider could do us all a favor and disperse its hundreds of annual service releases across the calendar.
I now know that this belief was wrong.
Here’s why I was wrong about changing AWS’s product release cadence
It doesn’t happen super frequently, but there are times that I completely reverse a position I previously held. This seems to be one of those times, although it’s nuanced. Onward!
What I’ve wished for — a steady drumbeat of releases on a weekly or monthly cadence, rather than a torrent of them at re:Invent — is superior to the status quo from the customer perspective, and it’s why I’ve maintained this position for a while. The challenge is that changing the release cadence would fundamentally break AWS culture.
How to build a cloud platform worth making
Despite Amazon’s vaunted value of customer obsession, it’s the wrong lens to use to view product release cadences.
Something that Tony Fadell talks about in his recent (and excellent!) book Build: An Unorthodox Guide to Making Things Worth Making is the idea of companies having heartbeats, both internal and external. He alludes to Apple’s heartbeat historically being driven around the annual MacWorld conference. Over time, it expanded to include WWDC, the iPhone event, and on. But at its core, one big event drove the cadence of the company. Fadell contrasts this with Google, whose heartbeat he describes as “erratic” and “unpredictable.” He states that Google as an entity has one big external event each year: Google I/O (because Google Cloud Next continues to get in its own way). However, there isn’t a clear heartbeat present, because Google teams are by and large not synced up with that event in any meaningful way.
Fadell doesn’t describe Amazon’s heartbeat, but it was impossible for me not to extrapolate, because I have AWS in the place where most people have hobbies. Having spent years as an AWS observer, it’s clear to me that the two big events that drive its product release cadences are re:Invent (which I trust needs no explanation to this audience) and OP1 (which probably does).
Details around OP1 are hard to come by externally; the term is bandied about by Amazonians who presume the listener, reader, or Twitter shitposter has a cultural understanding of what it is and means.
OP1, or Operating Plan 1, is a mandatory six pager produced by every team’s product manager around June, and it encourages large-scale planning. One key question is “What resources do you need to grow your business by 10x?” It should be noted that there’s also an OP2 in late December that appears to take more of the form “You survived re:Invent, now tell us how your achievements track against your OP1 doc.”
AWS culture has been driven by this corporate ebb and flow for so long that it’s impossible to predict what second- and third-order effects would result from a whiplash policy change to “Release whatever you want, whenever you want — have fun!” It would disrupt performance review cycles, the migration of talent between service teams, and budgetary planning processes, just off the top of my head.
re:Invent and OP1 are more than counterbalanced dates on a calendar; they’re the underlying bedrock that supports a mind-boggling amount of Amazonian culture. Cast whatever stones you (and, more importantly, I) would like, but AWS has been a massive success for Amazon. Asking AWS to throw away the culture that empowered all of that is no small thing. If the cost of maintaining that culture is that customers feel overwhelmed once a year when service releases start hitting hard and fast, then that’s a price Amazon is more than willing to pay — because they’ve been paying it all along. In the long run, maintaining its culture better serves AWS’s customers.
But is AWS’s cadence correct?
It’s easy to imagine alternate cadences. What if it were an 18-month cycle, or a 12-month cycle, or a two-week sprint? It’s pretty clear that this cadence predates Amazon having to give a Flying Wallenda about its stock price, so I don’t believe it’s tied to external market pressures. I have to trust that however the current cadence was derived, it didn’t come from pulling a number out of a bag.
And let’s be very clear here: There are exceptions to this once-a-year release cadence all over the place! If there weren’t, most issues of Last Week in AWS would be less of “a couple of thousand words” and more of “a gif of a tumbleweed.” Throughout the year, there are occasional service launches, constant enhancements and expansions to existing services, and quality of life improvements to virtually every service in ways that, from the outside, don’t appear to bear any relation to the cadences I’ve just described.
AWS’s calendar works for its culture
This is all highly speculative on my part. But it’s pretty clear that, to date, AWS has been outperforming Google Cloud and Azure. Depending upon whom you ask and the context in which you ask it, the reasons behind that success include Customer Obsession, Frugality, API-based communication between teams, Jeff Bezos leasing his soul to the devil, the two-pizza team culture, and many, many more.
I think that the awareness and institution of AWS’s internal cadences is certainly a strong candidate for — if not the root cause of — its success. It’s certainly a serious enough contender that I’m highly reluctant to casually toss out the idea of deviating from the re:Invent release dump as I have previously.
But just because this uniting cadence is working for AWS, it might not work for you. It’s easy to look at any given aspect of a company and adopt it without understanding the larger context. We see this constantly when big companies envy startups’ ability to deliver incredibly quickly and start adopting the visible cultural elements without a nuanced understanding of their place in the larger tapestry. “Well, we switched to an open plan office, put some bikes in the entryway, and tossed some dogs into the office. When does the transformation happen?”
We need the fruits of AWS’s culture, so we’ll accept its product release cadence
Amazon prides itself on being misunderstood for long periods of time, whereas I pride myself on seeing through Amazonian talking points — enough that I foolishly believed that I was somehow immune to misunderstanding the company. This was a mistake. (There’s no harm in making those, but it says nothing good when you realize you’ve made a mistake and continue to forge ahead down a path you know to be wrong.)
So here it is: As annoying as it might be for customers to have to deal with the tidal wave of announcements, I’d argue it’s the lesser evil when compared to the cost of breaking the cultural engine that drives the AWS platform.
