Onboarding: Balancing Curiosity vs Focus

When starting a new job, have you ever asked yourself:

• How much time should I spend learning about the code? The product? The process?
• Was I expected to know Technology/Framework/Design Pattern X?
• Is my ticket taking too long?

Effective onboarding is a balance. You should be curious and learn all the things. But you also need to focus on one thing to avoid being overwhelmed. I will share some anecdotes about my onboarding experiences that will help you manage this balance of curiosity vs focus.

Being Too Curious

Three years ago I started my first job in the software industry. I felt a mixture of excitement and imposter syndrome.

We use Scala!? Elixir!? I love functional programming. When’s the next Hack Day!?

But wtf is Cassandra? DevOps? Was I expected to know these things before joining?

Ultimately, my imposter syndrome dominated my excitement. I was doing deep dives into Scala code to learn about legacy services. I was reading dozens of blog posts every time I came across an unfamiliar design pattern. I started to feel overwhelmed.

This unstructured, “learn-everything” attitude is inefficient. My team wasn’t doing any current development on those legacy Scala services. My time would have been much better spent learning about our current project. I could have completed more tickets, reviewed more PRs and contributed more to design discussions. My team’s velocity took a hit as a result.

Setting Goals

One way to avoid being too curious is to set some goals. Having a more focused approach to learning ensures you prioritize learning the most important things first.  You also end up ignoring the less important things.

When I started my new job at OpsLevel, one of the first things I did was set 30/60/90 day goals with my manager. All new hires at OpsLevel do this since Focus and Efficiency is one of our most important cultural values.

Here are some sample goals:

• By day 30, learn the process  - Ex. deploy three PRs to production, engage in retros and planning
• By day 60, learn the code  - Ex. develop T-shaped understanding of code base, complete a large-sized ticket

It’s best to focus on the process initially since that can be learned a lot quicker than the code. You really only have to participate in a few stand-ups/retros to get a feel for how they’re run. A lot of your people skills from your last job will transfer over.

Learning the code takes a bit longer. Odds are you have little to no context about the code / problem space. Trying to learn all the code at once can be daunting. It’s best to focus on one part of the code initially. Then slowly, over time, you can branch out to other parts of the code. This will allow you to develop a T-shaped knowledge of the code where you have a deep understanding of one specific area and a breadth of knowledge about the other areas.

Self-Awareness

When I started at OpsLevel, I had more confidence than I did three years ago. I had written a ton of code, led some projects and considered myself proficient at “DevOps” (whatever that ubiquitous term means).

I also knew there would be a lot of things at OpsLevel that I didn’t know. But that was ok. I was confident I would be able to learn those things, in due time.

It can be difficult to have this self-awareness as a junior engineer. It comes with experience. But regardless of your seniority, you should know you’re not expected to know everything. If you were good enough to get hired by company X, they have confidence that you will be able to learn those things. You should have that confidence too.

Leverage your Strengths

In my second week at OpsLevel, our GitHub integration suddenly began processing repository:created webhooks incorrectly, affecting some customers.  We spun up an incident call right away.  When I joined the call, I had two possible courses of action:

• Respond
• Scribe

Although the engineer in me wanted to dig into the issue, my self-awareness spoke up. I was brand new to the company and the chances of me contributing to the incident response were next to none.

I noticed no one was scribing. I had scribed a lot of incidents at my past job and felt confident in my ability to summarize information quickly and concisely. So I cracked my fingers and started typing.

I was able to contribute to the incident response, while also learning about our product and how it could break. I didn’t feel any self-imposed pressure about needing to fix the issue asap. People like our CEO who couldn’t join the call were able to stay in the loop due to my scribing.

When starting a new job, you bring your strengths with you. They are why you got hired. Some of your strengths can be used right away - written communication, API design, identifying edge cases, authoring tests, etc. Others need time to gain context about your new role. Perhaps you’re working with a new language and need to learn the basics before you can write beautiful code. Knowing which strengths can be used right away will help you onboard more effectively.

Conclusion

Like a lot of things in engineering, onboarding is a trade-off. You will get better at managing this curiosity/focus trade-off over time, as you gain more confidence and self-awareness. But there are some practices you can adopt right now, like goal-setting, that will help.

Now you will be more conscious of the balance between curiosity and focus. You will be able to onboard effectively and stress-free. Best of luck in your future endeavors!

One of those endeavors could be OpsLevel. We just raised $5M and we’re laser focussed on fixing DevOps. We care immensely about ensuring all new hires have a smooth onboarding experience. Check out our open roles.