Designing Infrastructure for Bounded Autonomy Introduction A production access request during an incident looks straightforward from far enough away. An identity system can grant a role, a privileged access system can time-limit it, and an audit system can record what happened. The hard part is deciding whether the request should be granted at all. That decision draws on the state of the incident and who owns the service. The reviewer may also need to check the requester’s device, the sensitivity of the data, recent access, and any current exceptions. In many organizations, those signals live in separate systems with different owners and failure modes. The person reviewing the request has to join them together. ...

I was working on a design doc recently with the help of AI when it generated a sentence that immediately made me stop. It described another team’s system as “legacy infrastructure that should be replaced.” That might sound like a small wording issue, but it was not. The system was not legacy. The team had invested heavily in it, it solved real operational problems, and replacing it was neither realistic nor necessary. The broader proposal was moving in a reasonable direction, and AI was genuinely helping me get to a better version of the idea faster. ...

The more I look at how we actually build systems now, the more it looks like Terraform is dead. Not “declining.” Not “evolving.” Dead. What’s left is just inertia. What Terraform Actually Solved Terraform solved a very specific problem: how do we make infrastructure deterministic, reviewable, and repeatable? The answer was a DSL, a plan step, and a state file. It worked, and it still works. But it also forced an awkward compromise. Humans ended up describing intent in a language that was never designed to express it, and HCL is not how anyone actually thinks about systems. ...

This is the final post in the series expanding on my talk about the path to Staff Engineer and beyond. The series began by challenging management as the only path forward, then moved from problem solving to problem finding. Part 3 covered the value of messy, political work, and Part 4 looked at leading before you’re given the title. This last part is about the space in between being a strong Senior engineer and actually operating at Staff level. ...

This is the fourth post in a series exploring the path from senior engineer to Staff engineer. If you missed the earlier parts, you can find them here: The Path to Staff Engineer, Part 1: Breaking the Glass Ceiling The Path to Staff Engineer, Part 2: From Problem Solver to Problem Finder The Path to Staff Engineer, Part 3: Turning Messy Work Into Staff Level Impact The Path to Staff Engineer, Part 4: Learning to Be a Leader The Path to Staff Engineer, Part 5: The Transition Trap A lot of the Staff conversation focuses on technical scope. Bigger systems, harder problems, more ambiguity, more cross team work. All true. ...

I was having a drink with a friend last weekend and the topic turned to AI - particularly about why so much AI-generated code is just slop. Does it work? Sure (well, most of the time). But it’s hard to understand, hard to maintain, and often not written in a way that’s easy to test. You take one look at it and know you’re going to be paying for it later. ...

This is the third post in a series exploring the path from senior engineer to Staff engineer. Check out the rest of this series: The Path to Staff Engineer, Part 1: Breaking the Glass Ceiling The Path to Staff Engineer, Part 2: From Problem Solver to Problem Finder The Path to Staff Engineer, Part 3: Turning Messy Work Into Staff Level Impact The Path to Staff Engineer, Part 4: Learning to Be a Leader The Path to Staff Engineer, Part 5: The Transition Trap One of the clearest ways to understand Staff level work is by looking at situations that appear when systems grow, ownership is distributed, and expectations vary across teams. ...

This is the second part in a series expanding on the conference talks I have given this year about the path to Staff Engineer and beyond. Check out the rest of this series: The Path to Staff Engineer, Part 1: Breaking the Glass Ceiling The Path to Staff Engineer, Part 2: From Problem Solver to Problem Finder The Path to Staff Engineer, Part 3: Turning Messy Work Into Staff Level Impact The Path to Staff Engineer, Part 4: Learning to Be a Leader The Path to Staff Engineer, Part 5: The Transition Trap ...

This post is the first in a series expanding on the conference talks I have given this year about the path to Staff Engineer and beyond. These talks have resonated with a lot of people who feel stuck between senior engineering and management, unsure of what comes next. Over the next few posts, I will break down what Staff means, how to grow into it, and how to lead without giving up the craft. ...

It’s been nearly two years since I moved from being an Individual Contributor (IC) to a Tech Lead Manager (TLM) - a hybrid role that combines the responsibilities of a manager with those of a senior engineer. When I was offered the role, I reached out to a few friends at companies that had TLMs. Their advice was nearly unanimous: “It’s a trap.” Clearly, that gave me pause. But also - of course it’s a trap. It’s all the responsibility of a manager and of an individual contributor. ...