Career Growth After Your First Engineering Promotion

Musings from a Senior Infra Femme Engineer

Indu Subbaraj
Bluecore Engineering
6 min readMar 15, 2021

--

drawn by author

You just got your first promotion — congratulations! Whether you were promoted from an entry-level engineering position yesterday or two years ago, making it to the next stage of your career is an exciting achievement. Once the high from the promotion starts wearing off though, a scary question often surfaces: what next?

Navigating that next stage of your engineering career can be a confusing experience. The evaluation rubrics companies use are often much more open-ended after entry-level positions, a reflection of the multiple career paths available to a mid-level engineer. This means your career growth is now, even more so than before, in your hands, a simultaneously awesome and terrifying reality. With the experience you’ve gained, you’ll start noticing new opportunities emerge in your work. These may fall into different categories: technical, leadership, cultural, etc. All these possibilities can quickly grow overwhelming, and it can be difficult to figure out how to navigate these new waters in a healthy, productive fashion.

These are all emotions and experiences I personally felt after my promotion to senior engineer last year. And although I finally feel like I’ve found my rhythm as an engineer (at least for now!), it was a struggle. Below are some of the most important learnings that have helped me on this journey.

Set Boundaries

“Set boundaries” is a phrase often used for relationships with people, but I’ve found it crucial in figuring out what matters in my next stage of career growth. After being promoted, I often felt compelled to volunteer for any leadership opportunity that arose. This isn’t inherently a bad thing, but it led to me overcommitting to responsibilities I did not have the support to succeed in.

For example, when I moved to the Infrastructure team at Bluecore, I was also the scrum/team lead because I had served that role on my old team. I had never been on a devops or infra team before and I quickly realized that I just did not have the experience or breadth of knowledge to be able to perform the high-level, vision setting duties of a team lead. This was the fault of no one, just a truth of the circumstance. Deciding to step down as team lead and focus on implementation and technical learning was one of the best career choices I’ve made because it has set me up for much better future success as either an individual contributor or lead/manager.

The goal of setting these boundaries should be to allow you to focus on what you have the most control over. It’s helpful to communicate your boundaries with your manager so you’re both aligned on your chosen area(s) of growth. I’ve found the intentional focus helps me grow faster in my committed goals, not to mention the wonders it does for my mental health at work.

Focus on Implementations Over Design

When I was first promoted out of an entry-level engineering position, I thought the best way to learn would be to write as many design docs as I could. After all, isn’t architecting solutions a sign of a more senior engineer? This is certainly not wrong and gaining experience in designing complex architecture is critical to technical growth. However, even more important at this stage is continuing to build a solid technical repertoire that will empower you to make informed architectural choices. The best way to grow this knowledge is by implementing solutions — writing that code. The more technical areas you’re able to execute projects in, the better. Experiencing a breadth of technical knowledge early in your career allows you to discover what you enjoy, gain useful technical perspective, and learn how to learn fast.

Implementation often ends up involving design decisions because engineering is inherently an iterative process. No matter how much design work is done prior to implementation, roadblocks invariably arise — these are moments you, as an implementer, are most equipped to navigate and where your analysis and architecture skills grow. I most recently experienced this while instrumenting Google App Engine for tracing. Executing this project taught me about the ins and outs of tracing, UDP/TCP networking, VPCs, how to leverage shared libraries, and even python metaclass programming. This hands-on learning has improved my technical instinct and given me technical perspectives that have already helped me make better decisions.

Don’t Fall Prey to the “Grass is Greener” Syndrome

You may be thinking after the last section, “What if I don’t have tons of new opportunities on my team?” I’ve felt this way at times in my career too! It can be easy to feel stuck when on a team maintaining legacy code or while working on a project that isn’t greenfield. The biggest thing that helped me break free of this mindset was shifting my perspective. I moved from a prefixed, static mindset of “these are the tools/things I wish I could learn,” to instead think “what opportunities can I create to learn new things in this work?” A practical approach that has helped me is to think of the ideal state of the project — what does the perfect execution of this work look like? The gaps between the current state and the ideal state are rich opportunities to learn some new technical skills and make a tangible impact.

An experience that really hit this home for me was my first project on the Infrastructure team: increasing the visibility of Bluecore’s Google Cloud Bill so we could understand how to optimize our engineering costs. The project involved lots of seemingly mundane tasks: enforcing labeling standards on engineering resources, aggregating logs, and writing lots of SQL queries. At first, I was disappointed I wasn’t able to work on what I considered our more “infra” projects such as operating Kubernetes clusters and configuring networking. Once I started to change my perspective and embrace the work I was doing, it became apparent just how many opportunities there were to learn. For example, instead of just simply labeling all existing Kubernetes resources manually and crossing my fingers that engineers would remember to do the same for future ones, I deployed Open Policy Agent (OPA) and created Rego rules to auto enforce these labels. In the process, I learned a lot about not just OPA but also Kubernetes and ArgoCD. And this was all in pursuit of streamlining our cost analysis work!

The most powerful trait of this mindset is that it allows you to take charge of your own growth and learn the important skill of creating opportunities, rather than letting random circumstances decide.

Find a Mentor in Everyone

One of the most common pieces of career advice is “find a mentor.” I’ve always disliked that statement because for most of my professional career, I’ve understood it as finding someone who fits some ideal vision of what you want to achieve in your future. Well, what if you don’t know what you want to do in your future or you just haven’t met anyone who fits that vision? That’s perfectly okay! Look around you, especially at those you work with on a daily basis. Every one of them, yourself included, has their unique strengths and weaknesses. Identify some of the strengths in people you work with and actively learn from them. By doing this, each of them becomes a mentor to you in a way. Of course, learning from your own and others’ weaknesses is a rich opportunity in its own way!

Crucial to this is working with people who know more and/or different things than you. Seniority isn’t the only indicator of this, but working with those who have had more technical experience than you certainly provides for rich learning.

The thoughts I’ve shared here are by no means conclusive methods of growing as an engineer and you may resonate with none, some, or all of them. Regardless, I hope that my perspectives have provided some food for thought as you navigate your own career path. These mid-career years are extremely formative and also the most common years during which engineers leave the profession, especially from underrepresented groups. As a female engineer myself, I’ve begun to experience the sobering reality of a dearth of senior women in engineering. And as someone who is just starting to find her place in the world of tech, I write this article to pass on my learnings, in hopes that it can help accelerate other engineers as they navigate this important stage in their career.

If you’re looking for a new adventure to experience some of that growth, check out the Bluecore careers page!

--

--