Coding Conversations: Four teams, three tracks, two offices

Editor's Note: LinkedIn Engineering is dedicated to solving complex problems at scale to create economic opportunity for every member of the global workforce. This challenge provides our engineers with the opportunity to build their technical skills as they make this mission a reality. In this series, we’ll talk about the career development of the people that comprise our Engineering team. 

If there is one thing I’ve learned in my last two years at LinkedIn, it’s that talent is a top priority for the company. In addition to hiring net new talent, internal mobility is a corporate belief that LinkedIn truly puts into practice, and I’ve had a chance to experience this firsthand. Since joining the company two years ago as an intern, I’ve had the opportunity to work on four different teams, in three different tracks, and from two different office locations. In this post, I’ll share details about my journey through these roles and the thought processes that led me to make these changes.

Chelsea’s current team at SRE InCon, LinkedIn’s internal conference for Site Engineering

Philosophy when starting my career

I didn’t start my career with the intention of switching teams multiple times or switching career tracks so early. Instead, I began my professional journey with a few specific intentions:

1. Learn how to work well with others
2. Build out my skill set and mastery
3. Be rewarded for the work that I do and continue to grow in my role

Before starting my career, I had the impression that a lot of people go through the motions at work and then gradually become demotivated, in need of a vacation or break from the day-to-day. I didn’t want to live a life that required any sort of escape. In other words, I wanted to make sure that my work life wouldn’t make me want to go on vacation.

As such, I set the following baseline lifestyle requirements with regard to work:

1. Work must not get in the way of me wanting to wake up in the morning, nor should it negatively affect my energy for the rest of the non-working day.
2. Work must contribute to making me a better human being in the grand scheme of things.
3. Work must teach me things that will help me with my long-term career, with at most two months without growth.

These requirements came from asking the question, “How do I want to feel day-to-day?” I found that any of these principles being violated usually correlated with an overall lower sense of well-being.

My journey from Intern to Software Engineer to Site Reliability Engineer

My career began interning in LinkedIn’s New York office as a frontend engineer, but I was largely interested in backend or anything closer to distributed computing. Fortunately, I joined a full-stack product team that had both backend and frontend engineers, and my manager was flexible enough to allow me to work on something that would be challenging and interesting for me. As a result, I worked on a backend project using Kafka during the internship, and received a full-time offer at the end.

Since I was interested in further exploring backend engineering and had gained experience in it through my internship, I negotiated my full-time offer to include changing teams to a backend-centric team and switching to the Software Engineer position, rather than the Frontend Software Engineer position.

Backend team as a full-time software engineer
Upon joining the backend platform team as a full-time software engineer (SWE), I quickly learned that I was the only one on the team with frontend experience, so I worked on a project to launch a public-facing tool, Post Inspector, to help internal and external clients optimize their third-party content for LinkedIn. You can read more about Post Inspector here. I also worked on the API and backend infrastructure with that project.

Beyond my work on Post Inspector, I also refactored our core code base to simplify the data models architecture and worked on improving code reviews, team standup meetings, and sprint processes to improve execution. I also created a recurring tea time event to improve team collaboration and get to know the team better.

Switching from SWE to Site Reliability Engineer
Six months in, even though I had just received a good performance evaluation, my motivation was at an all-time low. There were several factors that led to this situation, including my desire to work in a more fast-paced project environment that would consistently challenge me. I also found that the team culture wasn’t as good of a fit for me as my intern team had been, and I craved an environment that would be more relaxed and relational. Reflecting on my original intentions and requirements for my career, I knew I had to make a change. I spent several months talking with my manager about what I was interested in and wanted to do next. That’s when we realized that I needed to switch teams. 

The prospect of switching teams was a little intimidating because I had already begun to build up a body of work as a SWE, and making a change would mean starting back at square one, so to speak. However, one thing I learned from this process was the value of having a solid body of work to point to when making a change, even if it’s not directly related to the new position. Other people will be more willing to give you a chance in a new role if you can demonstrate the type of good work that you’re capable of.

Through this process, I also learned the importance of maintaining open communication with my manager regarding how I was feeling about my work. Because I had been open and frank about my experience, it was easier for my manager to understand when I felt my motivation dipping, and for them to pinpoint possible causes. It also helps both of you brainstorm ways to improve the situation before it reaches a critical point.

Joining the New York SRE team
So, after much deliberation and several conversations with my manager, I chose to switch tracks from SWE to Site Reliability Engineering (SRE) by joining the New York Engineering SRE (NYENG SRE) team. I had some contextual familiarity with the SRE role, but not really an understanding of what SREs do in day-to-day practice. While I was excited for the change and new challenges, I was nervous about the uncertainty of whether my skills would transfer to the new role.

