I’m seeing something deeply disturbing about AWS that I didn’t recognize at first until I viewed it through the lens of Google.
This is such a pervasive and impactful problem that I feel compelled to discuss it in terms Amazon themselves would: the Amazon Leadership Principles. I decided to Learn and Be Curious, and what I found led me down a rabbit hole.
At Google, it’s generally accepted that you have to ship something new and exciting if you want to be promoted. Working on existing things means you can’t measure your impact as effectively, and thus the Promotion Czar will be displeased with your lack of impact.
This does much to explain why Google perpetually launches new services, lets them wither, and then kills them in the night. People want to be promoted, and if you want to Hire and Develop the Best, you need to offer a path to get recognition. (And honestly, going from a Systems Manager Assistant Dingus to a Systems Manager Lead Dingus means you can be more Frugal with traditional forms of comp; titles remain both free and untaxed.)
The problem with this is that Ownership often means accepting that you need to maintain something that exists rather than ignoring it entirely in favor of something ever-newer and far shinier.
The “launch a new service” mentality
AWS famously never turns off any services (it’s not in the console and never has been, but SimpleDB is alive and well). The problem that I’m seeing is that AWS is starting to adopt a “launch a new service” mentality for an awful lot of stuff that should be features of other services.
It’s incumbent upon AWS to Deliver Results for its customers. But instead, they’ve chosen to deliver new and often competing services. This has led to massive sprawl, customer confusion, and folks being unnecessarily driven away from the cloud.
Conway’s Law states that organizations ship their culture. And as one apparent example of what I’m talking about, AWS’s culture puts Organizations and Control Tower in two completely separate orgs that apparently aren’t allowed to talk to one another.
At launch, Amazon SageMaker was an easy onramp to machine learning for folks without formal data science training. Today, SageMaker Autopilot, SageMaker Studio, SageMaker Feature Store, SageMaker DataWrangler, SageMaker Ground Truth, SageMaker Notebook, SageMaker Neo, SageMaker RL, SageMaker Marketplace, SageMaker Experiments, SageMaker Debugger, SageMaker Model Monitor, and whatever they’re released between the time I write this and the time I publish it mean that a neophyte is going to pull up the service page, get freaked out, shut their laptop and walk away.
Think Big should apply to data—not how long the documentation table of contents needs to be.
A misalignment with leadership principles
What are their incentives? They’ve clearly turned hard into something that’s at odds with their leadership principles.
I don’t see how having 40 services all named “IoT” is particularly Customer Obsessed. I fail to understand how having a top-level Compute Optimizer service that isn’t part of Cost Explorer is Reinventing and Simplifying a single thing. And as a customer new to the cloud, I shouldn’t have to Dive Deep into three full pages of top-level services.
For a company that believes its team should Be Right a Lot, this is pretty clearly the wrong path—according to customers, analysts, random passersby, and employees with a penchant for honesty. It’s not good for anyone, and I firmly believe that you don’t Earn Trust from your customers by making even the most diligent cloud-watchers feel that the cloud is accelerating away from their ability to understand and contextualize what you’ve built.
I work on AWS billing. If I restrict myself to first-party tools to help my customers, I’ll be using AWS Budgets, the AWS Cost and Usage Reports, AWS Cost Explorer, the AWS Billing section of the dashboard, AWS Trusted Advisor, and the AWS Compute Optimizer.
No two of these things are in the same section of the AWS console, despite all existing for the same purpose. Someone’s version of Bias for Action got twisted into increasing cross-service engagement from the finance side of the house.
I find it hard to accept that nobody inside of AWS has raised this as a point of concern. But whatever the cause, leadership has decided to Disagree and Commit by launching ever-more services—many of which directly compete with one another.
Can you really tell me the differences between SAM, SAR, CodeStar, Proton, Service Catalog, and the Service Catalog AppRegistry? Because without getting deep into minutiae, I can’t.
How is someone supposed to figure out which of these remarkably similar half-dozen services supports their use case?
It really feels to me that the product strategy at AWS has grown increasingly top-heavy, with contradictory and confusing service collisions in an overly crowded console, which represents a clear misalignment between their product strategy and leadership principles.
I like and enjoy using AWS services. But I’m facing increasing doubt that I’m “using the right one” as I go about building things, and I’m sure I’m not the only one.
