
*This article was originally written in May 2022 for one of my favourite publications: Gergely Orosz's [The Pragmatic Engineer](https://newsletter.pragmaticengineer.com/p/navigating-the-individual-contributor). I recommend subscribing for a 30-minute length version of this article and much more.*
_____

When I transitioned to my first formal management role, I remember feeling that I was doing well as an engineer with minimal effort. Work just flowed naturally. I gave folks code pointers sometimes without looking at the codebase. When posed with challenges, I knew how to act and get to the solution. 

The journey from junior engineer to senior engineer feels like a continuum, where your perspective of the work changes with each stage of progression. However, the IC to EM transition means learning an entirely different job. The change starts long before you get the title and takes much longer to complete, afterward.

### Transitioning from IC to EM

In most tech companies, the career progression path in engineering forks at around the senior level into two distinct paths. Once at the senior level, you choose if you'd like to progress in the individual contribution craft, as a staff+ engineer, or the engineering management track. 

There are good reasons why this happens at around the senior level: it becomes ineffective to shift context between solving complex organisational problems and driving deeply technical challenges toward clarity.

It's natural then that senior engineers might feel interested in trying engineering management to progress their careers. But what does it take to make this career transition a success?

Engineering management roles are rarer: you first need enough engineers in a team for a manager to exist. A significant component of being considered for the role once the opportunity arises is showcasing leadership traits as an engineer.

Most of the time, expectations boil down to four dimensions:
- **Technology Strategy:** how this person enables the team to build great technology. How they ensure software being shipped is of high quality, that the team has sound engineering practices, and that there is an underlying tech strategy and vision articulating how the team's systems and architecture will evolve over time.
- **Business Impact:** the impact of the software this team ships, relative to the size of the team. The primary measure is not productivity or throughput, but rather how this team enables the overarching business outcomes and how the EM plays a role in making them happen.
- **Process & Delivery:** how this person organises their team. How well they work and collaborate with external stakeholders, ensure accountability is well defined, risks are flagged in proactive ways, and the team functions sustainably and autonomously.
- **People Management:** how this person empowers the people they support. This is not just what their reports have to say, but how this EM promotes growth, matches people to their strengths and growth paths, hires for gaps in capability, and builds a diverse team that fosters a sense of inclusivity and belonging.

Besides the general expectations, some of the key advice I have to offer are:

**Know how to manage yourself.** While this can sound obvious, it is not an easy task. It's not unusual even for senior leaders to mismanage themselves. Typical examples of mismanaging yourself include: 
- Seeking hard goals, forgetting to pace yourself and burning out as a result.
- Drowning in tactics because of pressure and failing to think longer-term. 
- Focusing on speed of execution, mistaking motion for progress and noise for signal. 
- Learning how to manage yourself is a cornerstone of management and leadership.

**Know how to manage up.** The best reports I ever had made my job easy. Not because they didn't need my guidance and support, but because they held me accountable for what they needed from me.

Managing up is fundamentally doing a part of your boss's work, so it's an excellent way to show aptitude for the role. A good example of managing up is taking ownership of problems in the team and coming up with options and a recommendation, rather than just talking about it. 

**Propose solutions to problems.** When you're a manager, accountability becomes an even higher expectation. As a manager, your accountability spans beyond your direct team; it percolates the overarching organisational culture, hiring, fairness, diversity, belonging and inclusion. Leaving issues aside has a much larger blast radius, impacting other people. Holding yourself and others accountable for resolving problems is another key trait that makes you prepared for the opportunity.

When you spot something that feels wrong, flag it to the accountable party, and beyond that, make a recommendation for a path forward. You may not have the answers, but start the conversation.

**Prioritise hard.** In a high accountability environment, one common trap is trying to solve everything that feels wrong. The issue though is that the more responsibility you are trusted with, the harder it is to get to the bottom of your list of problems. It becomes essential for EMs to prioritize well to avoid hindering the team's ability to focus. These traits are also widely applicable for strong individual contributors; they know what matters most and so focus their energy on that. 

Keep a running list of your priorities and every time something new comes in, add it to the list. This same list can also serve as a way to set expectations with your manager in case you are unsure, plus it gives visibility on what you are not doing – which can sometimes be as important as the things you are doing.

