Conscious Career Growth

Problem

When I first started my career as a software engineer, growth was linear, straightforward. Being an entry-level IC, I knew my immediate goals were to keep coding, learning technologies, and implementing features. The path was laid out - SWE 2, 3, Sr SWE, Staff, etc. Reaching each of those levels meant growth. Somewhat subconsciously, I was learning the skills to get there. Many times, referencing the guidance attached to each level as a loose checklist with my then managers to identify what gaps I needed to fill to get there. As I grew professionally and personally, that checklist grew less apparent. What did it mean to grow then? Should I have emulated the path of my former classmates, colleagues? It didn’t help matters when I joined a company with a completely flat hierarchy. Through a journey of self-awareness and constant introspection, I decided to forge my own path.
 

Actions taken

I like to think of my career - not as a ladder I need to climb - but more like a jungle gym. As I grew more senior, the label and titles started mattering less, and having the freedom to choose the challenges I wanted to pursue and things I wanted to learn mattered more.
 

Self-awareness was the first step in this journey. Figuring out what matters to me now, both in the short term (say one year) and long term (two to five years), was critical. Introspection and a bit of soul searching led me to identify the areas I wanted to improve. By this point, I considered myself somewhat of a subject matter expert. Delivering features, building and maintaining systems and services, converting requirements into features became more routine and table stakes. I had confidence in my technical skills to know that I could solve technical problems and deliver business impact.
 

Next on my journey, I identified the areas where I could provide value to the team, setting up engineering processes correctly. Addressing tech debt on the team, which involved identifying weak parts of the system and making them resilient, was part of that journey. I also added tests following TDD and helped improve alerting and monitoring. These were some of the things that I could deliver myself. By consciously setting up a pattern and framework that others on the team could leverage, I helped keep the resiliency of the systems. I then decided to take up advocacy for better engineering practices and socialize my ideas within the team and, in some cases, within other sister teams that worked closely together. This gave me exposure and visibility within the org, leading workshops and sessions for knowledge sharing, becoming the go-to person on these matters.
 

Another area where I challenged myself was leading cross-functional projects and teams. These are projects that are business-critical and needed to be driven across business teams, sometimes even crossing the org boundaries. Drawing alignment in these is crucial. To set the project up for success required buy-in from everyone, involving discussing trade-offs.
 

I am now practicing this muscle more intentionally. Along with improving my technical know-how, I am also increasing my interpersonal skills, empathy, and collaboration. I practice fostering and building relationships with stakeholders all over the company. As a result, I am more satisfied with my work.
 

Lessons learned

• When I feel stagnated, I stop and think about what I could be doing additionally to adding value and impact, which would help both the business and org prosper. That is aligned with my own growth and creates a win-win situation. I would also reevaluate my goals and adjust them as needed.
• “Leader” is a loaded term. Most recognize EMs, Directors, VPs -- the people leaders - as that. But you don't always need to be awarded a title to make a difference as an IC. The first step is to stop and ask yourself, “How could I grow more, and what is important to me?” Answering this question as authentically as you can is the key to unlocking and forging your own path and leading the way.