Field Notes from the Stack: Remembering Your Roots

Week ending October 3, 2026

Teams are always busy. For some teams, it's shipping features, for others it's keeping the lights on. There's rarely a week where a team could say they have time to spare. In my years in engineering perhaps the only position I held that had downtime was when I worked in a NOC. This week was no different for my team. With high-priority customer requests, strategic projects, and an incident or two we were swamped. Then there are those requests that are just toil or grunt work.

This week, that meant dealing with lingering Airflow upgrades in our federal environment. The work had stalled for several months, first as a goal for the owning team and then over differing expectations about what assistance from my team would involve. The upgrades still needed to happen, and the question became: could the federal team take them on?

Well yes, but then my team isn't working on the strategic projects, such as our efforts to build out a FedRAMP Class D environment. The work was necessary, but it was so repetitive. It needed careful execution and production judgment more than it needed the full attention of an engineer for a week.

I admit, I'm not as far out of being an individual contributor as my peers or others in the industry, but I don't spend much of my time doing engineering work. I'm relied on by my team for support that comes with my role, such as protecting their time and keeping them unblocked. Automation and AI-assisted analysis made it practical for me to handle that repetitive work in smaller blocks of time.

Now, I don’t think an EM picking up work for the team is the default answer to a capacity problem. Here, though, the task was bounded, the failure patterns were repetitive, and I had enough context to make progress without pulling an engineer away from a larger commitment.

So, I sat down and did the work to unblock several dozen Airflow upgrades in the federal environment. Most of these failed with similar patterns, but being a production system, it wasn't safe enough to blindly automate.

In between meetings, I'd run a baseline script to start the infrastructure build, debug deploy pipelines, and leveraging Claude's thinking to provide some initial analysis on whether the failure modes matched known patterns with documented fixes. By Friday, most deployments were complete, with a small number of exceptions still requiring follow-up.

Anyone I've led, either as a people manager or IC has heard me say "I'm here for you." That has to mean something in practice. This week, it meant using my experience as an IC to finish work without asking the team to absorb another competing priority. That's not always the right answer, but understanding when it is can make a big impact on a team's health and state of mind.