Fast-track your career: How I went from Junior -> Senior engineer in 2 years

Hi everyone,

Jordan here. In this issue, you’ll learn a wealth of actions you can do right now to grow in your career, regardless of your level.

By doing these things, I was able to go from an L1 (Junior Engineer) at Gusto to L3 (Senior Engineer) through 2 back-to-back promotions.

Before jumping into it, a few warnings… feel free to skip to the “Year 1” section

⚠️ Warning 1: My intent

• I don’t intend: To come across as bragging

• I do intend: To pack this post with a massive amount of useful nuggets you can start integrating into your day-to-day

⚠️ Warning 2: Title inflation

There are often a set of people who complain about title inflation or try to bring others down, saying it is impossible to actually be one of these higher levels in a short amount of time.

Do not listen to them.

Regardless of if that is true, who cares? If your company promotes you for good work and wants to give you a title for it, let them. You deserve it.

Of course, there will be cases of a small startup giving out Principal Engineer titles to people with 1 year of experience. Those are the minority of cases. If you are consistently exhibiting Senior Engineer qualities at 2 YOE (years of experience) because you put in the work and your company promotes you for it, enjoy it, and don’t let people tell you it’s not possible. It is.

⚠️ Warning 3: I almost burned out

I recommend taking only a portion of some of the things I did and applying them to your work life. Don’t do them all. I overworked myself and got close to burnout a few times. I only intend to be exhaustive to give you as many options to pull from.

---

🏁 Year 1: Junior Engineer → Software Engineer

In each section, we’ll talk about the base level of expectations for the level you are at and how you can stand out.

It’s essential to not skip the base-level responsibilities. If you skip these and try to act like a Senior right away, it will hurt you more than help you.

Guiding principle at this level

You’re viewed as a positive addition to the team, you follow team processes, ship projects with the teams’ guidance, and need less help over time.

Minimum responsibilities

1. Be a contributing member of the team

   1. Your main focus should be crushing the projects you are assigned. Any free time you have should be dedicated to doing your assigned project better, even when you are blocked.

2. Learn about team processes

   1. Watch how your peers handle on-call, give standup updates, participate in the planning process, retros, project syncs, etc.

3. Slowly gain independence by learning from your senior peers

   1. Become similar to your teammates 1-2 levels above you in how they ship projects. The fewer differences your manager sees between you and them, the more of a case they have to promote you.

How I stood out

Reminder: Ensure you are at least meeting the minimum responsibilities before these

• I documented what I learned: As I was ramping up on the code (my minimum responsibility), I identified areas that were missing documentation. I identified areas that weren’t documented and created docs and diagrams for them. This showed I was dedicated to not just ramping up myself, but also future members of the team.

• Identified opportunities for new team processes: After documenting my learnings, I realized there wasn’t a great way for me to share my learnings. I worked with my manager to create a bi-weekly team meeting we called “Mind Meld.” I got to be the one to lead it and get people to present. In the first meeting, I presented the documentation I created and my learnings from it. After that, I made a spreadsheet and requested volunteers every 2 weeks. The team process still exists to this day and has been an opportunity for junior members of the team to get a leadership opportunity.

• Learn and show dedication to your senior teammates: Early on in your career, it is essential your senior teammates vouch for you to be promoted. They are the ones who work most closely with you and can tell your manager you are ready for promotion. At the time, I wasn’t really thinking about this; but here’s how I made this happen. I made it clear to my teammates that I wanted to learn from them and asked to pair program every 2 weeks or every month.
  

  Pair programming was an amazing opportunity for me to see how each of my team members approached problems and get to know them better. We would often take turns working on a problem I or they had, either splitting the session in half or taking turns at the meeting level. Either way, I learned a ton.

  Additionally, this gave them a way to gauge where I was at, provide suggestions for improvement, or give more positive feedback when it came time for performance reviews.

• Team building: Create a board game night for the team to bond. Led this and set up a monthly meeting

• Improved the code: Our tech lead brought up a pattern that we should be avoiding but happens too often in our code; in our case, it was Ruby `ActiveRecord` calls everywhere. I worked with him to make a doc that described a new pattern going forward to isolate our `ActiveRecord` calls in one area. After creating the doc, I shared it with a few teammates to get buy-in before a large meeting presenting it to everyone. That pattern still exists in the code 3 years later.

• Getting good at on-call: By pairing with teammates on on-call issues early on in my career, I was able to learn from how they approached each issue. That allowed me to solve on-call issues as fast as them and made for an easier promotion case. Additionally, because I was able to fix on-call issues quickly, our customer support team would call out how helpful I was, which gave me big bonus points as a junior engineer.

🌟 A pattern to notice

Did you recognize the pattern with each of these ways to stand out?

Each of them also moves the “minimum responsibilities” forward.

One of the best ways to get more done and grow faster is to find ways to move multiple goals forward with one action.

Imagine if you found one thing you could do which made you a better programmer, communicator, and made your teammates like you.

The pair programming example did just that. It made me a better programmer by learning from my peers, a better communicator because I had to explain what I was trying to do with my code, and made my teammates like me because we got to spend more time together.

Finding these “golden opportunities” is a secret sauce that will help you grow and get to the next level faster than you thought was possible.

🏁 Year 2: Software Engineer → Senior Engineer

Guiding principle at this level

