OpsLevel Logo
Product
Developer portal
Software catalog
Understand your entire architecture at a glance
Standards
Your guide to safe, reliable software
Developer self-service
Empower developers to move faster, risk-free
Integrations
Connect your most powerful third-party tools
Use Cases
Ownership
Build accountability and clarity into your catalog
Standardization
Set and rollout best practices for your software
Developer Experience
Free up your team to focus on high-impact work
Customers
Resources
All Resources
Our full library of resources
Pricing
Flexible and designed for your unique needs
Podcast
Podcast
Conversations with technical leaders
Blog
Blog
DevOps resources, tips, and best practices
Demo
Demo
Videos of our product and features
Tech talk
Tech talk
Our POV on technical topics
Guide
Guide
Practical resources to roll out new programs and features
DocsLog In
Talk to usTry for free
No items found.
Share this
Table of contents
 
Resources
Blog

Onboarding: Balancing Curiosity vs Focus

Insights
DevX
DevOps
Tooling
Onboarding: Balancing Curiosity vs Focus
OpsLevel
|
December 11, 2020
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.

More resources

Blog
September 19, 2023
by
Fernando Villalba
The OpsLevel Developer Experience (DevEx) series. Part 1: What is DevEx?

Great developer experience (DevEx) is what you get when developers can easily achieve and maintain flow state at work. This article begins a series where we tackle all of the areas that affect flow state and impair your developer experience at your company and provide example metrics and suggestion to help you operate like a potential future unicorn.

Blog
August 31, 2023
by
OpsLevel
August 2023 release notes

This month included an update to our Service Maturity features—to give you even more flexibility—plus more sorting and syncing improvements. Read on to learn more!

Blog
May 31, 2023
by
Haley Hnatiw
May 2023 release notes

See what we’ve shipped in the month of May.

OpsLevel Logo
Subscribe
Join our newsletter to stay up to date on features and releases.
By subscribing you agree to with our Privacy Policy and provide consent to receive updates from our company.
SOC 2AICPA SOC
Product
Software CatalogMaturityIntegrationsSelf-serviceRequest a demo
Company
About usCareersContact UsCustomersPartnersSecurity
Resources
Docs
Blog
Demo
© 1999 J/K Labs Inc. All rights reserved.
Cookie Preferences
Terms of Use
Privacy Policy
Responsible Disclosure
By using this website, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Data Processing Agreement for more information.
Okay!