SRE is infamous for being woken up at all hours of the night to fix business-critical outages. While this isn’t always the case, I had to learn how to be on-call. Initially, I used to worry, thinking “Why am I being trusted as the line of defense for these money-generating services?” But after a few on-call rotations, I soon had no problem escalating to different teams to get things fixed, and I perceived incidents as challenges to solve, instead of as evidence of my (in)ability. I also worked on making a security-related tool more robust and refactored it for ease of maintainability, and became an embedded SRE on a team to improve the long-term stability of their services.

From my switch to SRE, I’ve discovered that learning about things that interest you, even if they aren’t directly applicable to your current work, can expand the kinds of opportunities available to you. And, more importantly, I learned that while many skills are eventually transferable, an attitude towards learning is immediately transferable and is key to being successful right away. 

Relocating to California and joining a new team
One of my favorite aspects of being an SRE is that it provides an opportunity to work with multiple teams and verticals to solve outages. This meant that, when I took a work trip to California, I knew several more colleagues than I had before. As a result, it was a fun trip with plenty of opportunities to talk to different people in different teams and roles. I loved the experience of collaborating with SREs and discussing work life with a variety of people. At the time, our headquarters in Sunnyvale had several SRE teams, whereas the NY office only had one. Since I had already been an SRE for six months and wanted to expand my responsibilities, I started thinking about relocating seriously, because a lot of the hardest site reliability problems require the work of several teams.

After a subsequent work trip, my decision to relocate was official. I was already working with a distributed group of SREs on a Product Experience Monitoring (PEM) project, so I had some continuity even though I would be switching teams, offices, and personal lifestyles. After working with my manager and analyzing my working style and the company’s needs, I moved to work on PEM full-time in California as the first dedicated team member.

How I made these decisions

Over the course of the last two years, LinkedIn has afforded me the opportunity to make my voice heard when I was looking for a change or needed a new challenge. It’s hard to ever judge if a decision was the “right” one or not, especially because there are many potential paths to happiness in life. However, I have decided that for now, a “right” decision is any decision that provides me more benefit than the amount of work it takes to make and adapt to the decision.

My baseline lifestyle requirements have guided my decisions a lot, as well. I’ve found that you can’t always predict where you’ll be or what you’ll be doing, and you don’t have full control over those things. All you can control is how you are feeling and what you are accomplishing, and then use that to determine if your day-to-day fits your personal requirements. Fortunately, I work at a company that also advocates for and sticks behind its claim to care about employees’ career transformations, which has allowed me to grow in ways that I couldn’t have otherwise predicted or defined.

Conclusion

It’s important that a work environment seeks to enhance, rather than restrict, its people, including you. I’ve learned that I want to work at a company that not only gives me the room to grow, but also is forgiving enough to allow me to make mistakes and take the time to do so. When comparing companies’ offers, don’t forget to factor this in, since this will affect your long-term happiness and trajectory.

From all of the team, track, and location switches, I’ve learned to take a week off between major transitions to refocus on what matters and re-energize myself for what’s to come. This may not be possible for everyone, but, fortunately, I could do this due to LinkedIn’s unlimited discretionary time off.

And lastly, it’s all about confidence. Build your soft and hard skills to have the confidence to make decisions that best suit you, and as you learn more about a company’s work, you’ll be able to make more mutually beneficial decisions. I’ve found that decisions that best suit me will often also be in the company’s best interest. In other words, when I am more enthusiastic about what I’m doing, the company also benefits from my improved output and vigor.

Throughout these career shifts, several key habits have helped me adapt more easily to new environments and responsibilities. These habits include reading, talking to interesting people at work, and practicing daily reflection. For more on how I’ve cultivated these practices and how they can benefit individuals looking to develop professionally, read my article on LinkedIn.

Acknowledgements

The people you work with, and thus surround yourself with, make a huge difference in how you develop. Thus, I’d like to thank coworkers both outside of my team and within my team. Starting with my coworkers from the NY office: thanks to Tom Dale for all of the interesting conversations and guidance since my intern days, Nikolai Avteniev for his guidance on fixing and switching teams, Chris Ng for all of the lunches and code reviews, as well as Evan Farina and Nate Woodhams. I’d also like to thank coworkers from the CA offices such as Michael Kehoe for telling me about Conscious Business, as well as Cliff Snyder, Brandon Tsao, Brian Wilcox, Anu Krishnan, JinUk Shin, Sandhya Ramu, Nick Han, and Will Chan.

I’ve also learned a lot and had fun with my team members. Thanks to Pratheeksha Seetharama on my intern team as well as Ben Poyet for providing me the flexibility to work on a backend project. Thanks to Yaz Shimizu for being open to feedback and thinking about my career, and also to the rest of my backend team. Thanks to Xiao Li for the guidance while I was a SWE and for believing that my capabilities would translate to a SRE role, to Logan Rosen, Zaina Afoulki, and the rest of the New York SRE team for letting me sit on their sofa for half a year and then eventually inviting me into the team. And finally, thank you to Ankur Paul, my diligent manager who works with me throughout the risks and mistakes.

Thank you to Anne Trapasso, Hannah Sills, and Michael Kehoe for helping edit this post and make it come to life.