My talk "Building Technology Standards at Amazon Scale" from reInvent 2020 is now up on YouTube: It's nominally about how the team chose to use Rust for a new core component of AWS Lambda, but it's really about risk and decision making. Some key points: \\

The Lambda team was faced with the decision of choosing a programming language for a replacement of a core piece of the system: an every-microsecond-counts high-availability stateful load balancer.

At first glance, Rust seems like a perfect fit for this workload. Great performance and memory safety are especially important here.

Why not just choose that then? It's different, and less familiar, and less mature. How do we balance the technical advantages with the organizational disadvantages?

Some organizations make those decisions top-down, but that centralizes risk and potentially reduces innovation. What do we do instead? We encourage engineers to innovate, and leaders focus on providing technical and organizational guard rails.

The talk covers several approaches to do that, but the most important one in my mind is empowering engineers (and everybody) to understand both the technology and the business, and to take long-term ownership of the decision.

That requires having the right incentives. Engineers and leaders should be thinking long-term. Not only whether this is the right decision now, but whether it will still be the right decision in a long time. Incentives are needed to drive long-term thinking.

Finally, when you find something successful, double down on it. This is another key role of leadership: looking for opportunities to invest more in areas of success. We've done that with Rust at Amazon, including building a team around the language itself.

And now taking part in the Rust Foundation: https://aws.amazon.com/blogs/opensource/congratulations-rustaceans-on-the-creation-of-the-rust-foundation/

My role as a leader is to help people innovate by reducing risk and enhancing success. It isn't to write standards, or be the decision maker.