How to set yourself up for success in a Staff+ engineering role

If you’ve just landed a new Staff+ position, congratulations! Now you need to ask the right questions to make sure you’re ready to deliver maximum value in your new role.

Understanding why your new position was open and why you were hired is the first step to building the context you need to do your job.

In a perfect world, you’ll have an interview process where you can push for answers to make sure there’s a good fit and that you know what you’re getting yourself into. I’ve never had issues asking for skip-level conversations (e.g. with your manager’s manager) or additional meetings with teammates or product managers at this stage. Of course, sometimes you won’t be able to have these conversations before you start a new job – reorgs, lateral transfers, and hasty interview processes can leave little space to do this work before your Day One.

But whether you have the luxury of a slow, thorough interview process, or you’re about to land in unknown territory, there are seven key areas to focus on to set yourself up for success.

1. Understanding the Staff+ role’s level and scope

When management opens a staff-level role, they’re not simply looking to fill an empty seat. They’re looking to make a strategic hire that will influence the direction of a team, department or company. It’s often a business choice to open a staff role, not just a planning and capacity decision.

To understand the level and scope of your role, try asking your direct and skip-level managers why this job was opened at your level and not the level below.

Listen for cues in their answers about the expectations for the scope of the role. Do the responsibilities sound smaller or larger than what you’re looking for? If so, consider digging into the role’s leveling.

2. Understanding the hiring strategy

A healthy organization will be able to successfully hire external folks at staff-level and above. Usually, however, companies look internally first. Even if they’re not launching a major internal search, it’s far, far easier for the hiring manager if they can quickly look around at their current reports and see someone who can take on the job at hand. And if that means a promotion or career growth for that internal person, that manager has just scored two wins!

So, what caused the extra work of hiring externally for this role to be worth it? I would ask the hiring manager why they were looking to fill this position externally. I find answers to this question pretty reliably turn up threads you can pull on to find the main stressors and challenges for the role. At the very least, you have your first pass answer at what the need for this role is.

3. Understanding how you fit for the company’s need

Once you have an answer to why they are trying to fill the role externally, consider whether you’re the right fit for the role. Here are some examples of company-identified needs and how I might think about whether I’m a fit:

• We’re growing so fast!
  Are they just looking to fill butts in seats (in which case, do you think the seat looks comfy?) or are they looking for someone who has seen this rate of growth before?
• We’re at the stage where we need our first principal engineer.
  This is an exciting stage for them and it’s important to acknowledge that! However, dig in to ensure you agree on what that looks like. Do you agree on the reasons why they think now is the right time for that role to be added to their company?
   
• We’re looking for you to mentor senior folks into staff roles, but right now we don’t have any internal candidates.
  Software engineering is a growing field, so this definitely happens frequently. How do those seniors feel about not being internal candidates? Is the mentorship that they want for those engineers the kind of mentorship that you’re good at?
• We want to do something with X technology and we don’t have enough expertise.
  Gently ask how they know X is the path forward. What did that process look like? Can you sign an NDA and do some technical deep dives to make sure you fully agree?
• Nobody wanted this job.
  A personal favorite. Roles at staff and above are typically high-stress and frustrating – we’re dealing with a lot of the coordination and communication work that is often correlated with low job satisfaction. What keeps you still excited about this type of work? Will those factors be present in this role?

4. Exploring the identified need

Okay, so you think you’re a fit. But does the company really understand their problem?

If you’re still at the offer stage, it’s reasonable to ask for an additional block with the hiring manager, the skip-level (it might be a short call!), and a relevant product manager. Separately, you can usually ask to meet with some IC peers. And then you can mine your network for connections within the company for more folks to meet with. (If you’re already on staff, we’ll talk about building this network in my next LeadDev article.)

As graciously as you can, poke at the problem in as many ways you can think of. Take what you learn from one meeting and ask about that same topic another way. I frame it as the world’s gentlest game of five whys.

Let’s say you were hired for a stalled project. Things I would immediately poke at:

• What’s the current state? What was in place before work started?
• What was the process that led to deciding the path forward? 
• Why is it stalled? Who thinks this is a good idea? Who doesn’t?

If you only read the job posting and did the phone screen, you might reasonably walk away with the impression that the company needed an expert in X technology. Sounds great! You know X technology! Once you’re on the ground, however, you may find you were truly hired to understand why the broader problem is hard, why the current solution based on X hasn’t worked, who might not be onboard, and then figure out how to deliver.

5. Understanding what driving change looks like in a Staff+ role

You’ve made progress identifying the core need that led to this role to be opened. But why are you the intended solution? Very rarely are you being hired because everything needs to stay exactly the same. What are they expecting you to change?

Change is uncomfortable! If you’re being hired to change something, you’re by definition creating stress in the organization. Will that stress fall on your shoulders or someone else’s? Consider whether your role will feel the downsides of your eventual success or whether another person or team will feel it.

It’s rare that you and only you will feel the unfortunate consequences of the positive changes you drive forward in a role. How do you want to handle that? How does your prospective boss frame their relationship with any teams and managers that may have reason to push back on your initiatives?

Questions you can ask:

• Anything I should know about how that team works with us?
• How does *team manager name* work with you?

With these questions, you’re looking for any red flags or bad political relationships. I don’t know whether it’s subtle or not, but when I’m initially building trust with someone, I find it easier to ask about how someone else works with them rather than how they work with someone.

6. Understanding the role’s current level of empowerment

The flipside of poking around to see if you’re being hired to be a bull in the china shop is whether you’ll be able to build the buy-in to actually solve the problem. Neither a raging bull nor a field mouse are effective hires to run a dinnerware store. One has too much muscle; the other has too little.

I don’t have any guaranteed winning questions here because the situation on the ground has always been different than what was shared, even with internal transfers. You’re being hired to assess the situation and build agreement on the path forward – to a certain degree, your job is to build your own empowerment.

However, it’s worth noting as something to push on as you interview and as you settle in.

Questions you can ask:

• What paths forward are on the table right now? Who has been involved in these decisions?
• Can you walk me through the process of the last contentious architectural decision that impacted your organization?

7. Articulating and owning the problem

You’ve successfully answered the question of why you were hired when you’ve identified the problem to which your hiring is the intended solution. In many ways, this is your first win on the job! But think about how often in the past you’ve asked, ‘Hey, why are we doing this?’ and ‘Do we really need to do this?’ and discovered the team was building the wrong thing. As my friend and former colleague Ben Scofield told me, delving into why you were hired is performing that exact skill – just for your role instead of a new feature.

Bring that skill set that you’ve built up over the years to these discussions. I think you’ll find that you have a lot of leeway in solving the problem – your boss may have an initial idea of what to do, but should be looking to you to solidify the solution for this big need they’ve identified. If you disagree with the way you’re expected to solve the problem and there’s no flexibility, then it’s time to walk away. After all, they’re hiring you for this job; they need to trust your expertise.

The only thing that is not negotiable? You need to be ready to fully own the problem, that big need, from day one.