blakehawkins.com

Being spoiled

Posted 2020-11-04

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

Context

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.

Summary

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.