mibus.org
Sydney Staff SRE or something.

Path to Staff SRE...

· by Robert Mibus · Read in about 3 min · (460 Words)
sre career communication

I recently got promoted to Staff SRE, and ended up in a conversation about the path my career took to get here.

The path I would have described a few years ago seems pretty simple:

  • Part-time local school
  • Part-time friend’s startup
  • Full-time friend’s startup
  • Full-time in a larger (400-500 person) company
  • Full-time in a larger-again company (~2500)
  • Full-time in a FAANG

Or maybe I would have described my roles:

  • Individual Contributor
  • Tech Lead
  • Manager

But that’s not really how I think of the path any more; I think of it with inflection points reflecting my personal growth:

  • Getting paid for doing random stuff
  • Learning that it matters which stuff
  • Learning that mistakes should only be made once
  • Learning that managers are there as leverage I can use to achieve my goals, not just vice-versa
  • Learning that technology doesn’t matter, getting things accomplished does.

That last one in particular, is a lesson that took me a long time to really learn in a meaningful way, and it’s had huge (positive!) repurcussions ever since. I say “meaningful” because it’s easy to say “yes I understand this” without actually taking it on fully and trying to bring that to your day.

What does this have to do with being a Staff SRE? Nothing, and everything. Unless you’re a far more accomplished and talented engineer than I am, it’s very likely that a path to Staff means a lot of collaboration, a lot of wrangling of requirements, a lot of analysis, a lot of imperfect decisions that need to be made. Prior to having focus on outcomes, I would be a lot more likely to get caught up trying to polish something that didn’t need polish, gain consensus when I only needed consent, or caring too much about a technical implementation rather than being pragmatic due to the overall needs of the project.

It seems so obvious in hindsight, but considering “getting things accomplished” as my goal has really shifted the way I approach work (especially when starting out a project). Don’t tell me what you want me to do, tell me what problem you’re solving. Tell me who else has similar problems, and I’ll talk to them about how they solved it. Tell me what concerns you have. Tell me how often you want to hear progress, and what level. Tell me what progress even means to you - if we don’t deliver everything, what would still make the project valuable for partial delivery?

OK, this was a bit of an off-the-cuff ramble… What should you take away from this?

  • Focus on outcomes. Technology is not the hard part of our job.
  • Focus on communication. You’ll never succeed beyond yourself, without listening to others’ needs, and explaining yours.
  • Focus on understanding what’s needed.