Growth after Onboarding
Five tips to make the most of your first year
“My manager would give me specifics of what I needed to do to improve, but the answer was often that I just needed time. It didn’t all come to me immediately. I needed to marinate in the environment.”
An excerpt from The Growth Series (read the rest)
Photo by Christina @ wocintechchat.com on Unsplash
In the last month I’ve had 3 conversations with engineers just past the onboarding phase of their new job. There was a common question across all three conversations: What should I be focusing on for the next six months to set myself up to contribute to the team, be on track for a promotion, and grow at the company. I wasn’t surprised, six months is a very natural time to have this realization. Your onboarding launch plan that you’ve spent the last six months meticulously checking off is now complete and it’s easy to feel on your own to set goals now. What’s next?
Of course you’re not on your own, your manager is still there to support you and you have your team, but you now have a bit more flexibility to set goals and work towards milestones that matter to you and your team.
1. Review your current state
Create a blank document and write down by month your key contributions to the team. Don’t worry if these seem small, you’ve been onboarding for the last six months. Write out your work in a detailed way that will help you and your manager see your current state. Leverage your launch plan as a starting point and then review your pull requests, assigned Jiras, emails, etc. to pull a complete list.
Categories to include:
Achievements: Set up local environment, installed team’s software, device setup, first pull request, first comment on a pull request, demoed at sprint review, completed key trainings, answered question in the team chat, etc.
Learnings: New technologies, key solutions, team codebase, team culture, etc.
Projects: All major projects you’ve worked on
Other contributions: Wiki updates, led meeting, represented team at meeting, etc.
This exercise will take some time, so going forward think about what systems you can have in place to reliably put something like this together every month
What themes do you notice? What are areas you’ve spent a lot of time on? What skills come most naturally to you? What have you not spent time on?
2. Goal Setting
Use the review from above to create goals for the next six months. These goals should cover a few key categories: Things you want to learn, Experiences you want to have, Trainings,
Here are some examples for a junior software engineer:
Complete interview training and shadow 3 interviews
Work on projects in areas X and Y
Present a tech talk
Serve as a Scrum Leader
Resolve a high severity issue while oncall
Reduce number of revisions per pull request for complex changes
Complete a design document
3. Breadth vs. Depth — T-shaped engineers
“My manager tried to build out T-shaped engineers: an engineer that has breadth in a bunch of different things but depth in a small number of areas. We alternated between going wide and going deep. We tried to get me exposure to different things and then take on a project that would allow me to go deeper. She was being very intentional with projects I was picking up. She would get me projects with visibility, across the stack and things without a time pressure early on.”
— An excerpt from the Growth Series
A great strategy for software engineers is to focus on building depth and breadth gradually with the goal of eventually being an engineer with a lot of breadth (the top of the T) and depth in a few key areas. Building out these skills will mean you’re someone that can actively participate in meetings and understand what your team and related teams are working on and provide feedback on pull requests, but also that you will be a subject matter expert in a few key areas that allow you to specialize and train the team. Depending on your projects early on, it’s natural to be leaning more in one direction than the other, for example if during onboarding you worked on a series of unrelated bugs in the codebase, you probably have a decent amount of breadth for a new hire, but are lacking any depth. Whereas if you had one project throughout onboarding you might have a lot of depth but have no idea what the rest of the team is working on because you’ve been in a bubble.
Identify which area you’ve been focusing on more lately and add specific goals to work on improving in the other area over the next 6 months.
Example Breadth Goals:
Participate more in team meetings (at least one comment / question per meeting)
When I don’t understand a status update at standup, ask the teammate later to explain
Review teammate PRs daily and ask questions to gain understanding
Review team tickets and identify how the oncall solved the issue
Watch recorded tech talks on key areas of the team
Read team architecture diagram and explain it back to a team member until I understand it
Work on 3 Projects that don’t overlap with my onboarding projects
Work on a Project in X area.
Example Depth Goals:
Write a design document
Research a new technology and give a tech talk
Lead one project end-to-end
Photo by Christina @ wocintechchat.com on Unsplash
4. Subject Matter Expertise
This brings us to becoming a SME (Subject Matter Expert). Sometimes this happens naturally based on when you joined the team and sometimes you have to actively work on it. Besides speed and reliability of delivery one of the biggest differentiators between junior and mid-level engineers is subject matter expertise. As a SME you can be a primary reviewer of a major change, teach others about the feature or technology, and mentor junior engineers.
Identify opportunities for expertise on your team. If everyone is already an expert in X area, then you should definitely learn about it, but you’ll never be an SME for that. Instead identify 1–2 areas where every time they come up, the team reveals gaps in understanding. Dive into the technology, read what exists, talk to several teammates to gain understanding, and then work on a few tricky projects or bugs in that area. Then when people ask questions in the chat about that, proactively answer the question or provide insights. One caveat: usually these areas lack experts for a reason, maybe they’re particularly tricky, seen as boring, or the previous expert left. Don’t feel the need to dive into every mundane topics you come across and work with your manager to identify the right opportunities for you. Another way to grow subject matter expertise is to lead a new project or area for the team.
You likely won’t achieve expert status by the end of your first year, but by working towards this gradually you’ll set yourself up for success.
5. Seek out multiple mentors
Around 9 months to a year may be a good time to seek out mentorship, but don’t limit yourself to a formal mentor. Too often women in particular seek out career mentors, but miss out on technical mentorship which can be the greatest differentiator of growth and the next level.
Identify 3–5 people on your team that you admire and aspire towards. Reflect on the characteristics they demonstrate:
Do they always share key insights in team meetings?
Are they a prolific coder?
Do they know how to debug even the gnarliest issues?
Are they great at design patterns?
Then instead of asking the dreaded “will you be my mentor?” question ask them specific questions:
How did you get to be so great at ____?
What would you recommend I do to improve at ____?
The next time you work on ____ could I shadow you for a bit?
What would you recommend someone at my level do to grow on our team?
These are questions engineers can more readily answer. Set these meetings up with a few engineers on your team, work on the recommendations they offer, and then meet with them in a few months to thank them for the help, discuss your progress, and ask what they’d recommend next.
For most this is a more realistic and accessible approach to mentorship than a formal mentor.
