Being spoiled

Posted 2020-11-04

I was once very spoiled - quite recently - very spoiled.


In my previous role, I was a Software Engineer in a highly structured organisation. I hated the hierarchical structure. I hated the focus on process over outcomes. I hated the approach to operations.

In my currently role, I'm a Reliability Engineer in a highly unstructured organisation. This post is about how things are different.

I was spoiled

There are too many directions to take this, so here are a list of ways that I was once spoiled:

  • The most important thing to work on at any given time was determined by my manager. If I worked on the wrong things, it was my manager's performance at stake.
  • The landscape of possible work items to consider for me and my manager was determined by a product manager. The product manager worked tirelessly to fill checkboxes and create spreadsheets for some salespeople to reference.
  • Interface/protocol-level details for important software was authored by a spec writer and signed off by a manager, sometimes a product manager, sometimes higher ranking managers, and sometimes a software architect. At times I wrote a spec. At times I challenged the need to write a spec. At times I was permitted to write the spec some other way than with a Word template. But I was never solely responsible for the correctness of that spec. Only the execution/implementation.
  • At times I had to write software from scratch, and at other times I had to utilise data stores on legacy software - both single-availability data stores, and fully-redundant NoSQL-style stores. At times I had to write database migrations. But, I never had to take full responsibility for writing a software system with a backing datastore, including its migrations.
  • I never had to monitor the impact of my changes in the field - I relied on a software architect to guide my changes, and I relied on a full-time testing team to validate performance and cost impacts.
  • I was never responsible for enabling operational tooling (unless I wanted to).
  • I was never operationally responsible for my software's stability at night and on weekends.

Sometimes I broke out of this process space. I pushed back against some of the above, citing efficiency gains. I had earned the trust to do so from time to time, and even landed on a sort of green-fields team of like-minded individuals, but even there, I always had a safety net.

The SWEs I work with are also spoiled

As a brief aside, I originally wanted to write this blog post about how I perceived my coworkers now as being the spoiled ones.

They're blessed with a pure, naive, Layer-7-only view of the world. They're utilising powerful infrastructure to safely roll out changes into production without testing. They're building microservices to integrate with a powerful software platform that handles critical capabilities like auth, data storage, and data versioning by default.

But I was wrong. My coworkers are pushing the boundaries of operational responsibility. They're taking on calculated risks, always pushing the envelope for monitoring and observability, seeking out big-impact changes proactively, identifying high-criticality work reactively, and at times, accepting enormous pain to achieve desired outcomes. Outcomes that they defined and put on themselves without much external input at all.

Am I anti-authoritarian, or just an asshole?

At times I have tried - and still sometimes want to try - breaking out of the accepted processes at my workplace.

I attribute a lot of my success in life to a slightly maverick, anti-authoritarian approach to things. To shun process that doesn't serve outcomes. To identify what can be done better, and to vocalise it.

Being a black sheep works well when process is dysfunctional and imposed. It works poorly when unjustified, unearned, and unmeasured.


In the last two years I've learned what it takes to lead a technical team to excellence from first principles. I understand the meaning behind having "startup thinking". I know what it takes to affect worthwhile change.

I find it incredibly motivating that I will use these skills - skills that not everyone has access to learn - in every role for the rest of my life.