There’s a particular kind of feedback that’s easy to keep deferring — and the deferral is so reasonable-looking that you can go a long time without naming it for what it is. It’s not feedback to struggling employees — those conversations, while hard, have an urgency to them that makes them easier to actually have. It’s feedback to strong performers. The people who are delivering, who you like working with, who you’d fight to keep on your team. ...
I lead the org that builds pricing systems for EC2 at AWS. So I’ve thought about this a lot — and I can tell you that the engineering leaders who struggle most with cloud costs are almost never struggling because of a technical problem. They’re struggling because of a cultural one. Here’s the pattern I see repeatedly: cloud spend grows faster than expected, finance sends an alert, leadership schedules a meeting, someone produces a spreadsheet showing which teams are spending what, and then there’s a conversation about “rightsizing” and “optimization” that produces a short-term reduction and almost no lasting change. Three quarters later, the same meeting happens again. ...
A few years ago, one of my senior engineers — someone I genuinely considered one of the strongest technical contributors on my team — was consistently getting passed over in calibration. Peers rated him lower than I expected. His stakeholders were lukewarm. I was confused, and honestly a little defensive on his behalf. Then I read the feedback closely and saw a clear pattern: in design reviews, he interrupted people. He’d finish their sentences — usually incorrectly — then pivot to his own take without pausing to absorb what the other person had actually been saying. He thought he was being efficient. He had no idea how it landed on the other side of the table. ...
It was a Tuesday morning in Plano, Texas — eight o’clock, already pushing ninety degrees, the kind of summer day that makes clear it has no interest in easing you in. One of the engineering managers on my team stormed into my office before I’d made a dent in my first coffee. He was furious — a VP had dropped a new feature onto our upcoming launch two weeks before go-live. No consult, no heads-up, just a scope addition that landed on the team like a boulder. The work was real; the timeline was not. He’d already done the math, already stress-tested the estimate with his tech leads, and he’d come to me with the full picture — ready to hand the grenade to someone with more standing to push back. ...
When I joined AWS to lead the EC2 Pricing Engineering team, there were eight engineers. Two years later, there were fifty-plus. That growth sounds clean on a slide deck. Living through it was something else. You don’t move linearly through the Tuckman stages — you loop back through all of them every time you hire a new cohort, every time a reorg reshuffles the team, every time a leadership change sends people back to square one. I’ve lived this cycle more times than I can count. Here’s what each stage actually looked like from inside it. ...