Andy Jassy’s keynote at AWS re:Invent sets the tone for the upcoming year for AWS. With AWS re:Invent now wrapped up, what course was set?
Any keynote delivered by the CEO at Amazon Web Services is bound to have an impact not only on the company and its customers but the cloud as a whole. For the 9th time, Mr. Jassy took the stage to kick off the conference and delivered an update on the business, new services, exciting features, and some interesting customer stories.
This keynote set the tone not only for AWS re:Invent (which just wrapped up its 2nd part) but how AWS will approach 2021.
You should also take a few minutes to read Forrest Brazeal’s excellent analysis of the keynote, “5 takeaways from Andy Jassy’s big re:Invent keynote”
How is AWS doing?
In a word? Great.
There were 27 different launches just in Andy Jassy’s keynote today. Alongside the expected update for the overall AWS business — crushing it with over 45% of the market — the keynote was much like you would expect based on previous years.
Yes, there were some very cool launches today and if you want read more about that aspect of the keynote, I highly recommend Forrest Brazeal’s excellent keynote analysis, “5 takeaways from Andy Jassy’s big re:Invent keynote.”
I much preferred the thematic aspect of the keynote. This year, Andy’s keynote theme was “reinvent”. Ironic or not, it called out one of the biggest challenges facing teams as they move to deeper into the cloud; themselves.
The environment we build in
The theme was first raised as seven distinct points;
- The leadership will to invent and reinvent
- Acknowledgment that you can’t fight gravity
- Talent that’s hungry to invent
- Solving real customer problems with builders
- Don’t “complexify”
- Use the platform with the broadest and deepest set of tools
Of course the last one is a bit self serving, but when your business is already at $46B/year and growing at 29% YoY (00:04:28), you’re allowed to toot your own horn a bit.
Imagine for a moment a completely new team. One that has basically unlimited resources and the knowledge to get the most out of the cloud. The ideal workflow for that team aligns with the AWS Well-Architected Framework.
The team works in small iterations. They have an idea, test it, learn from those tests, and improve the idea.
Everything is automated using on-demand resources. They regularly practice operational scenarios. They are constantly evolving their architecture based on customer needs and availability of better tooling in the cloud.
This team is lean and efficient. They are customer obsessed. Their work is almost entirely directly tied to customer value.
That team sounds amazing. Odds are, you are not on this team.
Reality crashes in
IT delivery today is very, very messy. A lot of it is done to get something else in place in order to actually start building what your customers really want.
No one stands up a server just because. It’s there to allow you to build something on top of it. Multiply that a few times and you’ve got a crazy amount of IT infrastructure in place just to get to the point where you can deliver value to your customers.
But this is the way. Or at least it has been the way for a few decades. It’s worked. Sort of.
The true problem is that organizations and careers have been built around this setup. Entire teams are hired to run operating systems or your network routing or your perimeter security controls. These teams are made up of people and people tend to be slow in changing their ways.
This is where the first point, “The leadership will to invent and reinvent”, comes into play.
Having a leadership team that sets the tone that nothing is “done”, that nothing should remain stagnant sets the expectation throughout the organization that your current work tasks are not you. This goes hand in hand with a culture that values learning and I wish that was called out in the keynote as well.
If a team self-identifies as the “networking team”, they will frame all of their work through that lens. The understandable goal for them is to get their network to a point where it’s in an ideal state.
The problem is that “ideal state” is a fallacy. Organizations are dynamic and their needs are constantly changing. That network is just a temporary implementation detail. What is there today might not meet the needs of tomorrow.
When leadership sets the tone for constant change and innovation, teams don’t settle in as easily.
The second point, “you can’t fight gravity” is really just acknowledging that you don’t work in a void. Customer needs and desires changes.
During the keynote, Andy cited examples Netflix as an example. They started as a DVD rental company. Unlike some others, they quickly saw the writing on the wall and decided to act before it was too late.
As Andy said, innovation and invention should happen when a company is healthy, not desperate.
Far too many companies are locked by inertia — not having implemented the first point — and can’t shift course…even when everyone accepts that things have changed. This has long been a challenge and only becomes more complicated as time passes.
Build fast, build smart
The next points all go hand-in-hand and they all address how teams need to build today. This is fundamentally different than we built even ten years ago.
The main reason? We’ve built better tools for ourselves, the cloud prime among those improvements.
No longer do we really have to worry about significant up front entry costs, capacity limits, or start up times. We have more power available via one API call than an entire data center from ten years ago.
But if you don’t change how you approach using these tools, you won’t see the advantage of them. And that’s the key takeaway from today’s keynote.
Teams need to understand that their goal is to deliver the desired business outcome with the least amount of operational burden possible. Automate everything. Use as many managed services as possible.
AWS has proven time and time again that their services will improve constantly. Teams needs to stop searching for perfect and be ok with “good enough for now” …as long as that solution has a low operational burden.
Why the focus on operational overhead? Because you and your team want to avoid being held back by keeping the lights on. If you’re working on keeping things running, you’re not improving the system. You’re not responding to customer needs.
Tied directly to this push is the idea of speed and simplicity. Complexity encourages technical debt. Complexity encourages stagnation. Complexity restricts innovation.
Solving the business problem with the simplest possible solution is hard.
Not only is it hard to find that simple, elegant solution. It’s also hard to resist that innate builder tendency of just adding that one extra bit for additional flexibility. “If we just…” has doomed more than one team to a life under a mountain of technical debt.
Why are you building?
This was the biggest takeaway for me today. Builders still struggle with updating their approach to solving problems. That struggle is typically due to organizational and team pressure.
It’s a hard problem to solve because it requires a lot of people to be on the same page and to stay on that page for a long time. But that journey starts with the first step…a desire to build better.
What did you think of the keynote? Let me know on Twitter where I’m @marknca
When the keynote was original broadcast on 01-Dec-2020, I live tweeted the entire thing. If you want to see the play-by-play, check out the thread below…