Most importantly, you should ask for what you want. Most of the time, [doing so goes a long way](https://twitter.com/ppyapali/status/1361814049231695878).

The last missing bit is the need for a new EM to step up. It can come through your manager quitting, a restructuring in the organisation, your team growing to a point where your manager has more reports than they can manage, and many other situations. As the stars align – or you align them yourself by convincing your manager you can manage a part of the team – you'll be on your way.

### Stepping up to the role
So the stars align and you are given the opportunity to do the role in the interim. In your first year as an EM, some fundamentals can help you establish yourself.

#### Understand the business
In a company, nothing exists in isolation. Everything serves a broader context. As an engineering leader, to be successful, you and your team need to be aligned with the business. You will not be successful if you jump straight into the tech side without understanding the purpose of the team. A large part of an engineering manager's role is building bridges between the team and the broader context. Only with this context in place can you execute against the goals. 

To build a well-informed opinion, you need two inputs: local context (the team) and global context (the company).

**For local context**, my favourite method is [Boz's career cold start algorithm](https://boz.com/articles/career-cold-start). The method is simple, but works very well: you'll hear stories from different angles that will help you build your own beliefs. You will also begin building the relationships which will enable you to be successful in the role.

**For global context**, spend time reading and catching up on what's happening at the company. This is necessary to understand how the work you and your team does maps to the broader company mission. It also helps you spot opportunities to be impactful. 

The more you understand the business, the better positioned you are to shape its direction. Ways you can shape direction include writing [engineering strategy](https://lethain.com/engineering-strategy/), partnering with product and stakeholders to develop a [consolidated roadmap](https://cutlefish.substack.com/p/tbm-4853-one-roadmap) and defining longer-term [Objectives and Key Results (OKRs)](https://www.whatmatters.com/get-started). 

#### Build strong relationships
Your success in a leadership role largely depends on your ability to build and nurture relationships. This part of the work has to do with how well you can work with others and support and be supported by them:
- **With your manager.** In a healthy environment, your manager is the second most interested party in your success, after only yourself. Asking for help is fundamental to your success. As a new manager, you might assume that now you have to deal with everything yourself. Instead, learn how to use your manager and be okay with being supported by them. 
- **With your peers.** Make your manager's reports your "first team." Do this to avoid the feeling of loneliness that can come with a leadership role. Your manager's reports face similar challenges to yours. They are more likely to have a useful perspective on your challenges.
- **With your cross-functional peers.** Engineering teams are usually part of a broader cross-functional team, with product, data, research, design, operations and other counterparts. As an engineering manager, these partners directly impact the outcomes of your work and your team's work. They are fundamental to your success and your team's success.
- **With your direct reports.** Your team defines the largest portion of your success as a leader. A team is a group of individuals, and your success as a manager comes from building an effective, motivated, and impactful group of people. The way people will get the most from you is by you understanding them as human beings, well beyond their technical skills.

If you don't intentionally invest time in these relationships, they will become strictly transactional. Or worse, the lack of relationships may get in the way of getting work done.

#### Build a well-functioning team

<Quote quote="All happy families are alike; each unhappy family is unhappy in its own way." author="Leo Tolstoy" />

Happy teams share characteristics which are not easy to create but are simple to understand. Here are three qualities that are components of well-functioning teams.

**1. Team composition matches the shape of the work.** Happy teams are staffed with people who do work they like, in the proportions of the shape of the work you have. Some of the dimensions to look into are:
- **Discipline:** % of backend, frontend, data, etc.
- **Seniority:** % of junior, mid-level, senior, staff, etc.
- **Projects’ stage of maturity:** % of projects which are zero-to-one, as in trying something new, vs one-to-hundreds which usually means scaling and optimisation challenges.
- **Type of challenge:** % of time the team is working heavily cross-functionally, with multiple stakeholder teams vs working in isolation and writing code.
- **Desired trajectory:** % of people seeking growth vs people seeking stability in the role.

Second, understand the shape of your team. By shape I mean the strengths, growth areas and development paths of the people you support. How strongly work and team match is a strong predictor of how successful people are in a team, and consequently, how successful you are as their manager.

In an ideal world you want a high-performing team that is motivated 100% of the time by exactly the challenges they're given. In reality, this rarely happens. Learn how to [manage and enable performance](https://www.dballona.com/performance-enablement), even if it means supporting people to find a better fit outside of your team. 

**2. Healthy engineering craft practices.** Engineering managers are functional leaders. You are ultimately accountable for the quality of the software your team builds, even if you might not be writing software yourself.

Periodically running [Likert Scale surveys](https://www.surveymonkey.co.uk/mp/likert-scale/) to take into consideration all team members' opinions about different subjects such as state of on-call, architecture gaps, systems ownership usually works well. The maxima is being grounded in the team's sentiment and serves as an input for prioritising engineering investments.

**3. Strong connections.** What makes a group of people into a team is the strength and quality of the connections between members.
- **Shared sense of mission.** A large part of building this sentiment is being aligned on what success looks like. Ways to achieve it include crafting team vision and mission statements and being clear about [direction rather than destination](https://www.productplan.com/blog/build-shared-understanding/).
- **Social bond.** Especially in a distributed world, where video calls can become transactional, creating situations for social bonding is crucial. Social activities in a cadence and dedicating time for team offsites, are examples of ways to create some degree of connection beyond work.
- **Diversity.** Teams that embrace difference and celebrate diversity tend to be more connected. Diversity is a competitive advantage, and diverse teams make better decisions for their customers and the business. 

As an EM, your primary role is in improving the team's outcomes. Building a well-functioning team consists of understanding your team's problems – as every team has them – and working towards improvement, in collaboration with the team members. Start by being a good listener.

### Growing as an EM
If you enjoy the role, your first year will fly by. You will experience the joys of promoting people you support, defusing situations that seemed unfixable, and executing long-term strategies that felt like improbable moon shots back when you started them. You will also experience some of the not-so-great sides of being an EM, such as letting people go, managing conflicts, and saying “no” to things you would've consented to if it was only your call. After some time, you may wonder: “what else is there for me?”

Owning and driving your development becomes more important the more senior you get. It becomes primarily your responsibility to spot, understand and pursue opportunities for your growth. Similarly to the IC track, there are many growth directions you can take into the engineering management craft.

#### Broaden your canvas
Suppose your team’s mission evolves slowly over time, and you're near the point where further investment doesn't grant considerably better business outcomes. In this case, there's a high chance you will feel stagnant. On the bright side, at this stage you will have much more space for defining what the future should look like. Some ideas to further your scope and give you and your team a broader canvas:
- **Explore collaborations with adjacent teams.** With the network and relationships you build over time, it becomes easier to have the leverage to experiment with something entirely new. If you understand the basics beyond your local context, you might find challenges that can be solved at the intersection of teams.
- **Ask your boss for more.** You could be back at our starting point of being prepared for new opportunities. As mentioned at the beginning, making your manager aware that you could do more and asking for new opportunities can help.
- **Make an investment plan.** Sometimes you could be doing more within your scope, but you need to be resourced accordingly. Your manager might not fully understand how much more you could do if you were funded further.
- **Widen your lens to the problem at hand.** Assuming you achieved your original purpose, it makes sense to ask yourself what's next. Using Spotify as an example: it started as a music app, disrupted the music industry and became much more, with podcasts and new audio formats. It's still everything it ever was and is becoming much more.

One common misconception among EMs is that growth in the role comes from supporting a larger number of people. However, the answer is in the most important problems you should be solving for the business. Rather than going on an empire-building journey, you should seek business impact in order to grow as an EM.

#### Try something new
Sometimes the answer to personal growth is changing your context. Before changing teams or companies, it's essential to understand what you want. The engineering management track is full of challenges, and there are many paths to further your growth.

- **Manage multiple teams:** when you support one team, you have total dedication to one problem space. Learning how to manage more than one team simultaneously comes with its own set of challenges such as time management, delegation and stakeholder management.
- **Manage a team outside of your technical expertise:** when your background as an IC predominantly matches your team's discipline, you have much more specific advice to offer. I had the experience of managing a team heavy on machine learning experience. Having been a web engineer most of my IC career, this taught me more about engineering than any other experience I had.
- **Build teams from the ground up:** if you had the experience as a manager of inheriting a well-established team, building a team from scratch is one thing to try out. It comes with its own set of challenges, such as establishing the team's identity and hiring all or most members.
- **Join a team that is well established:** on the flip side of the above, joining a well-established team is another type of challenge. As a new arrival, you won't share all the context and perspectives that the team may have built up over years of working together. 
- **Manage the managers:** Similarly to the IC to EM transition, line management to group management is a complete job change. It comes with its own intricacies, such as having a wide-reaching impact within the business, learning how to manage managers and nurturing a team of teams.

____

In closing, I hope you find fulfilment in engineering management. I found much more happiness in doing the EM role, even when this meant taking a back seat on the engineering craft. 

You may feel differently and if you do, a sideways move from EM to the IC track is career progression. Remember that [your decision is not a one-way door](https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/). Stay curious, loyal to yourself, keep your heart open to change, and everything else will fall into place.


Article originally written for The Pragmatic Engineer, where I talk about what can feel like 'a fork in the road' – how to go about moving from a software engineer role to a software engineering manager role.

Navigating the engineer to engineering manager transition


There's a lot of great literature out there on [why you should build a technical platform](https://kislayverma.com/platform-thinking/why-you-should-build-a-platform/), and [what is a platform](https://martinfowler.com/articles/talk-about-platforms.html), but I haven't found a resource which illustrates specific situations where you might want to build one. With that, I started thinking about patterns that could help spot the need for a platform and what to do about it when you find yourself in this situation as an engineering leader.

I plan to write a few articles about the different patterns I've seen in the past. If you think of any other examples, please reach out and I will write about it and credit you as a contributor.

### What is a platform?

For those less familiar with technical platforms, I'll be using the following overly simplified terminology and set of principles that might help understand the basics. If you'd like to go deeper on the subject, the articles in the introduction will give you more depth on the subject.

##### Terminology

- **Application team** is a team that leverages the technical platform for a specific use-case, e.g. a team building recurring billing through a payments platform;
- **Platform team** is the team that operates and maintains the technical platform leveraged by application teams, e.g., the payments platform team;
- **Capability** is a piece of software that provides the business and a user the ability to do something, e.g., "charging a credit card" is a capability of the payments platform, and so is "refunding a card transaction".

##### Principles

1. **A platform is self-serve for most use-cases.** Not only from a tech standpoint – meaning excellent documentation, developer experience, etc. – but also from a people and process standpoint. [Jade Rubick's self-service coordination model](https://www.rubick.com/platform-teams-and-the-self-service-model/) article illustrates in detail what I mean.
2. **A platform is extensible for use-cases it doesn't support.** Application teams can leverage the platform as building blocks rather than a black box to build and support their own needs. For instance, extending a payments platform to support recurring billing by an application team might be easy if it has a "store cards" capability and supports "charging a credit card".
3. **A platform operates similarly to a third-party to the use-cases.** All complexity on maintaining the platform's domain is abstracted from the application team. Abuse prevention, security, compliance and 3rd-party vendors are good examples of the complexity a platform should abstract away.

The following quote I took from [this article](https://martinfowler.com/articles/talk-about-platforms.html) written by Evan Bottcher on Martin Fowler's blog illustrates the concept very well:

<Quote quote="A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination." author="Evan Bottcher" />

With this quick primer on technical platforms, here's a fictitious story that talks about a common pattern to build platform teams: "consolidation".

### A story & the problem

Acme corp started its business by serving only business customers. Besides building a great product, they also had a software engineering team whose charter was onboarding new businesses. Besides designing the experience, the business onboarding team developed some basic functionality for:
- Authenticity checks through a tax ID to ensure the businesses  onboarded are legally registered;
- Compliance checks for preventing money laundering, for compliance, security and quality reasons;
- Contact information verification to ensure any onboarded business could be contacted for any reason;
- And, as part of the onboarding flow, a credit card was required, which would get charged after the product trial ended.

Product-market fit came very fast for Acme, given their innovative product. Consequently, their ambitions broadened, and Acme's leadership announced a new strategy to support consumers without a legal business, with a different set of features. To do so, they staffed another team to build consumer onboarding. With the rising pressure from investors to hit targets, it made sense for the consumer onboarding team to develop their own set of systems. At this stage, to prevent fake accounts, it was as simple as just sending an email to confirm the consumer's email address.

Over a few months, the consumer side of the business also grew considerably. Acme saw another opportunity to charge a subset of consumers for a specific tier of their business product. The consumer onboarding team quickly implemented the feature, which was an excellent win. Nonetheless, a few months after the launch, some issues came to light:
- Trials between the consumer and business profiles were inconsistent, and managing different lengths of cycles created a lot of overhead for the finance team;
- Given consumer and business onboarding used different payment vendors, the same credit card that would work in a business account wouldn't work in a consumer account;
- As both products were built independently, language to refer to the domain varied across consumer & business, and sometimes was even conflicting;
- As Acme expanded to new markets, both consumer & business teams had to add new payment types, new compliance checks, and support for new currencies.

### Symptoms

Usually, there are a few symptoms that precede the need to apply the consolidation pattern:
1. **Fragmented technology for a capability.** Especially when you're experimenting with a new product, over-indexing in cohesion is usually a bad idea, as you barely know if the product will ever be successful. In the anecdote above, when the engineering leadership team staffed the consumer onboarding team, taking a payment was off the scope, so it probably was the right decision to build a new set of systems. Although as the scope increased, the company ended up with duplicated systems for many capabilities such as "taking a payment", "running compliance checks", "managing trials".
2. **Duplication of work or similar indirect dependencies.** In the anecdote, when expanding to new markets, both consumer and business onboarding teams would depend on a "user management team" to add a "country" field to the user model to select which currency to use when making a payment. We can abstract this as more than one team having to do very similar implementation or sometimes the same work, or two teams having indirect dependencies for the same reasons to the same parties. 
3. **Broken language across the business.** In the example above, referring to "product trial" or "compliance checks" is very ambiguous, as you may be referring to very different things depending on who you talk with. For folks familiar with the Domain-Driven Design book, the [Ubiquitous Language](https://martinfowler.com/bliki/UbiquitousLanguage.html) chapter comes to mind here.

### A solution to the problem

One example of a path forward for teams in such a situation is using the ["application/platform" model](/en/composition-for-teams-platform-and-application-pattern) and splitting up responsibility into three areas: 
- Consumer onboarding, which focuses on the experience of the consumer onboarding and anything specific to the consumer side;
- Business onboarding, which focuses on the business experience and its specifics;
- Onboarding platform, which consolidates the capabilities used by both onboarding teams into a platform. Good examples of capabilities in this platform team might be "taking payments", "managing trials", "running compliance checks", which can be configured or extended to different use-cases;

And here's a breakdown of a step-by-step to test the change and see if it makes sense for your case:

1. **Set up a [virtual team](https://www.referenceforbusiness.com/management/Tr-Z/Virtual-Organizations.html) with representation from both teams.** This group of people will be accountable for putting together an action plan and test the hypothesis. Besides working on a shared roadmap, I recommend looking into SLAs per use-case, level of extensibility needed per team, and prioritising future cases in the new platform with input from both teams. You might find that maybe you can live with duplication for a while longer, or even conclude that a platform is not the right fit;
2. **Carve out capacity to consolidate capabilities.** If that proves to be the path forward, rather than going with a big-bang migration, or rewriting everything from the ground up, pull one capability at a time from former systems into the new platform. A way to prioritise is pick the use-cases that are the largest pain points for both teams and the business first, or the largest bottlenecks for the business first;
3. **Eventually staff a new team.** Preferably with some degree of resourcing from existing teams, and move to the application/platform model.

And to wrap up, here's how doing this solves the symptoms aforementioned:

1. Fragmented technology is no longer an issue, as, by design, the shared capabilities are in a single team;
2. Ideally, most of the work should sit with the platform team when adding a new payment type, complying with a new policy, or adding a new trial type;
3. The new organisational boundary in the platform team can be a forcing function for language correction, even though there will be a need for conscious effort from the platform team.

_____

*Special thanks to [David Golden](https://xdg.me/) for his feedback on a previous version of this article.*


Engineering teams frequently duplicate each other's work. When there are no good reasons and it becomes a pain point, a commonly used pattern is building a platform team, to consolidate scattered capabilities.

Consolidation into a platform team


The most common path to engineering management is through a technical leadership position with people responsibilities, also referred to as [tech lead manager (TLM)](https://www.teamblind.com/post/What-does-Tech-Lead-Manager-mean-in-Google-8e4VQDy1). In such roles, besides holding people responsibilities, the engineering manager also is a technical expert within the team.

As one furthers out in their management career path, they may be posed with situations where they manage a team with a different skill set than they had as an engineer. While this type of opportunity comes with a lot of learning, it may also come loaded with self-doubt. 

There's no absolute answer to how technical an engineering manager should be, given the answer is bound to the context they are inserted in. Still, one fact is that engineering managers are functional leaders. They should support their team in making strategically aligned decisions for the business, even when they're not as confident with their technical skills.

### Safeguard strategic alignment

As a TLM, you have an increased ability to introduce granular controls. Reviewing code, discussing how to implement a change, or a simple deep dive with an engineer are examples of these granular controls that inform your perspective to provide advice and give feedback. A less technical manager who needs to assure that the investment of time and effort goes to the most impactful opportunities can only exclusively resort to slightly more abstract controls, including:

1. **A clear longer-term vision.** This is particularly important as tunnel vision is even more harmful to teams without a strong technical leader. How systems are built can heavily impact your ability to stay aligned to the strategy, so having a clear understanding of what is the target condition for a longer timeframe (e.g. 2-3 years) and communicating it well helps the team to make decisions that are future-proof to the most significant extent possible;
2. **A set of topline metrics and guardrail metrics.** Having a well-defined set of indicators that tell you what good looks like helps assess the team's outcomes and plays a considerable role in prioritisation. For instance, making a prioritisation call between increasing availability by 1% or reducing false positives by 10% is easier when you can attribute both to the same business outcome, such as "OPEX savings". It also helps you stay away from the implementation details you don't understand;
3. **A planning cycle with a clear set of outcomes.** While you may not understand the internals of how something will be achieved, understanding what and why it needs to be achieved is essential, and so is communicating that clearly with the team. Clear, quantifiable outcomes or clear ship goals attached to a business outcome are essential to any context, but it is prohibitive for teams with not-so-technical leaders, as trying to align the team through the detail will be counter-intuitive at best and disastrous in the worst-case scenario.

While you may find that your technical skills may hinder your ability to do the above, defining good abstract controls requires much more understanding of the business than the internals of the systems that achieve the outcomes.

### Decentralise technical leadership duties

For many reasons, including avoiding becoming a bottleneck, engineering managers should share technical leadership duties, even when they're relatively technical. It becomes imperative when you think you are not competent to make sound technical decisions. One approach to solve the situation, which I'm particularly not a fan of, is the TL + EM [two-in-a-box](https://hbr.org/2012/04/leadership-teams-why-two-are-b) approach, where the EM moves technical leadership to a senior/staff engineer in the team while keeping people management responsibilities. I believe it doesn't solve the bottleneck aspect but, instead, it fragments it into two different bottlenecks with the added alignment overhead.

What I believe to be a better approach is identifying the different challenges in the team and delegating entire problems to the most competent person to solve the challenge at hand instead. Doing so prevents merging all problems into a single problem and serves as a forcing function to identify the best people in your team to drive each problem area to clarity. To be able to trust and delegate different types of challenges to different people, you may end up with [an inverted triangle-shaped team](https://twitter.com/GergelyOrosz/status/1480942071179579393) – a team with a more significant senior presence – which comes with its own set of challenges, but usually solves well the technical leadership gap in the team.

### Gather unbiased information to draw conclusions

If you have top-level alignment and shared leadership for different subjects, how do you build a cohesive picture of the whole team's state? By trusting multiple senior or staff engineers with different challenges, you may solve individual problem areas well, but you don't enable cohesion. It's easy to deflect accountability by thinking that alignment will come from people speaking with each other, especially in a senior-heavy team. Cohesion only happens intentionally, and if you leave it to be established organically, it can be highly biased by a few more vocal people, with a high propensity of being the ones you trusted the most responsibility.

With the lack of competence to [verify and inspect](https://lethain.com/inspection/), and not being comfortable with just trusting, I've seen folks have a lot of success build mechanisms where you gather unbiased information to reach their conclusions. Something as simple as running an anonymous survey with only linear scale answers ranging from 1-5 can give you a cohesive picture accounting for everyone's opinions and help start the right discussions.

### Learn the basics along the way

I found myself in this situation in the past, managing teams that worked closely with machine learning when I would undoubtedly fail Statistics 101. Nonetheless, more commonly than not, people hold pride in their craft and will gladly help you understand what they do. Besides learning along the way, I developed a good appreciation for identifying people who could successfully help me understand the basics. As it turns out, this is also a strong signal of competence of who would be able to uplevel others in the team whenever needed.


While good software engineering is universal across disciplines, managing teams where you lack technical depth can be challenging. In this article I talk a bit about what has worked for me before.

Out of bounds: managing teams without technical expertise


Performance management is broadly used as a way to plan, review, and reward people for their contributions. For folks who are unfamiliar about how the process looks like in larger tech companies, it broadly consists of:

1. **Aligning expectations.** Companies usually have a framework that dictates expected behaviour and scope of impact for a specific seniority level; and role-specific expectations provided by the person's direct manager, such as expectations within their team or organisation. The beginning of each performance management cycle usually consists of discussing the current state of the person's abilities in these two dimensions and agreeing on a plan of what the next cycle should look like.

2. **Continuously provide support and feedback.** Throughout the performance cycle, people need to have the support channels to seek input, give feedback and realign expectations. Typically, the process consists of 1:1s on a weekly/biweekly basis and plan/goal reviews every month. Some companies also have mid-cycle check-ins, which are the mid-point of a performance cycle, with slightly more formal feedback and reflections.

3. **Recognising and rewarding contributions.** At the end of each performance cycle, people are rewarded and recognised for their achievements. Different companies will also have their intricacies, but it is usually a combination of extra compensation (e.g. salary raises, stock/equity refreshers, bonuses) and more scope and responsibility (promotions, taking on more responsibility, and so forth). The reward piece is usually defined through a committee set up to reduce bias and focus on facts, so the process is as fair as possible. The outputs of this stage are used as input for the next performance cycle.

Performance management implies control, and managers have their fair share of responsibility for a person's success in their role. Although, for the vast majority of the time, **I find it beneficial to approach my role as a manager in a person's performance as an enablement function rather than a controlling one**. To explain my point further, consider [two performance targets I took from Radical Candor](https://www.radicalcandor.com/growth-and-stability/): folks seeking growth and folks seeking stability.

### Enabling a growth trajectory

For the sake of definition, growth can be folks testing the waters with next-level work, such as someone seeking a senior to staff promotion, but also folks seeking a learning opportunity such as a backend engineer wanting to do more data work or wanting to try a new role out, or an EM filling as interim EM for a vacancy within the same organisation to get exposed to different challenges.

Regardless of the scenario, enabling growth is fundamentally about matching people to their aspirations. Enablement consists of jointly identifying meaningful opportunities that will stretch people to their target condition. The first scenario is more straightforward – promotions are "lagging", meaning there's a need to perform at the next level to get promoted, so expectation alignment consists of setting up goals for that person as if they were at the next level. In the learning-focused case, expectations are usually less company-bound and much more team-bound or organisation-bound – which theoretically the manager has even more agency over.

Similarly, providing support and feedback can be done in many ways. Examples include directly through already established 1:1 channels mentioned before and indirectly through helping the person build a support network around them: good mentors to provide them with advice, a financial incentive for learning & development by leveraging company benefits and budget, etc.

In short, **while managers can be a multiplying force in someone's growth trajectory, people should have agency and desire for the development path.** That is why I believe a manager's role in a person's growth trajectory is fundamentally about enablement.

### Enabling a stability trajectory

A stability trajectory assumes that the person is performing well at their current level and wishes to continue so for whatever reason. Some companies have growth pressure for career progression up to what they call "terminal" level, which once reached, there's no risk of "up-or-out". In such circumstances, people commonly seek stability rather than growth for many reasons, ranging from their focus being elsewhere on their lives or simply liking things as they are. 

In such scenarios, people already know well the expectations at their level. **In most means, especially in "terminal" levels, a manager's role for a report on a stability trajectory is enablement.**

### When to control performance

While most of the work seems to be enablement, there are great reasons why controlling performance is a reasonable approach. A manager is ultimately accountable for the team's outcomes, and sometimes consensus with the report isn't possible. Here are some examples that come to mind:
- **When an individual growth trajectory can impact business goals or commitments**. Typical scenarios of it going wrong include chasing a promotion through [promotion-driven development](https://twitter.com/gergelyorosz/status/1442162670753431559) and resulting in a bad rating at the current level and missed targets because of the negligence of the manager, or not defining an experiment period and rollback plan for folks making lateral moves from IC-to-management and vice versa. Good controls to avoid such situations are using the expectation alignment stage at the beginning of the performance cycle to define when to intervene and how that would happen.
- **When an individual action impacts their teammates or their directs team**, for instance, when there's resistance to develop a skill where the lack thereof affects the team's functioning. A good example might be a manager who doesn't want any involvement in technical decisions but can't delegate the responsibility to a senior/staff IC. Folks sometimes may unintentionally swim against the team's current, and a good way to proactively control it from becoming a performance issue is through openly discussing it in 1:1s, goal reviews, and pointing people out to the company-level expectation guidelines for their level.

There are many other circumstances, but I believe that **the bottom-line is two-fold: firstly, more than when, "how" matters a lot** – arbitrary control may come across as micro-management; **and secondly, usually the control aspect of performance management becomes critical to be exerted when there's an impact beyond the person in their actions**, which is very common for managers, less for ICs.

### When not to control performance

Similarly, things can also go wrong by attempting to manage performance from the controlling angle too much. One example that comes to mind is when the manager and the report have misaligned incentives. What I mean by that is that what's "right" for the role at hand is not what's "right" for the person, e.g. significant need for t-shapedness and the individual wanting to go on the specialist route. In such circumstances, **applying control may leave only two bad options to choose from: bending the role to fit the person in or bending the person to fit into the role.**

Such situations are where the enablement framing has helped me the most – a high performing individual in another team is a better outcome than a low performing individual in this specific team for the business. I've seen folks move internally and get promoted in the next cycle because they were fundamentally ready but lacked matching opportunities, and folks leave companies because they didn't want to develop their skillset in the direction the specific team needed. Undoubtedly, the former situation is preferred, hence why, by default, **I believe looking at performance management from the enablement angle tends to work quite well, at least for me.**


Performance management is the means to plan, review, and reward people for their contributions. My take is that achieveng strong performance and results is more about enablement rather than control.

Performance enablement


I've been recently asked by a fellow engineering manager what was my framework for delegation, and it got me thinking about how to boil down what I believe to be good delegation into a few principles. There's plenty of literature out there on what good delegation looks like. Still, I never spent time synthesising what I believe to be good delegation into something as simple as a set of principles.

In essence, the best examples of delegation I've experienced shared a few characteristics. As the delegator, I could focus my energy elsewhere; I had the right level of involvement when asked for guidance and got to the expected outcome through the delegatee. Similarly, as a delegatee, I got opportunities to work on challenging problems and figure them out myself; I had the right level of support whenever I felt stuck and was held accountable for the expected outcomes.

The pattern is pretty clear: **the best delegation examples I can think of combine moving autonomy and accountability simultaneously from the delegator to the delegatee**. I boiled it down to three principles to help myself reproduce the pattern I believe to be good delegation:

### Delegate problems rather than chunks of a solution

Most of the time it is a bad idea to delegate with a lot of structure. If you have to break down all steps to get to the solution, it probably means you're still solving most of the problem yourself. [Work is like a hill and a lot of it is in figuring out what to do](https://basecamp.com/shapeup/3.4-chapter-13#work-is-like-a-hill). Incentives are not aligned if you delegate with too much structure: two of the primary outcomes you get from delegating to others is exposing people to a learning experience and freeing up yourself to focus your attention elsewhere. 

When delegating with too much structure, you're likely not fulfilling neither. Firstly, learning is limited as most of it comes from figuring out how to break the problem into a solution. By coming up with a set of instructions to get to the solution yourself, context transfer to the delegatee can end up being even more expensive than letting them figure out what to do themselves.

Conversely, framing the problem well and clarifying why it matters usually leads to much healthier dynamics and better outcomes. **By delegating a well-framed problem, you're much closer to exposing the delegatee to learning and getting to an outcome where you have less involvement.**

### Define clear boundaries for the problem you're delegating

Besides framing the problem clearly by defining why it matters, defining the constraints for the problem to be solved, and aligning on the expected outcome are equally important. 

For instance, not being aligned on inputs such as priority and timelines are a recipe for loose accountability and disproportional effort/outcome ratio. By defining the inputs beforehand, both parties can align expectations on importance and effort. 

Not being aligned on the outcome is a recipe for reduced autonomy. The delegator is pushed to delve into details. All the complexity of the problem at hand becomes the main subject in conversations rather than how to maximise the outcome. The delegatee gets squeezed into mostly execution and loses autonomy.

**By defining precise inputs and outcomes, you set boundaries of the problem, which defines a cleaner contract between parties.** As you shift accountability and autonomy to the delegatee, the challenge becomes setting them up for success.

### Manage risk *with* the delegatee, not *for* them

Risk management is a fundamental aspect of delegation. As risks emerge, it's essential to not jump straight to intervention as it comes at a very high cost in multiple ways.

One common failure mode for delegation is offering advice you're not asked for. As much as it may come from a place of care and protection, it will take away from both autonomy and accountability, especially given a situation under pressure. The delegatee is very likely to take the delegator's advice much more seriously in such scenarios. 

The alternative I've found is to manage risk *with* the delegatee instead. Assuming you haven't set up the delegatee for failure by delegating something much beyond their [task-relevant maturity](https://getlighthouse.com/blog/management-concept/), and that you delegated the entire problem rather than a black-box chunk of the solution to the problem, they are in a better position to make decisions. In such cases, **you can manage risk with them rather than for them by being curious, asking questions, and supporting them to reach their conclusions.**

____

This set of principles is notably biased towards successful scenarios. Things don't always go as planned. When that happens, good leaders make people feel like they have a safety net and may intervene if the situation requires; but most importantly, they provide the right combination of learning and support people need to grow and succeed next time.

Delegation is a cornerstone in leadership, and fundamental to scale yourself as a leader. I've tried to synthesise what I believe to be good delegation into three simple principles.

Three simple principles for delegation


A tension in software engineering which has always fascinated me is knowing when to break one into many. There always seems to be this inflexion point, usually triggered by the perception of duplication, understanding conflation of responsibilities or noticing that coupling became a problem.

Similarly, organisations also benefit from this pattern. Signs it might be needed are the same: there's duplication in systems, a conflation of scope and coupling of goals between teams. A common org design solution is establishing a "platform team" responsible for generalising the existing use-cases into one platform, and "application teams", focusing on the specifics of use-cases.

Supporting this type of change can be disruptive for teams, and sometimes frustration comes from defining new boundaries and decoupled purposes. Here are some ideas of how to draw boundaries and support both platform and application teams to succeed.

### What stays in application teams

Defining clear responsibilities for application teams helps defining what a platform could be. A way to understand what needs to be a platform is understanding what shouldn't be one, as this is usually more obvious than the other way around.

1. **Platforms are less likely to solve subjective or nuanced problems well.** Given that a platform's role is serving multiple use-cases, they are usually excellent at solving objective problems. Although, for most problems which ebb on the subjective side, application teams shine much more. For a payments processing platform, there are many tough product challenges to be solved as an application team: when and how to authorise a card, when to retry a payment, when and how often to settle funds, the best day of the month to recur a payment, to name a few.

2. **Context-related optimisation should live close to the context.** Platforms are great at solving the bulk of shared problems, although some of the most challenging optimisation work, especially on large scale systems, is at the context. For a recommendations platform, the context whereby a recommendation is made is hugely relevant for it to be effective, e.g. a recommendation in a product listing page, with low purchase intent vs a pre-payment or upsell recommendation. Whilst platforms can provide table-stakes for optimisation, all the tuning, calibration and meaning of success tends to live closer to the context. In general, application teams are in a much better position to find high-quality signal which is context-aware for optimisation.

3. **Platformisation may affect your user.** Teams can be extremely successful by working very closely with user experience researchers to understand what are their user's specific needs. Sometimes insight generated through research be contradictory in different surfaces or contexts and understanding this can determine how platformisation affects the user. Outcomes from research can range from application teams influencing the platform's direction if the insight is valid across the board, to also reveal that maybe the proposed drawn boundary somewhat impacts the use-case and decide that it is premature to have a platform.

### A new platform emerges

As you understand what stays, what should be generalised gets much clearer. More than a lift and shift of systems, platform teams demand a massive change in mindset. For those unfamiliar with platform teams, they tend to share some characteristics. A notable one is working with multiple customers or stakeholders. That said, a lot of the tension for platform teams is finding the balance between usefulness and staying edge-agnostic – platforms are designed to solve a set of problems well, but not all. Some characteristics I've observed successful platform teams have include:

1. **Think of infra as part of the product – or the product itself.** When a team can't control all downstream consequences of different failure modes, they need to have much stricter SLAs, incident management processes, and business continuity practices. For example, a 99% availability requirement might be acceptable for a payments platform with an average ticket of $10 @ 500k transactions per day – meaning a loss of ~$3.5k per hour. Nevertheless, if the average ticket is on the thousands, that could mean different availability requirements. Being in a platform team demands a shift into thinking that infrastructure is a much more relevant part of the product offering.

2. **Be cautious with assuming equivalences in data.** Especially for data or machine learning heavy platforms, finding ways to compare meaning, standardise and share protocols for labelling or generating insight across the board can be very hard. Even further, it can sometimes be misleading, if you don't fully understand use-cases before sharing data for analysis or training models. That said, a good way to prevent scenarios like this is being conservative of where to draw the platform's domain boundary and start with the smallest value possible. For instance, a product recommendations platform can start with an API that returns probability scores for multiple recommendation types – buy again, also bought, etc – rather than dealing with product ranking, which is a much more complex and nuanced problem.

3. **Think of the platform as capabilities rather than a one-stop-shop.** A way platforms commonly fail is by trying to package all capabilities together rather than providing application teams with a set of interoperable capabilities which they can use as needed. Even though it can be quite convenient to abstract all complexity behind a single API, when application teams don't have access to independent capabilities, they are incentivised to "go around the platform". Instead, breaking logical domains into building blocks can give tenants the ability to extend functionality. [Kislay Verma's post about preventing "go-around" with platform thinking](https://kislayverma.com/platform-thinking/preventing-go-around-with-platform-thinking/) explains the problem and solution very well.

___

As much as change may be positive when you can clearly define each constituent's responsibility, introducing it prematurely can be very harmful. Considering how disruptive a wrong decision can be and how slow the feedback loop is to define whether a reorg has been successful or not, [approaching change through experimentation](https://dballona.com/en/reorganising-teams-through-experimentation/) can help to mitigate risks and make the experience less frustrating for everyone.


Similarly to software, teams can benefit from composition. A common org design pattern is defining a platform team and leveraging it through many application teams.

Composition for teams


Similarly to systems, as engineering teams grow, you get to points where you need to iterate the design and optimise for different characteristics. You also don't want to over-engineer, as optimising for future cases can lead to undesirable consequences. That's a point in time where you might want to consider a team redesign or reorg.

Reorganisations are rarely the only way to solve a problem. In fact, they generally are the most expensive and disruptive way. Although, sometimes, reorganising or redesigning is the right call. Some of the symptoms that might indicate this is something to consider are recurring complex dependency management, an overwhelming cognitive load needed to maintain systems owned by a group of people, increased amount of processes to compensate for poor communication, and so on.

A way to reduce the risks of reorganising to solve a problem and end up creating a few more is clarifying the problem, coming up with a hypothesis, approaching change as an experiment and then sharing your findings, which informs the final decision.

### Before making the decision

First and foremost **clarify what the problem you are trying to solve through reorganising people is**. I believe the default inclination should usually be to not go for reorganising. Most of the times alignment at a higher organisational level, reevaluating ownership of systems or responsibilities and introducing better communication practices or processes can help to avoid this decision.

If you are convinced that you need to do it **clarify which groups of people are affected by the problem**. A way to start is by asking people individually and paying attention to the nuances each person brings. These nuances will serve as input to hypothesis generation.

Once you know who's affected by the problem, collaboratively **generate a set of hypotheses for the problem's existence**. Understanding people's frustrations is usually a good starting point and then asking why this frustrates them can lead you to a good hypothesis. [Liberating Structures](https://reimaginaire.medium.com/what-are-liberating-structures-de6f6d14c2c8) are useful for getting everyone's input free of judgement.

Next up **draw different ways you could organise people to validate your hypothesis** and **understand capability gaps each candidate change would generate**. Reorganising might introduce risks, and for teams, a large factor is team composition. A change like this can make you lose essential characteristics in a team such as specialised knowledge about a set of components, on-call coverage for operating the footprint the team owns, diluted throughput from a delivery standpoint, and so on.

Then, once you collaboratively find some of the best options, **listen to people who are the most hesitant and most excited about each potential change**. This will help you gauge whether the split would be healthy for the new teams and people individually too. Ideally, you want to solve for everyone – the organisation, the team and also each individual. Some people might be unhappy with the proposed change, and strong opposers usually have their reasons which can be insightful and cover blindspots from the group.

### Experimenting with change

Framing change as experimentation takes some of the pressure of succeeding off and is easier to revert from an administrative standpoint, but also morale and expectation management perspectives. **Commit to one hypothesis and approach it as experimentation**. As any experimentation, you need to give it enough time to get accurate feedback as there will be a considerable lag between implementing the change and being able to evaluate its effectiveness.

At the beginning you will likely have more crossed wires, people will be more uncomfortable, quality can decrease, and pace might get slower. **Let it last long enough to build a fair judgement** before making a definitive decision either way to keep or revert. A good starting point is six months to re-evaluate. This time interval will likely match your goal-setting schedule, performance reviews, staffing planning, so giving it enough time will help you understand the consequences of this decision from multiple perspectives.

**Set up a feedback loop with team and external parties**. Getting feedback from the team is fundamental, but it is usually more straightforward, as you might have established communication channels such as 1:1s and team health surveys. It is also essential to understand what are the external impacts, so spending time with stakeholders and peer teams can help to gauge both internal and external satisfaction and act upon it accordingly.

It can be insightful to **re-evaluate if the problems you assumed reorganising would solve are getting solved**. You might feel that, anecdotally, the teams are healthier and performing better, but it is essential to understand why. Looking back and understanding what you thought the motivations for doing it were in the first place can help to validate if you are solving the problems from the initial hypothesis itself or something else.

Considering the experiment is being successful, and the new teams are doing incredibly well, you still need to be aware of external factors. One of them is demand: understanding the future needs and **how demand and supply evolve over the experiment** can be a strong signal to justify either to grow a team further or to be proactively prepared for another plan. The least disruptive way I know of doing this is watching both supply and demand closely and being open about your observations to all parties.

### Making the decision

As you feel like the new experiment has reached maturity, **share your findings internally and open up for discussion**. Will Larson's [model, document and share](https://lethain.com/model-document-share/) can work well for starting the conversation with an informed perspective rather than an authoritative one, especially if you are the person accountable for the team's success where it can be easy to go top-down unnecessarily.

It is also important to recap what you were collectively trying to achieve and how successful you were on doing it. **Set up a retrospective-style meeting to reflect** on what went well, what went wrong, what should change and summarise lessons learned. At this stage, you have the opportunity again to build shared understanding and decide how you want to move forward. Use the outcome of this retrospective as input to what you will communicate publicly.

Next up, you probably have a decision made. If you have any folks who are concerned about the change, take your time to **listen and understand people's individual needs**. Sometimes not everyone will be happy with the change. Unsatisfied people have all the right to want to figure out what future will look like for them, and it is your role and accountability to support them on finding something they will be happy with, preferably within the team or the organisation.

As the next step, regardless of the outcome of the experiment, **make your findings public**. Go back to the context which generated the experiment, how was it approached, what you have learned during the process and share the change with the audience affected by it. If you think the experiment succeeded, Uma Chingunde has a great post on [communicating organisational changes](https://umach.medium.com/communicating-organizational-changes-6277e4b47cff), which is excellent for this purpose.

___

Change is never easy but is usually for good. I believe the most important aspects for successful team reorgs are finding clarity on why, having people's input on the process, and listening to individuals thoughtfully. Again, rarely it is the only answer to a problem, but if you think it is to yours, experimenting before making a final decision can help you manage risks more conservatively.


Engineering teams can grow in unexpected ways like systems do. Utilising experimentation concepts can help find the right design before you fully commit to longer-term change.

Reorganising teams through experimentation


After posting [my takes on posture in system design interviews](/en/posture-in-system-design-interviews) in [TechWriters](https://lethain.com/techwriters/), [David Golden](https://twitter.com/xdg) inspired me to write about calibrations on technical interviews. The angle I'm looking at calibrations in this article is intentionally narrow, as I took a route to talk more about how calibrations contribute to a fairer, more balanced, and as a consequence of that, more efficient hiring processes. For the sake of this, I'm containing the subject of calibrations to two perspectives:

1. How can a group of peer interviewers assess and land onto a shared understanding of who is the best fit for a role;
2. How can a hiring manager increase the certainty that they are making the best hire decision for their team and organisation.

Even though my goal is approaching the subject with as much transposability and objectiveness as possible, calibrating interviews isn't in any means an immutable, transferable or exact matter. Similar to any complex system or concept, this is an overly-simplified representation of the subject as an attempt to make it more digestible. Calibrations are a highly nuanced subject even within the same organisational culture context, and even further for different organisations. Different organisations will expect different outcomes from hiring processes, and covering calibrations to the degree of depth to make it justice would overlap with specifics of the hiring process designed for your organisation, which is out of scope and reach to cover.

### Context & Pre-requisites

For those who are unfamiliar with the term: interview calibrations serve the purpose of finding common ground between interviewers about a candidate's overall performance and then measuring the performance of candidates against each other, so you move forward with the most appropriate candidate for the next step or to a job offer.

Even though interview calibrations can be unstructured, as in just talking through overall impressions about a candidate, approaching it from this angle has a large propensity to go wrong. Hiring managers and the seniormost people in the interview loop are usually well-positioned – even if unintentionally – to influence other's opinions, therefore making the process less fair and more biased if you go fully unstructured.

To that extent, I believe pre-requisites to reasonably calibrating candidates are:

1. **A framework that defines leveling organisation-wide** by outlining roles, expectations and impact for each level – what Senior, Staff, and other roles mean in practice;
2. **A well-defined interview process per level or career track** that is equitably used for all candidates, regardless of circumstances such as referrals or returning employees;
3. For more structured interview stages, such as technical interviews, **a database of questions with clear guidelines** at the interviewer's disposal;
4. **A training program as a pre-requisite for interviewing** covering what matters for the organisation covering from practicalities to D&I and unconscious bias training.

These pre-requisites will help to establish a foundation for objective comparison between existing talent at the organisation, a standardised way to assess candidates, and that interviewers understand how to evaluate candidates fairly.

### The interviewer's role

I believe a good starting point from the interviewers' perspective, regardless of their role, is **studying the framework for leveling people**. Understanding leveling is inherently understanding expectations for a role – and that's a starting point to assure fairness. In other words, further than defining that whoever does x, y and z is Senior Engineer, defining what type of impact and effect you expect these people to have in the role helps to clarify what you are looking for the needs for the open role. Studying the framework helps calibrations as if you understand expectations for a role, you can assess a candidate more objectively.

Next up, **having comparative data and criteria between candidates under different lenses** can be helpful too. In situations where there are constraints such as fewer roles open than candidates passing the interview bar, it can be hard to define who is better suited for the role, especially if different people interviewed them. I've seen this solved in two ways: having more than one interviewer per interview (e.g., one lead interviewer and one [shadow interviewer](https://rework.withgoogle.com/guides/hiring-train-your-interviewers/steps/giving-interviewers-practice/)) or having more than one interview of the same type per candidate (e.g., two system design interviews within the same interview loop done by different people). Both can help to decrease bias and give interviewers more angles to debate, compare and calibrate candidates between themselves through more perspectives for the same criteria.

Another critical task is **defining what is expected as a good outcome for an interview stage upfront**, so you have what to calibrate against after the interview in case you have multiple passes. What "better" means is for the majority of the times relative, so discussing it on the same terms with other interviewers in case of multiple passes will help to keep discussions to specifics. As an example, for a system design interview, you are likely looking for criteria such as "completion", "prioritisation", "depth of knowledge", "breadth of knowledge", "communication", "trade-off awareness" and so forth. Further observation out of scope as a note can help on the overall decision, but to ensure the process works as envisioned when designed is essential to limit grading to the stage's criteria.

To this point, **defining how interview stage performance maps to candidate leveling** can help to inform the decision process. For context, candidate leveling usually takes into consideration the overall performance of a candidate during the interview, plus their previous accomplishments and experiences. That is, the overall performance should be supported by stage performance, which then should be backed by interview criteria. A slightly more tangible example is, for instance, in system design interviews, seasoned engineers are more likely to have a deeper level of awareness of the trade-offs being made compared to less experienced engineers. Understanding what to expect performance-wise for each interview stage for each level can help to make the decision fairer. Be mindful though that turning the assessment into an exclusively objective or mechanical process is not desirable too, which brings us to the next two points.

You likely won't need to make a decision exclusively given the signals gathered in the interview stage you conducted. That said, **giving candidates the benefit of the doubt by default** can be a compassionate way to speak of someone's abilities that you barely know. Interviewing is a stressful experience, especially when the candidate really wants the role. Instead of pretentiously judging whether someone is fit or not for a role, understanding the interview as a snapshot of behaviours observed helps to keep yourself open to being convinced otherwise – both to favour hiring or to withdraw your hire recommendation.

Finally, if you get to a situation where you have more than one great candidate per role and grading between interviewers for the same interview type reveals a draw, **delegate the decision to other stages**. It is hard to get an accurate picture of one's ability through a 45-minute interview. At some point, the precision for stacking candidates speaks more about your own bias than about their qualities, so leave it for other criteria to drive the decision instead.

### The hiring manager's role

One of the main learnings I've had as a hiring manager is **hiring first for the organisation, then for the team**. Things will go wrong often, regardless of the organisation's maturity. Having a narrow/tightly-fit hiring strategy can backfire dramatically. Good examples of that are a project the candidate was an excellent fit for getting disincentivised or deciding to buy software from a vendor instead of building it in-house. Those are circumstances where calibrations are helpful – if leveling is standardised across the organisation, moving people to their next endeavour is less disruptive for everyone involved.

That said, **resist the urge to think exclusively of the capability gaps your teams have** and your particular needs. As a hiring manager, you obviously should be well focused in your problem space, although people can end up needing more than that to stay or grow within the organisation. Investigating whether similar needs exist somewhere else within your organisation can help to make a more thoughtful decision. Validating your assumptions with peers and aligning potential further remit for your hires before even hiring them can force you to think of what is this candidate's progression path and ensure that you can bring someone with a clear problem space to own. On the flip side of the previous example, if things go incredibly well, this person will have options to pick for their path forward.

**Before deciding for a specific candidate, calibrate them against the leveling framework** to assure you're leveling newcomers fairly. Most companies have situations where levels have overlapping responsibilities and compensation bands. To achieve promotion to the next level, one has to be consistently performing at the next level, so when bringing new people in, you want to level them correctly, but even more so, you want to make sure to make things right for their peers too. In cases where you are unsure, down-leveling is usually the right thing to do as promoting someone within 6-12 months is simpler than demoting them.

A typical scenario as a hiring manager is biasing hiring towards your projects, teams and needs. [This article from Google](https://ai.googleblog.com/2006/03/hiring-lake-wobegon-strategy.html) describes how project/team-driven hiring impacts overall talent quality. As the hiring manager, what you can do to that regard is **calibrate candidates against their potential peer group**. Doing this can help to achieve similar results in talent quality terms to the strategy used by Google. Think of adjacent teams or organisations who have people on the same level that you're hiring for, within the same discipline, and understand the peer group duties, impact, and responsibilities. Doing so will likely reveal how this candidate would fit into the overall picture, thus assuring talent quality across the organisation.

Furthermore, **calibrate interviewers against each other, so you have a weighted average as a measure**. Different interviewers have different criteria to assess people, even with a well-set frame. I have the impression that I tend to often ebb on the bright-side. Others might be much more conservative to risks and tend to recommend "no-hire" where I make " hire" recommendations. The vast majority of application tracking systems have [calibration reporting](https://help.lever.co/hc/en-us/articles/206403385-How-can-the-Interview-Calibration-report-help-me-identify-bias-in-interview-feedback-) which can help to understand how interviewers tend to grade interviewees who got offers, and this can serve as a signal to gauge overall performance quantitatively without going too deep into analysis.

Then, for split decisions, where interviewers have diametrically differing opinions or the uncertainty level is high across multiple stages, **increase alignment and consistency by hosting an interview packet review meeting**. This type of meeting usually consists of bringing all interviewers that attended each stage of the candidate's interview process together, build consensus, and then make a final decision. Usually, it is an excellent opportunity to understand where there might be ambiguity for a criterion within an interview stage, to give feedback to interviewers and receive feedback about the candidate and process, and as a consequence of that,  improve the process and make fairer and more accurate decisions.


___

As previously said, this is just the tip of the iceberg – software engineering interview calibrations are a fascinating subject which likely will require cross-disciplinary efforts from people teams such as talent acquisition and human resources as well as technical input. To assure fairer calibrations and hiring, it is fundamental to continuously assess, measure, and through quantitative and qualitative signals evolve the process.


Assessing who is the best candidate for a role is not a straightforward task. Many parties play a role, and sometimes there are conflicting interests. Here's a take on how to make calibrations more consistent.

Engineering Management