What’s the most frequent advice I give?

Read “Crucial Conversations”… regularly.

Crucial Conversations is literally my #1 book recommendation, and has been so for most of a decade now.

It’s just so useful at helping understand where discussions can go astray, and gives you great ways to think about how to approach them to bring them back on track.

“Debugging Teams” is also on my list.

Have a career plan - the easy way

What are your life goals? Values? Simplicity? Money? Prestige?

Your “life plan” informs your career plan. You can’t know what you “should” think of for your career, without knowing what’s important to your life.

What is the direction of your career? Not the next step, but just vaguely gesture.

Accept it might not be a linear path!

Talk more to people

Enquire. Listen. Reach out proactively, even if you think you’re “wasting their time”.

Build and maintain connections that aren’t immediately valuable. Sometimes they’re valuable later - and sometimes they just turn out to be great people to have fun conversations with :)

Tech is a means to an end

I’ve worked with some truly amazing engineers. Several who can code circles around me, while blindfolded and with both hands tied behind their back.

But the work you can create yourself, is still much more limited. Working with others, leading, helping, directing, advising - that’s how you have more impact.

Sometimes it doesn’t feel as fun. I got into computers because staring at a hex editor for hours a day, solving problems, that stuff is great fun.

But “people don’t stare at hex editors enough” probably isn’t what your business considers a problem. It’s “we worry about system reliability”, or “our IT costs are too high”. Solve the business’s problems; have fun but do it along the way.

SRE isn’t about improving reliability

Slightly more controversial; I think that SRE’s job is not to improve reliability. 100% reliability isn’t the goal (I believe this is even covered in the SRE Book from Google). So, what is the goal? Confidence.

SRE’s job is to build confidence that the risks - particularly in the areas of reliability and data stewardship - are known and managed to a level that makes sense for the business.

Take a step back

It’s almost always valuable to take a step back and ask the meta-question around the work you’re doing.

You’re struggling to get a patch written, because some technical aspect is very difficult. What do you do - dig into the code further, escalate to an expert, or something else? Maybe instead you should first re-evaluate what problem this patch was intended to solve - now that you’ve learned that it’s difficult, does that change what your preferred choice is for solving the problem?

You’ve been told to look at a new service. Should you look at the outages, adherence to best practices, toil required… or is that the wrong question? Why were you told to look? What did the person asking you, actually want to have different a year from now? It’s possible the answer is “they don’t know”, and so you do the research and present options. But you need to know what their priorities are, because otherwise how can you rank your possibilities into a proposed suggestion?