Could vs. Should: The First Year Managing an SRE Team

As of today, I’ve drafted this post upwards of 10 times – it’s old enough that the version I first started working on was called “Reflections on 1 Year of SRE Management” (I’m currently at 2.5 years). But everything I learned during that first year became critical for the next. I had been thinking about the fact that Site Reliability Engineering (SRE) teams and engineering management roles have one important thing in common: there are many things you could do, but only some are things you should do, and it’s hard to define which is which. Both roles require tons of context (which I love) and tons of ambiguity (which I also love), with the occasional high-pressure situation to make things interesting.

Now, I manage a second team along with the first: the one behind Honeycomb Private Cloud. The experience I gained in my first year was critical for being ready to face the challenge of managing two teams. In this post, I talk about what I learned in that first year, what I got wrong (and right), and what I wish I’d known when I started.

Jumping in the deep end

My first week as engineering manager for SRE was during an engineering team offsite at KubeCon. It was half conference, half team building and roadmapping, and I was terrified. “I have to sit in a whole room of people and figure out how to entertain them for several hours? And it has to be productive?!” After several years of being fully remote, I feared there was no way it wouldn’t be a disaster.

It went fine. Everyone was exhausted from KubeCon (we all resolved to never do a conference and then an offsite again). And with some prodding from my manager, I kept it simple: got people talking with basic agenda items, brought stickies and pens, and wrote it all down. Our roadmap of ideas was so long I had to walk across the table to get a picture of it all.

(A year later, we looked back at the list, and it turned out we worked on all these things—in roughly that order—and had completed most of them. I hope to harness that universe energy again someday.)

The rest of the year was a pressure cooker of learning. I was desperately trying to:

• Understand what the org expected of us, and what the team expected to be doing
• Build trust with my team and boss
• Acquire basic management skills (e.g., coaching, facilitating, etc.)
• Acquire advanced management skills (e.g., change management, strategic thinking, etc.)
• Learn what my manager expected of me
• Learn what the word “manager” even meant. As much as I appreciate apophatic theology, we can do better than negative definitions like “managers do everything but write code.” Also: very not true in 2026. 🙃

At the end of the first year, I had gone from “I’m ready for this; throw me in the deep end” to “Oh god, I’m in the deep end” to “Oh boy, I’m in the deep end!” But it wasn’t without problems.

Missteps, and things that helped

I ran a lot of bad meetings. Or, at least ones that I would beat myself up about; ones where there was low participation, or awkwardly long non-productive silences. From the team’s perspective, they were just “meh,” but I wanted to do better. I found that the more I tried to engineer the perfect thing to say or design the perfect exercise, the less people wanted to participate. I learned to work backwards from the goal of the meeting (Buy-in? Agreement? Technical design? Information? Reflection?), start with the lightest possible process that allows for full participation, and make sure the next steps are clear.

I held on to feedback for too long. It would either get old enough that it was awkward at best to bring up, or the situation would repeat, which was not ideal. I focused on lowering my own bar for bringing feedback via lots of trust-building. I don’t want there to be any friction in feedback given to me, or from me to others! An exercise that helped with this was forcing everyone, at least once, to give me constructive feedback (either about me or about team processes) in a 1:1 setting. I let people take time to think about it, but I didn’t let anyone off the hook and I kept it as a recurring agenda item until they gave me at least one thing that could be better (this might have helped my own comfort more than it helped theirs, but was still a valuable exercise in trust).

I stopped weighing in on technical decisions. There are plenty of former-engineers/now-managers who get caught in the trap of trying to create the same type of value they used to, but I swung the pendulum a bit too far. I would completely recuse myself, despite having 8+ years of direct experience in this field, from technical decisions. In some way, this was great for learning how to facilitate and build team ownership. However, it did the opposite for our outcomes: some projects hit roadblocks I could have pointed out, and some decisions were ambiguous. I learned to use context to decide whether to make a call: unilaterally, recommending a direction, sharing advice, or staying quiet. If I was worried about biasing the team, I would state exactly what I was doing and why so we could directly talk about the reasoning, rather than have the invisible weight of the manager’s opinion hanging in the room.

But overall, the thing I tried hardest to do and that helped me the most was to seek out feedback in all forms, and to read a lot. If you’re not paying attention to the results of your actions and reflecting on them, you will not grow as a manager.

The next year

The second year brought lots of challenges, including a sudden staff engineer departure, massive contract negotiations (with fun internal negotiations too!), and some interesting parts of managing an SRE team specifically. In my next post or two, we’ll catch up to today, covering the rapid strategic shifts to AI and what I learned from managing two teams.

In the meantime, here is my advice for managers who may be in their first year or who are building their managerial base:

• Build relationships with your peers and your team, as strong and high-trust as possible. Your role will become impossible without this.
• Ask for feedback, and find it in things that don’t look like feedback.
• Ask three people what they see your role as, and what they think your team does: your boss, their boss, and your reports.
• Ask people for book recommendations, and read them.

And most importantly: ask questions far more than you give orders.