Switching from Customer Success to Engineering: a year later

A couple years ago, I joined PartnerStack in their Customer Success department, as an integration specialist. A lot has changed since then — I’ve since transitioned into our engineering department, and it’s been an incredible ride along the way. After over a year in engineering, I wanted to share a little bit about how I got there, and offer some advice to anyone looking to make a similar move at their organization.

When I joined PartnerStack on the integrations team back in 2020, I did with the intent of eventually becoming a software engineer, as the role felt like a good medium between being product facing and being customer facing. I've loved writing software for a long time, but at the time I didn't have any traditional software engineering education. My education was in chemical engineering, and a lot of what I learned about web development had been on my own, through side projects, online courses, or freelancing in the past. Not having traditional or bootcamp education made it trickier to break into a technical role in tech, even more in 2020 as the COVID-19 pandemic had just begun. After going through hundreds of rejected job applications and interviews, the PartnerStack interview process felt like a breath of fresh air and I was delighted to join the team.

The integrations team is an interesting one: we primarily helped during the onboarding phase of a customer’s journey, which included consulting on how best to use our APIs and SDKs with other engineering teams, using our integrations platform to build integrations with a customer’s systems, and more. You were really the main technical point of contact throughout the journey. We also interfaced with and supported other teams, both within CS and outside of it. You had exposure to product and engineering teams as well to relay client feedback and address bugs. Being on the team was an incredible way to learn both the product and the people who used it deeply, and some of the fondest memories I have at the company were while I was there. The team was brand new back in 2020, I onboarded with the only other team member as the company was beginning to build the role out.

A while after joining, I started working with my manager to flesh out my goals of transitioning and how I could go about achieving them eventually. Even though I had support to carve out this career path, execution was difficult. Often times the process felt paralyzing, because I wasn’t sure where to start. I was already confident in the primary language we used on our back-end (Python), but wanted to begin gaining exposure to the codebase and working on issues. At the same time I didn’t want to step on any toes and take up other team’s time / de-rail any processes I didn’t know about.

Where I started was following a bit of a “one step up” model — go “one step up” from what you’re currently doing to dip in to what another team is working on. For me, the target was our integrations platform — I already worked extensively with it (and the APIs backing it) as someone customer-facing. One step up would be working with the team who managed that platform from an engineering perspective, so I got in touch with the manager of that team and some of the engineers who worked there. We settled on a model where I could take on backlog tickets or bugs (i.e. nothing in a planned or active sprint, but where a user need was validated) from their team, pairing with their engineers where needed.

A lot of these tickets or bugs were “first time” type issues that would normally be handed off to new developers onboarding. The bugs forced me to understand the path of execution from a code perspective for features I was used to seeing from a user’s perspective, and even though the fixes were a couple lines long, they were monumental in helping me understand our back-end (largely a monolith). Over the coming months, I took on bigger tickets, eventually helping close out a whole feature. It felt amazing being able to share what I had built with my team but also the customers I was on call with — it became a really nice feedback loop.

The challenge became balancing these three sets of responsibilities:

• Building out team processes and preparing the team to grow
• The day-to-day responsibilities of being on the integrations team — being customer-facing can be demanding!
• The responsibilities I was taking on as part of picking up and completing engineering tickets

The balancing act was a tough one, but a few things really helped out. Firstly, we began hiring on the team. This made building out processes much more important, but it really helped in the long run as team members onboarded faster. A nice side effect of this was that other teammates could now help take on some of the things we were working on if they were interested, since they were now public and not living in people’s brains. The other thing that helped was strictly not working on tickets within an engineering team’s sprint — this kept expectations low and didn’t affect their delivery as much while giving me a ton of space to learn. If I needed to de-prioritize a ticket, I totally could.

Eventually, after numerous conversations and plans being drawn up I was offered the position and started in late 2021. Along the way, I learned a few things that I thought might be useful to someone else wanting to make the switch down the line. None of these are meant to be prescriptive, every workplace and situation is unique and mine pertains more to a SaaS startup.

1. Keep notes of the journey: Keep track of the details as you go through all of this — what did you work on? What sucked? What conversations with which people did you have? These notes, a lot like a brag document, help you advocate for yourself as you discuss your goals with your supporter, and supporters within the engineering org. Adding some dates in will help you look back and feel like you made progress on days where you feel you didn’t. I presented my story linearly, but this process is anything but linear, making these useful.

2. Communicate often and advocate for yourself: Your manager/supporter is there to advocate for you, but they can’t do so until you make your goals known! Communicate with them from the beginning to build a plan, and communicate with managers/team leads on teams you’re interested in learning more about-- this isn’t something you do on your own. Also keep them up to date on your progress (this is where keeping notes comes in handy!) One misconception I had when I started was that wins would speak for themself, but they commonly don’t. By sharing your wins/losses, and speaking openly about the work you’d like to take on and where you want to orient your career, you’re advocating for yourself and making every conversation a little easier.