You can ship projects independently, take on ambiguous tasks, and lift up your team.

Minimum responsibilities

1. Ship projects with minimal guidance

   1. As a junior, you’re expected to need guidance, and you should take it because you have a lot to learn. At this level, you should be able to do scoping and designing, then be able to present it to your senior teammates for approval.

2. Be a role model for junior engineers on the team

   1. You are now in the position you were looking up to as a Junior engineer.

3. Take on more scope and responsibility

   1. Adding documentation, writing clean code, designing APIs, and identifying opportunities and deficiencies in code, should all be in your scope.

How I stood out

Reminder: Ensure you are at least meeting the minimum responsibilities before these

Since this promotion was more challenging to achieve in a short time, I’m going to switch up the format, just give a ton of bullets with short explanations, and then talk about how you can apply these in your work.

Here it goes…

• Leading projects effectively: This could be a whole blog post on its own but here are a few ways I showed leadership and ensured projects went smoothly

  • Make a Slack channel for the project. It doesn’t have to be Slack, but there should be a way for quick async updates and communication

  • Schedule a weekly sync with relevant stakeholders. There should be check-in points every week to ensure everything is on track or to address any blockers.

  • Do a spike to find edge cases. A spike is where you attempt to ship the feature as quickly as possible and leave out implementations for methods just to get an idea of where things would go wrong and what you need to plan for. Planning without touching the code will likely result in missed edge cases.

• Becoming a subject matter expert on GraphQL and Frontend: I noticed that our team was adopting GraphQL for the first time and I thought it was an interesting technology. I asked my manager if I could get involved and I bought a book to learn as much as I could about it. After I read it, I had a wealth of knowledge to bring good patterns to the team. I slowly became the “go-to” person for all things GraphQL and frontend.

• Becoming a cross-functional partner: It’s important to be well-liked by your cross-functional stakeholders like designers, PMs, and customer support reps. In places where designers or PMs would have their requests denied due to scoping, I would do everything I could to find a solution that would make them happy. This might be the exact thing they wanted, or a compromise that made them happy; rather than flat-out rejecting.

• Finding opportunities to reduce scope: Since I knew the code really well, I was able to take a product ask, boil down what they really wanted, and look for alternative technical solutions that would take less time to achieve the end result. This would still get them what they want but be done in potentially weeks less time. Having cases like this made my PM and manager extremely happy.

• Publicly sharing learnings: I volunteered for tech talks at the team, engineering, and org level. They were on topics like GraphQL batching, React Testing Library, accessibility, frontend direction, etc. These made my presence more visible to leaders and stand out even with someone with low years of experience. In addition, I made a slack channel where I posted things I was learning about as I dove into becoming a better front-end engineer. I posted that people are welcome to join and it eventually got over 50 members.

• Driving engineering direction: I noticed consistency issues in how teams would use GraphQL, and when we needed to use each other’s APIs it caused problems. In order to solve this, I created a “GraphQL API Consistency” doc and got together the major stakeholders. We all agreed on a set of API patterns to align on going forward. This continued showing a leadership trend and drive for engineering excellence.

• Refactoring code outside of normal responsibilities: I worked to refactor a lot of our frontend code to what was being pushed by the Platform teams. This is often something Platform teams have trouble convincing product teams to do, so this improved my visibility and made Platform teams happy with us as a team.

• Becoming a mentor: I had a few people that I met with regularly to mentor and help grow their careers. As you get more senior, this will become more of an expectation. By showing I was already doing those expectations, it made it easier for a promotion case to be made.

How to apply this to your role

Ok, that was a lot to take in. Let’s take a step back and see how this can apply to you.

Here’s what I notice:

• Where others would say no, you say yes: For example, when your designer asks for that fun little animation as an add-on, try to work it in. When the platform team asks if you can spare some time to refactor to the new pattern, say yes. By doing these things, you build social capital. These people can then advocate for you during performance reviews.

• Learn in public: Learning in public is a clear example of a “golden opportunity” as we talked about before. While you learn, you can share what you learn and get the following benefits…

  • You help your team grow

  • You learn it better because you are teaching it

  • You become known as a subject matter expert, and people go to you more.

• Find opportunities to be viewed as a leader: Being viewed as a leader means people start to question why you aren’t Senior, especially if people are looking to you for answers. You can be viewed as a leader by becoming an expert at something, giving tech talks, mentoring, and leading projects effectively.

• Do not forget about your base-level responsibilities: I was able to do these extra things by working with my manager to get permission, ensure I was still doing my normal project work, and work on these extra initiatives when I was blocked. Wherever possible, I tried to go above and beyond in things that also moved forward my base-level responsibilities. An example of this is when I set up a bi-weekly sync between our mobile team and backend team to ensure there were no surprises from either of us on what we needed in regard to our project work.

🌟 Conclusion

I shared with you what helped me get to the Senior level in a short 2 years. My hope is by sharing my experience with you, your brain is firing off with ways you might be able to apply some of these in your work.

The last thing I want to reiterate is that you don’t need and I strongly recommend you don’t do all of these. I nearly burned myself out multiple times and overworked myself at times. By the way, that was entirely my doing, not Gusto’s.

I do encourage you to think of just one action you’d like to take and apply to your work this week or after your next project is finished. If you have one, it would bring me joy to hear it. Feel free to reply to this email and I’ll respond to every single one.