Why I Left the Staff Engineer Track

Editor’s note:Jordan Hayes has covered SRE and DevOps for us from the beginning. This is the first time she's written about herself.

I was two performance cycles from principal engineer when I asked to be moved to an engineering management track instead. My skip-level, who was the VP of Infrastructure, told me I was making a mistake. She said: "You are optimizing for the thing you think you want, not the thing you are actually good at." I told her I appreciated the feedback. Then I ignored it.

The decision came out of a specific meeting. It was a quarterly architecture review, and the team had just decided to implement a distributed saga pattern for a use case that didn't require it. The decision was wrong, and I knew it was wrong, but what I noticed in the room was that I wasn't thinking about why the decision was wrong. I was thinking about why the team had made it. What pressures had pushed them there. What information environment had made this feel like the right answer to people who were smart enough to know better. I had found the organizational failure mode more interesting than the technical one. That felt like data.

My first six months as an engineering manager were harder than I expected, in ways I hadn't anticipated. I was not bad at management because I didn't understand the technical problems. I was bad at it because I kept trying to solve things directly instead of creating the conditions for other people to solve them. I would sit in a 1:1 and identify exactly what someone needed to do differently, and then I would explain it to them, and nothing would change. The skill I was missing was not insight. It was patience for the indirect path.

The specific thing I got wrong about management: I thought it was about making better decisions than the engineers. It is actually about making engineers capable of making better decisions than you. Those are completely different jobs. The first requires being right. The second requires knowing how to be wrong usefully, in a way that doesn't poison the environment. I had spent eight years optimizing to be right. Being right was no longer the primary skill.

My skip-level was probably right, but not in the way she meant. She was right that I was good at technical work in a way that would have made me a strong principal. She was probably right that I would have been promoted. What she didn't say, maybe couldn't say, was that I would have been a technically excellent principal engineer who was chronically frustrated by the organizational layer she couldn't control. I had already been frustrated by it as a staff engineer. More seniority would have given me more visibility into the problem without giving me more tools to fix it.

I have been a manager for three years now. I am better at it than I would have been as a principal. I know this because I occasionally work with principals, and I recognize the specific flavor of friction I would have had with the role. I also miss writing code in a way that has not gone away, not as nostalgia exactly, but as a feeling of being slightly outside the thing I am most interested in. My skip-level was right that I was optimizing for the wrong thing. She was wrong about which wrong thing. I was not optimizing for the title. I was optimizing for proximity to decisions that are made in rooms I now sit in. Whether that was worth the tradeoff is a question I am still not done answering.

My skip-level said: you are optimizing for the thing you think you want, not the thing you are actually good at. I did not know she was right for another eighteen months.