3. Immerse yourself a bit: One thing that helped me a ton was joining the public Slack channels of engineering teams I was interested in working with (if they were cool with it). This gave me insight into the “stream” of work that team was producing; if there were requests for PR reviews, I got to check out the PR and learn from how existing teammates organized their code. If there are regular, open-invite, cross-team meetings that take place for engineering teams at your company, look into attending them as a fly on the wall. These meetings might contain high level feature proposals, which may be easier to digest since they need to be created for a broader audience. The discussions are arguably the best part, and the kinds of questions raised can help prep you for code review opportunities you’ll have down the line.

4. Try to onboard on your own: Ask around and find whatever onboarding documentation you can on how an engineer would onboard onto the team you were interested in working with. Request access to and set up the repos locally yourself, keeping a list of questions for when you get stuck. The benefits of this are multi-fold:

   1. You uncover holes in the onboarding documentation, which engineering leaders will appreciate (a fresh pair of eyes is underrated)
   2. You’ll uncover frameworks you don’t know yet, adding to your list of things to start learning to prepare you to take on tickets
   3. You’ll have your own copy of (at least a part of) your product running locally, which will benefit your current team immensely as eventually you’ll be able to replicate customer scenarios locally and answer customer/team questions even faster. This is extremely beneficial for “legacy” features few people have context on.

5. One foot in your comfort zone, one foot out: I don’t have a better name for this, but when looking at work to take on, first try engineering work thats as closely as possible related to what you work on in your role. This lets you use the context you have from your role to give you a leg to stand on. Some examples:

   1. If you’re an integration/implementation specialist who regularly talks about specific features or integrations look to see if there are any reported bugs on those features, or “quick wins” improvements one of the engineering teams has planned.
   2. If you’re on a support team, talk to an engineering team member looking into a bugfix for a bug you reported, as it might be a good opportunity for a pairing or shadowing session.
   3. If you’re a customer success manager, try shadowing with a support / integrations team member as they solve an issue or solution for one of your customers.

6. Comb through engineering team backlogs: Every engineering team has a backlog of things that they haven’t been able to prioritize yet. If these backlogs are public to the company, or you talk to the team lead there to get access to see, you have an advantage. Ask questions on a ticket you’re interested in to see if it might be a good fit for your comfort level. If you’re in CS, bugs can be a great first class of issue to work on because there’s a chance you’ve experienced the bug yourself or one of your customers has, which will make it even easier to reproduce. Take on one thing at a time, and ask before taking anything on. If you put up pull/merge requests, ensure the summaries can speak for themselves as you won’t be as connected to the rest of the engineers on the team for a bit. As a general rule, especially in the beginning I considered anything within 2 sprints of work (assuming your workplace’s engineering team follows a sprint model) to be a no-fly zone.

7. Get information out of your head: If there are:

   1. Processes only you know, that people come to you frequently for (especially in DMs)
   2. Knowledge that you have on the product or platform that allow you to answer questions quickly
   3. Context on specific accounts that lives exclusively in your head

   Externalize these! Make use of whatever documenting tools your company has to offer and level up your teammates. This helps reduce the “risk” involved with team switches and can help ease your transition, and help take work off your plate in the meantime.

8. Don’t lose customer context once you go: Once you transition over, don’t be quick to lose your customer context — keep in touch with your CS pals, frequent the channels you were a part of before. On an engineering team, product managers are usually the people who have access to customers, and try to gauge priority based on their needs. This is something you’ll have baked in, and will be one of your greatest strengths in the beginning. With your customer context, don’t be shy about helping product managers with understanding needs and priorities of the customers you used to work with. It’ll help your entire team to have another person with customer context to bounce ideas off of.

9. The imposter syndrome: The imposter syndrome may feel strong while you’re trying to get your first pieces of work out there. You might not feel you deserved what you got, or that it could be taken away at any moment. Even after transitioning, it’ll be around (and may even be worse). A couple things that helped me to keep in mind:

   1. You’re here for a reason — you’ve worked hard to get where you are, and have the work to prove it (pull/merge requests, or old conversation threads might help on days you’re feeling it hard)
   2. Your access to customer context is one of your greatest strengths on your new engineering team, and will help everyone deliver solutions much faster
   3. You’re setting the stage for other people at your organization who want to make a similar transition

I hope this helps! If you’re considering a career switch like this at your organization and want to talk, shoot me an email, I’m always happy to talk and dive into things further.