Senior Technical Program Manager; SW​/FW AWS Hardware Engineering

Every server in an AWS data center runs firmware, and someone has to decide how a new version of it safely reaches millions of machines. That is this role: you will own how firmware ships across the AWS server fleet, and you will design the mechanisms that make it predictable and safe at that scale.

We build the software that lives closest to the hardware, including BMC, BIOS, and the controllers that manage power, cooling, sensors, and health on every server and rack we deploy. Writing that firmware is only half the problem. Getting a new version onto millions of machines, in the right order, at the right time, without disrupting a single customer, is the other half.

That half is yours.

Your real product is the mechanisms. You will design the repeatable machinery that gets every release to the finish line without heroics: a release calendar the whole organization plans against, quality gates with clear criteria a build must clear before it goes anywhere near production, a staged rollout model that limits exposure if something goes wrong, and one shared view of where every release stands so nobody has to ask.

You will define how teams hand off to each other, how a blocker gets escalated and by when, and how we know a rollout is actually healthy rather than just finished.

You will get to decide what good looks like here, then make it stick. That means finding the places where coordination happens by memory or by meeting and replacing them with something documented, measured, and ideally automated. It means using every release and every operational surprise as evidence, turning what you learn into a permanent change to the process or the tooling instead of a one-time fix.

And it means holding a high bar with engineering teams who do not report to you, which you will earn through being right and being useful rather than through org chart authority.

• You will work where software meets physical hardware. A bad firmware rollout does not just throw an error, it can take a machine offline, so the bar for getting it right is unusually high.
• Your scope is the whole fleet. Decisions you make about release process apply to millions of servers across every AWS region.
• You are building the mechanisms, not inheriting them. There is real room to design how this works rather than administer someone else's process.
• You will get deep in the technology. This is a hands‑on technical role with engineers, not a status‑reporting role.

You will spend time with the firmware engineering teams, going deep on what is in the next release, what changed, what worries them, and whether it is ready to move to the next stage. These are technical conversations, not status checks, and you will be expected to hold your own in them.

You will spend time on releases already in flight. That means looking at how a staged rollout is progressing, deciding whether the data supports widening it, and pulling the handle to pause or roll back when it does not. When something fails qualification or a manufacturing partner reports a problem, you are the person who gets the right people on it and keeps it moving until it is closed.

You will spend time building. Writing down a gate that only existed in people's heads, replacing a manual status roll‑up with something automated, tightening a handoff between two teams that keeps slipping, updating the release schedule as reality changes.

And you will spend time communicating. Giving leadership a clear read on where releases stand and what the risks are, aligning teams whose priorities are in tension, and making the case for a decision that not everyone will initially agree with.

• Own…