Sometimes Bigger Isn't Better

Sometimes bigger isn’t better. This is a lesson I have recently learned as I step away from two years at a unicorn scale-up company. So let me first give some background context to this situation, and for the sake of brevity, I will attempt to be succinct.

I have no formal education in IT or computer science. My knowledge in these fields results from a self-taught education and hands-on experience. While it is true that self-learning is a more-than-viable path to success with the overwhelming amount of information and courses available on the internet, it does come with its downsides. One such downside of the self-learning approach is a lack of understanding and direction regarding which skills and principles one should spend extra time mastering before reaching for the next rung on the ladder.

In my case, I have an intermediate understanding of technologies and tools such as Linux, virtualisation, Docker, Kubernetes, Terraform and AWS, to name a few. However, my depth of knowledge in these areas can be (in specific scenarios) somewhat shallow as I have only ever learned enough to achieve the task at hand, which often was to climb the ranks as quickly as possible.

My priority to ascend the engineering hierarchy is not only reflected in my practical skills but also in the positions I have held in my career so far. As previously mentioned, I am coming out of a two-year tenure as a mid-level infrastructure engineer at a unicorn scale-up. Believe it or not, this was only my second full-time engineering role. Before that, I was a junior DevOps engineer at a smaller (but still sizable) company further in its maturity.

Unsurprisingly, the jump from junior to mid-level was far more than just a title bump. It came with a substantial increase in pay, flexibility, autonomy, but also responsibility and expectations. In my mind, this was merely another “fake it until you make it” situation — a game plan I thought had always served me sufficiently.

The “fake it until you make it” mentality is in many ways synonymous with that of a stretch goal, which is a goal that requires one to stretch past current limitations in order to deliver. A stretch goal can be extremely valuable and effective for achieving growth when deployed correctly. However, when deployed incorrectly and unrealistically, stretch goals can lead to ongoing burnout, demotivation, and a general feeling that each struggling step forward is somehow also a step in the wrong direction.

This has been my experience over the past two years. In other words, I bit off more than I could chew and, consequently, could never catch up and get ahead. Hindsight is 20/20, and looking back, it is clear that skill gaps from my self-taught education, mixed with a stretch goal far larger than was ever obtainable, resulted in this ongoing predicament I increasingly found myself in.

In the beginning, this overwhelming feeling was expected. Starting a new role is always a stretch. One has to meet and integrate into a new team, set up a new work machine, and learn the architecture and nuances of an unfamiliar system. It can often take months in a larger tech-focused company before one can consider themselves onboarded and ready to deliver value back to the company. However, in my case, it never quite felt like this onboarding period reached a conclusion.

Three, six, and twelve months went by, yet I still felt like I was the new rookie on the team, constantly struggling with each task I was assigned. Never was it a case of swiftly pulling a task across the kanban board to move on to the next. Each task inevitably felt like a mountain needing to be conquered with a range of challenges and concepts I had to wrap my head around for the first time. My dopamine meter started drying up.

Of course, I could have requested help and guidance from the wellspring of talent and knowledge in my immediate and extended team, but this felt progressively harder to do as time passed. No one wants to be the annoying one constantly asking for the time and assistance of busy colleagues dealing with their own workloads and challenges. So, I eventually stopped asking for help and took up the mindset of pulling myself up by my bootstraps. After all, I have taught myself everything I know, so this was no different. The thing is, it was different.

Scale-up companies move fast (hence the name) and are not always positioned to hit pause and invest extended time in levelling up those falling behind. I want to take a moment to clarify that this is not a flaw of the company. Rather, it’s business, and the aim of the game in business, regardless of the growth phase, is profit — a reality that most find uncomfortable acknowledging at the risk of sounding cold and harsh. Unlike my self-learning experience, where there were no deadlines, there were most definitely deadlines in a company on a rapid scale-up trajectory. So, I started fast-tracking my work to meet projected timelines and forgo the ability to really learn and understand the technologies I was touching.

My work became increasingly sloppy and often contained avoidable mistakes, making its completion take even longer. This pattern started becoming noticeable to my superiors, and I could feel their uncomfortable but justifiable gaze shifting in my direction. I felt like I was letting people down (and I was), so I worked harder. I quietly began to start my work days several hours earlier to catch up on tasks I had failed to complete the day prior. Yet, somehow, I seemed to be getting even less work done. I became easily distracted and lacked motivation. I often found myself staring blankly into my screen, scrolling through irrelevant work emails, or getting up to “stretch my legs” and play with my dog for the 4th time in an hour. I did not realise it then, but I was experiencing burnout and had begun circling the drain.

This led to the dreaded message no one ever wants to receive: a performance review. I was simultaneously surprised and unsurprised at the reality I had found myself in. Deep down, I knew this was coming and was most likely warranted, but I had become adept at denying just how lacking my performance had become, as that would be time taken away from the already dwindling deadlines I was failing to meet.

Suppose you’re reading this and have never witnessed or experienced a performance review. In that case, performance reviews are almost always a death sentence and serve more as an indication that one should get their affairs in order to move on, rather than to redeem oneself like a fallen hero in the third act of a Marvel movie.

This was all just over a month ago. At the time, once again, I foolishly thought this to be another case of pulling myself up by my bootstraps, overcoming the momentary hurdle, and soldiering on. However, throughout the month-long hearing, the reality of my situation became increasingly evident: this was not a hearing; it was a trial.

Queue the five stages of grief

We come to the present moment and this very post. While the narrative I have just laid out seems quite grim, I no longer choose to see it this way. Sure, I have recently resigned from a position I had no plans on walking away from only a handful of weeks ago, but perhaps this is the universe forcing my hand to play the cards I should have some time ago.

The past two years were definitely not a waste. I worked with some truly incredible people and learned much about scale-up companies and the “Silicon Valley” culture. But, most importantly, I learned how to identify my limitations and a situation that isn’t working for me.

I am now taking a course on Kubernetes to obtain the Certified Kubernetes Administrator certification. Then I plan to do the same for the Red Hat Certified System Administrator certification. Doing so will fill out many of the gaps in my skillset, as mentioned earlier, and put me more in line with the expectations of a mid-to-senior engineer.

I am also looking for my next role and this time with the right expectations that bigger is not always better. Instead, I want to take a step back and find a role that allows me to hone in on the technologies and concepts I am interested in (Kubernetes, Linux, infrastructure and automation). This will afford me the time to start mastering these foundational sections of the modern cloud engineering world rather than attempting to take on the whole goddamn kingdom at once.

I understand that this post and the conclusion to its story is not something most would recommend revealing to the world while seeking a new role, but I’m afraid I have to disagree. I am not ashamed of my journey; I own it. Owning one’s failures and shortcomings is the only path to meaningful growth.

I also hope this serves as a reminder to others who may have found themselves or are currently in a similar situation that you are not alone and that taking a step back is okay. To steal a line from my favourite Batman anthology: “Why do we fall? So we can learn to pick ourselves back up.”