Oliver Starr

Editor’s Note: This is a guest post from Jean Hsu of Range.

I recently joined Range as their new VP of Engineering. Over the last few weeks, I’ve ended many days full of meetings feeling energized — grateful to work with this incredible group of humans. And to be honest, I’ve also ended days feeling depleted — feeling a bit bashful about basic questions and overwhelmed by all that I don’t know.

Although I’ve previously onboarded at big companies like Google and smaller startups like Medium and built onboarding programs for engineering teams, this is the first time I’ve onboarded to a team in over eight years. It’s also the first time I’ve been onboarded to a team while everyone is working remotely, not to mention in the middle of a pandemic, while my kids are distance learning from home! With those remote constraints and personal time constraints in mind, I wanted to be particularly intentional about how I spent the first few weeks.

In this post, I’ll share some guiding principles and practices that have been helpful to me in navigating this onboarding process. 

Use Structured Questions to Get to Know Individuals and the Team
One-on-ones are foundational in getting to know people as individuals. You will want to schedule recurring one-on-one meetings with people you work closely with — whether that’s direct reports, cross-functional leads, or your manager.

In your first or second one-on-ones with the team, ask a set of structured questions to guide the conversation. You can give people a heads-up that you’ll be doing so, so they know it won’t be the norm for all one-on-ones. These are the questions I asked everyone on the engineering team:

• What’s going well at Range?
• What’s been frustrating, or could be better?
• If you could have your way, what one thing would you change?
• What do you want to get out of your time at Range?
• What support can the team or I provide?

Think of these questions as a broad invitation to share whatever they feel is important. There are few enough that there’s plenty of time to dig into the responses in a 45 minute or hour-long time frame. Delve deeper into each with open-ended follow-up questions like “What else?” and “Can you tell me more about that?”

Without a clear intention, over time, one-on-ones can settle into status updates or pleasant-but-not-too-meaningful chitchat.  By bringing up these topics at the start of a new work relationship, you let the other person know that the one-on-one space is one where these topics can be discussed. One-on-ones are the venue where you want to hear what’s going well, learn about any frustrations, discuss areas ripe for change, what your direct reports want professionally, and what support they need. 

Lean into Your Beginner’s Mind
When you’ve been on a team for years, working day-in and day-out in the same codebase and same team, you acclimate to small changes around you, like slowly increasing build times or that weekly meeting that doesn’t seem to have an agenda. Blindspots emerge that slow the team down significantly.

When you’re the newcomer to a team, you’re the only one with entirely fresh eyes. Take notes on what you notice. Are there product features that seem particularly delightful to you? Do you find any processes that feel needlessly painful? What about obvious gaps that feel important to fill?

It’s easy to tell yourself, “Oh, I’m new, so I’m sure they have a good reason for that. I’ll just keep my mouth shut and see if it all makes more sense in a few months.” It’s tempting not to want to rock the boat and not be the new engineering leader associated with complaints. Quite reasonably, you don’t want to be the person who chimes in at every meeting with, “Well, at Google, we did XYZ.”

To get around being the “problem messenger,” get buy-in upfront from other leaders with whom you work closely. Talk to them about what gaps you can fill in the leadership team, and discuss processes for you to leverage your “Beginner’s Mind” in this critical period to share observations and insights.

Absorb Information, and Let Go of Your Need to Know Everything
At Medium, the previous tech company I worked at, I joined before there was a Medium. I was there through the nascent ideation process, building out of the initial product and every single product iteration after that. 

At Range, I don’t have that in-depth knowledge to lean on.
Suppose you are, like me, joining a company as an engineering leader. In that case, you may be trying to absorb everything you can about the team, the individuals, the processes, the codebase, and the product. Piece together what you can — have conversations with engineers, designers, product people, sales, and marketing. Read relevant docs, and learn from the expertise others have on the team.

And know that you don’t need to have that full historical context to fill your role effectively. I also remember times at Medium when I had no context at all. Once, I helped DevOps scope out a plan for thwarting DDOS attacks, even though I had no prior meaningful knowledge concerning this issue. I scoped out and executed a successful multi-month API project, with little context as well. 

So absorb what you can to get up to speed and let go of your need to know everything. Ask questions when you have them, and ask for help when you get stuck. Trust that you’ll tap into your team’s expertise to get the information you need to lead teams and projects. 

Define Your Role
As you settle in and start to get a feel for the team’s needs, take some time to take a step back and define your role. It can be easy as the new person to help out everywhere as needed, but take the time to think about what you want the position to be — what do you want to be doing six months or a year into your job?

There will be parts of your role that are more concrete and non-negotiable, but engineering leadership roles often have a lot of room to choose your adventure. 

I love to write, so part of my role definition includes external-facing influence through writing blog posts and helping with other content for the product. Someone else may want to carve out time for regularly preparing and delivering talks or play a meaningful role in defining and iterating on team processes. 

When I’ve taken the time to clarify my role in this way, it helps to contextualize the day-to-day tasks and feel less scattered and reactive. It’s analogous to taking the time to define and communicate a team’s North Star and top priorities. Even if individuals are working on varied tasks, it’s essential to know how it ratchets up to the team’s focus — and that also helps individuals be mindful of when their work doesn’t contribute clearly to the team’s priorities. Similarly, taking the time to define my ideal role gives me clear intention and direction — so rather than feeling scattered or overwhelmed, I can see how the disparate parts of my job add up towards a role I aspire to fill.

Joining a new team as an engineering leader can be exhilarating, daunting, joyful, and overwhelming — sometimes all in the same day! You may be pulled in all directions before you even settle in. While you’re getting up-to-speed, remember to keep just a few priorities top-of-mind and communicate them clearly (even if they change every few weeks). I hope these principles and practices help you navigate this transition. 

About Jean:
Jean Hsu is the Vice President of Engineering at Range. Prior to Range, she built product and engineering teams at Google, Pulse, and Medium, and co-founded Co Leadership, a leadership development company for engineers and other tech leaders. She’s also a co-actively trained coach and has coached many engineers, tech leads, managers, PMs, VPs of Engineering, and CTOs. She loves to play ultimate frisbee (though not during pandemics), and lives in Berkeley with her partner and two kids.

About Range:
Crafting new ways for organizations, teams, and individuals to unlock their full potential