SEANK.H.LIAO

job3 retro

drifting into complacency

job3 retro

Escaping from my previous postion, I joined the company as a SRE.

history, briefly

The new role I got was in the SRE team, part of the Infrastructure group in the company. Unsurprisingly, as a centralized team, we didn't really run the business's applications day to day, in fact, for a team with reliability in its name, I'd say we had shockingly little visibility into how the business's services were doing reliability wise.

Instead the team focused more on providing tooling for the rest of the company. We started off with strong with several typical SRE projects: onboarding an incident management tool, push for SLO adoption, and rework / replatform the logs and metric stacks. That was the first 9 months, pretty eventful, the projects were declared "done" to varying degrees of success.

Then came several months of low activity within the team, and high churn in management. Oh well, I kept myself occupied by expanding my personal scope, picking up shared ownership of shared internal Go libraries, and making improvements to the rest of the wider group's stack, which we shared an on call rota for.

Just over a year after I joined, a soft reorg appeared, and that was probably the last of any true SRE responsibilities I had. I was instead moved over to do infrastructure / platform style work, in particular, migrating 90% of compute from a startup GCP project, into a secured, more enterprisey GCP project. That was a "3 month" project that took 8 months to finally wrap up.

After that, the SRE team reappeared, though it was somewhat aimless without a major project. I decided to busy muself with joining a different team taking care of the company's main monolith, but I didn't feel like I gelled with the team's ways of working. Back in the SRE team, while I was pondering my next move, the annual summertime leadership changes came, and the SRE team was disbanded, and I joined back into the core platform team that I had been working with for the cloud migration.

good things

For most of the time I was there, I had a high degree of autonomy in selecting the work I'd do (not least because there was no management to keep me in check). I certainly learned more about corporate politics, though probably not enough. Some resources were easy to use (general cloud spend), others less so (any other vendor).

I think I got along well with the people in both teams where I worked long term.

I felt my reputation came mostly from being quick to get a problem, and diving through the layers to find a solution. This also meant being considered knowledgable in a very wide range of technologies beyond what my team owned. Since I considered everything under the Infrastructure group "mine", I openly implemented / pushed for improvements where I saw the need for them, not unlike in the open source world.

I was quite happy with my deep dives into kyverno (upstream bug), vector and datadog (vendor misbehaviour), chartmuseum (240k / year cost saving on S3), and istio (2.4mil / year cost saving on interzone traffic).

bad things

In this series of blog posts I keep, I try to list out the things I did. Over time I found it harder to articulate where I spent all my efforts. As in, no large-ish projects were done that could be primarily attributed to me. Sure I worked on some very large / impactful projects but I was all over the place.

I felt the point above more acutely in interviews with other companies. I try to interview regularly to see what's available, what other people are looking for, and what gaps I have in skills, experience, or storytelling.

Finally, churn in leadership made any sort of progression hard. Every time a leader changed, it was a relationship reset, and with that I'd consider if I'd be better off with a hard reset (job change).

conclusion?

There is no conclusion. This is just a record of my thoughts for now.