Joining a new company in a leadership role is a funny position. You come in to a position of authority: you've interviewed; a panel of people have decided you have the right stuff; you've done this before (possibly for a number of years) and you feel pretty comfortable that you know what "doing a good job" means.

Yet it's also curiously lonely. You aren't really joining a "team" per se - while your Director / VP / CTO manages a group of people, your personal remit and span of control is likely quite encapsulated. You will need to get to know your team - this is absolutely most important - but also your peer group and senior folk at the company.

Most importantly, until your feet are properly under the table you won't really have anyone's full trust. Building that trust means shipping a few things, having people see you operate in good times and stressful times, garnering good feedback from your team and peers. Your reputation builds to the point where people say "oh yeah, they know what they're doing". Coming from a previous company where you had this security to a place where you don't is quite disconcerting.

It may (or may not!) be comforting to know that this never goes away. I know CTOs who have experienced it very directly. Indeed, the more senior you get the more scrutiny you come under: expectations and compensation of Directors and VPs are far higher, as is the blast radius of bad hires.

Loosely speaking there are two types of new manager role: one is taking over an existing team, the other is building a new team. The former is far more common so that's what we'll discuss here.

When coming in to manage an existing team, your core focus must be building trust before making changes. This is important at all levels of leadership. Even if your previous team was a self-organizing paragon of productivity and harmony, you have the best management instincts and books of effective process and coaching techniques, you still want to hold off and ask questions first. It cannot be overstated how wrong things can go (and how hard it is to claw back) when new managers come in swinging the bat, even when they're entirely right.

The simple reason is that teams are made of humans, and humans fear change. This is true even when they're literally asking you to make changes.

So how to proceed? First, speak to everyone in and around the team. Ask about them as individuals but also have consistent questions prepared. There's no perfect template for these questions, and you should evolve them as you learn more about existing standards, process and technical underpinnings.

But broadly you want to know about software development at all stages: how are projects kicked off; when do engineers get involved; how does software get planned and designed; how does code get written, tested and reviewed; how does it feel working locally; what's the state of CI / CD; how's the operational picture and load; how's monitoring and alerting done. There are more but this is good starter. Get each person's own take on it, and build your picture from there.

Remember that your words will travel. Don't make statements like "wow that sounds awful" even if you're repeating back what's said to you. You are in fact finding mode, not judging mode. This is also where you start to identify the people you'll work with later when you want to make changes.

Once you have a good sense of how everything is, and more importantly why everything is, then you can start drawing out some changes. Not everything all at once. It's good to start with things that are low cost and high perceived pain - meetings are perfect for this. Stand-ups, project status meetings and so on are often wasteful, thoroughly despised by engineers and easy to change. It just takes someone with the right authority and the right plan.

As a general rule avoid sponsoring technical or platform changes immediately as they are expensive (even if the ends clearly justify the means), and you want to be shipping things in your first few months. This is because you're also building trust with others around and above you, and that means your team delivering business value.

Note: if you've been hired to run a platform team, or to help a team with lower infra / quality / technical standards in a more hands-on fashion, then your business value is those technical changes. In that case, go for it, as it's what you were hired for.

Coming in as a Director or other level of senior leader is always interesting. You will have been hired with a specific purpose in mind: to lead a business unit and take over from someone who left, was promoted or was fired; to oversee a previously non-aligned group of teams; perhaps to bring expertise and authority to younger startups who are growing fast.

You should know what the role is and some detail about expectations before you start. For the purposes of this guide we'll assume you have oversight over some business critical part of a product, and manage multiple teams (each with their own engineering manager).

Similar to new line managers, the best advice is to ask questions and get the full lay of the land before making changes. Be aware that this can be stressful: everyone wants to join a new company and have impact: you will be aware of increased scrutiny that comes with the job title and comp packet, and feel like you have to do more. Resist this.

Your resources for figuring how things work are your boss, your team of managers, and (to a lesser extent) your Director peer group. Building trust with them early is the best thing you can do. I once got a nice insight from an SVP at a household-name tech company: the way the pyramid works means that no matter where you are in it, your day-to-day looks the same. No matter if you're a VP Eng with an org of 1000 people, or a line Eng Manager with a team of six: you have a boss and some direct reports. These few people will take the majority of your time and energy. Building the best relationships you can with them will always make you more effective, and make your life better.

You want to get a feel for what the business value of your organization is, and how it's measured. At Director level this will either exist and be clear, or it may be up to you to determine. In either case this is your currency when talking about your org - figure it out, measure it and improve it. Base your updates around it, and be consistent. This is how trust is built with executive teams.

You then want to figure out how this business value is split between your teams: what they own, how it contributes. From there you can manage teams through the value they provide to the business: set targets, ask for the right reporting and monitoring, hold them accountable for it.

Obviously this is very high-level. In reality there are very blurry lines here. You will be mapping real world concerns like teams, applications and services (and their leading indicators, which are easy to measure and adjust) to business value (and its lagging indicators which are notoriously hard to change).

Ultimately, this is the gray area where senior leaders operate. Success is the ability to manage that ambiguity and bring your teams, boss and all other interested parties along with you.