
*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, in May 2022, about how to navigate this very common career lateral movement.

Navigating the engineer to engineering manager transition


Trust is a foundational ingredient of any healthy relationship. Maybe because of this foundational quality, people tend to think of trust as an aspirational state of unwavering robustness, when in reality, trust is messy. It will be put to the test, most of the time in unintended ways. Then, if your expectations ebb too much on the side of this unwavering robustness, you will quickly find yourself in a state where you don't trust anybody and deprive yourself of human connection and authenticity.

Perhaps the target state for trust is an antifragile system? For the sake of definition:

<Quote quote="Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. Let us call it antifragile. Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better." author="Nassim Nicholas Taleb" />

It's unlikely one will build trust through volatility, randomness, disorder and stressors. Probably the opposite will work better to build it. You also don't want to inflict such phenomena on any relationship intentionally. However, it is naive to think it is avoidable.

With trust established, genuinely trustworthy relationships get stronger and better in the face of unexpected adversity. Therefore, trust is antifragile.


A note on how trustworthy relationships can get better through unavoidable volatility, randomness, disorder and stressors.

Trust is antifragile


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  exemplifies what I mean by the "consolidation" pattern.

### 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.*


Platform patterns is a series about how to use patterns for building platforms. The consolidation pattern consists of merging scattered capabilities into a platform team.

Platform patterns #1: Consolidation


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.


Managing teams which you lack technical understanding can be challenging. In this article I talk a bit about what has worked for me before.

Managing engineering teams outside your 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. In this article I explain why my take is it's more about enablement rather than control.

Performance enablement


Especially in large companies, organisational design may not reflect the product you're building. As much as you try to align people to problems, there will eventually be distributed expertise across the company. As different teams may have different priorities, alignment across organisations becomes a very valuable skill to have.

<Image src="/assets/uploads/2021-10-29/boats.webp" alt="Boats in alignment" caption="Picture by Simon Micheler on <a href='https://unsplash.com/photos/kALqjIawiv0'>Unsplash</a>" placement="default" width="450" height="300" />

### What creates misalignment?

Misalignment, for most of the time, is unintentional. In a healthy culture, most people will want to support and enable you to ship your product. Although, there's only so much you can do when you are focused on things that you believe are the most important and have no additional bandwidth left. Some of the main reasons I've seen teams get stuck in misalignment include:

**Diverging prioritisation.** Teams should have the autonomy to set their priorities. Sometimes there will be disagreement in how high a shared project ranks in the roadmap of different teams.

**Disproportionate or unilateral funding.** It's not rare to have organisations working in similar domains being funded through different cost centres. What may happen is that funding happens for one side, but not for the other, or, on a lighter version and not necessarily less harmful, there are disproportional investments in both sides. In short, there's an asymmetry in the ability to execute against the original plan.

**Increase in scope given iterative discovery.** Even when planning cycles are perfectly aligned, discovering a larger opportunity due to research, data, or customer insight after planning deadlines may mean you have less flexibility to pivot.

While you likely can sort out this type of misalignment tactically, for instance, by persuading a partner team to bump a priority or trimming down the scope to fit the initiative in both teams' capacity, repeated behaviour can make both sides feel stuck with each other. I believe the root cause for this kind of situation is very frequently in either lack of shared understanding or disagreement in broader-level prioritisation.

### Getting to a shared understanding

John Cutler has a very good take on [what is shared understanding](https://www.productplan.com/blog/build-shared-understanding/). Rather than "short-lived alignment", shared understanding is a state of alignment through direction rather than a destination. Some of the common traits I've observed in teams who have this type of long-lived alignment are:

1. **Shared purpose.** Even though it might sound obvious, it is easy to neglect whether or not you have a shared purpose for collaborating. Collaboration is not always the answer – you can probably name multiple companies which survived large-scale duplication for the sake of speed of execution or to avoid premature optimisation. If you choose to collaborate, though, the purpose should be clear. You can define a shared purpose by writing a joint vision statement, or even further, a joint product strategy. There are many great resources on how to do it ([this article by Melissa Perri](https://melissaperri.com/blog/2016/07/14/what-is-good-product-strategy) has a very useful canvas). If you lack ideas on where to start, a good starting point to find a common thread is facilitating a session where both teams abstract previous and future shared projects into themes together.

2. **Clear outcomes.** One level down is trying to understand what you're effectively trying to get from the collaboration. Do different teams contribute to different parts of the puzzle? Or maybe both teams play together a balancing act such as [metric/counter-metric](https://lethain.com/goals-and-baselines/)? The expected outcome should be specific, but not to a project (short-lived), but to the collaboration between the teams itself (long-lived). For tangibility purposes, consider two teams, one accountable for intake (customer acquisition) and another for quality (retention, user experience). Everyone will likely agree that low quality is irrelevant for a product without customers, and intake is irrelevant if every user churns because of low-quality experiences, but what means success for this group? In which proportion each role should be played? It could be, for example, meeting revenue goals without decreasing retention by more than 2%.

3. **Collaboration model.** Equally important, every collaboration needs well-defined ways of working. You want to avoid a situation where you need to rediscuss accountabilities, how to measure progress towards the outcome, and how to deal with eventual risks for every new project. The collaboration model is a set of expectations on how do you operate the two teams as a broader team. Some good practices I've seen include:
    - Formalising a "virtual team" with some representation of both teams and exclusive commitment or high priority for a longer timeframe than a planning cycle. Doing so helps not only with focus but also with effectiveness as people will gel over time;
    - Using [RACI matrixes](https://www.cio.com/article/2395825/project-management-how-to-design-a-successful-raci-project-plan.html) to align on who does what. They help to unveil misunderstandings on accountabilities and prevent communication gaps;
    - Defining how to measure progress together. It could be through metrics, a set of "ship" goals, or by untangling a big unknown into smaller unknowns. The end goal here is for the joint team to hold each other accountable for progress and have clear expectations of milestones over time.
    - Creating appropriate forums for decision-making, discussing risks or blockers, or any other unstructured subjects. Doing so prevents having to catch up with different people on why a decision was made, or which trade-offs were discussed, as the group is always part of these discussions.

Assuming that everyone agrees about purpose, outcomes and how to work together, and the ambiguity about priorities, funding and opportunities is likely to go away. When prioritising, different teams share a sense of the prioritisation criteria, funding dependencies are well known and can be flagged by both parties, and everyone will be happy to shift projects if new information comes in, as there's alignment on target outcomes. The overarching point is that alignment only lasts if it isn't made at the project or workstream level (short-lived) but at the team/organisational level (long-lived).

Sometimes, though, disagreement exists in principle.

### Framing disagreement for alignment

More often than not, people are afraid of disagreement, and it can be uncomfortable, especially when you have two groups of people who are very convinced that they're right. Although, worse than disagreeing is not reaching to a conclusion. The best way I've seen people untangle this type of situation is to frame the disagreement together by agreeing on the fairest representation of reality and escalating it up the reporting chain in the form of a [traffic light decision matrix](https://www.linkedin.com/pulse/decision-making-101-traffic-lights-puppy-case-study-valerio-magliulo/). This is how it works:

1. **Pick a list of criteria:** describe what the dimensions you're trying to get a decision on are;
2. **Have each team define one option**, and define how it affects each criterion;
3. **Represent the trade-offs you are making** by colour-coding each cell of the *Criteria × Options* matrix.

The result should look like something like this:

<Image src="/assets/uploads/2021-10-29/traffic-light-matrix-en.png" alt="Example of a traffic light decision matrix" caption="Example of a traffic light decision matrix" placement="default" width="710" height="400" />

Rather than spending weeks in convincing, which can be extremely painful, asking for help is usually the fastest way forward. By fairly representing the situation together, teams will help both reporting lines to be in a position to make the best decision. As a potential side-effect, there might be alignment on the suitable trade-off for other similar situations in the future.

____

While this is an oversimplification of the subject, finding alignment across organisations can be very useful. Organisational boundaries help to increase cohesion, but the most successful folks I've worked with [do not "ship the org chart"](https://twitter.com/stevesi/status/1275311075508936704) and try to build cohesion beyond reporting lines.


Finding alignment across organisations is an invaluable skill. Here are a few ways to get to a shared understanding, and frame disagreement to find alignment.

Alignment across organisations


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. 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, platform and application pattern


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 on such scenarios.

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 in any means a straightforward task. Here are some of my takes on this subject.

Calibrations for software engineering interviews


If I had to pick only one interview method to assess engineers, it would likely be system design. That's not because coding, behavioural, role-play or case interviews are less valuable – they are revealing and help to build a bigger picture of the candidate. If you have resources to create a process that will support diversity, a fair framework to avoid bias, and the time, people and training to run a multi-stage process it will likely reduce the propensity of false positives. Nonetheless, if I were constrained to pick just one, I'd pick system design.

I find the mix between subjective and objective criteria that the system design interview imposes very useful for assessing candidates from multiple angles. There is a reasonably well-set frame for technical assessment, but just coming up with a solid design is not necessarily a pass. Similarly, candidate behaviour has a vital role to play, but the lack of causal nexus and technical-ability can reveal lack of fit to the position quite clearly.

There's a lot of resources out there which are an excellent foundation for the more objective parts. I curated a few of my favourite ones in the [appendix](#appendix) of this article. These deserve great focus when studying for an interview, as they are the most fundamental part of the assessment being made. However, having undergone some interviews recently and practicing it, I thought I'd write about a few points I have learned and that I believe can help on the subjective aspects of it, especially in regards to posture.


### Don't just communicate: collaborate with the interviewers

One of the things I find very helpful in technical interviews is turning it into collaboration rather than just an assessment. The role interviewers are trusted to play fundamentally is assessing whether a candidate is a good fit to be a colleague of theirs. I believe that when you achieve a collaborative atmosphere at the interview you are giving people a much better perspective to assess your fit fairly.

With that in mind, once the interviewer shares what the problem to be solved is, a technique which can help is **rephrasing the objective in your own words.** I find this helps to avoid situations where you presume understanding what is being asked. It is much better to clarify with the interviewer than design the right solution to the wrong problem. Ask questions as obvious as they can sound, and try to engage in gathering all the information you can before proceeding.

As the objective is better defined, it is essential to **establish what is in scope and what is out.** Narrowing down what are the scope boundaries for the interview problem will help you to focus on what matters the most for the design in question. Making compromises on scope early on will prevent you from spending the very little time you have on going deep in off-scope topics of the problem at hand.

When you infer information from what you are told, or when you reach to a conclusion **voice your assumptions and conclusions.** You need to bring your interviewers to see the problem from the angle that you are looking at to make a fair judgement if you are going off track and nudge you on the right direction if it needs to be.

Then, when working on the proposed solution, **avoid turning the experience into a monologue by leaving spaces for feedback**. Interviewers are usually fine to signal when you might be going off-track. Have them contribute to the discussion even if in a non-verbal way, regardless if it is about implications of the design decisions you are making and why, or if it is more specific such as whether you should split a component into two.

In summary, communication goes a very long way for technical interviews. Even further, actively seeking collaboration improves your chances of performing well in the interview, and also helps interviewers gauge whether they would like to work with you – and vice-versa.

### Go wide first and then deep afterwards

It is easy to go deep prematurely as design interview questions are unlikely to fit within the timespan available, conversely to a coding interview, for example, where the problem likely fits within the time available. Nobody will expect you to come up with the perfect solution for a system which is run by dozens, hundreds or even thousands of people – although ideally, you should have a rough sketch to solve the problem end-to-end.

As in real-life systems, the design will evolve. Done is usually better than perfect. **Start simple before going complex by favouring extensibility rather than perfection**. Put forward the most straightforward design which won't pose obvious scalability issues first, while keeping the interviewer informed of your strategy, and then as you cover the requirements, get into more in-depth optimisation.

A way I have found to frame the problem at the right level at the starting point is to **put yourself in the shoes of the user of the system you are about to design.** Basically, talk with the interviewer about the steps the user would take to use the product/system you are designing for the features in scope. Being mindful of the user's needs will help to clarify the characteristics of this system, for example, what are the capabilities which will need public-facing APIs, which components will have higher reads vs writes, or when to ebb on consistency over availability. Looking into the system from a user experience perspective usually hints what is fundamental and will help define a few whys further down the path.

Once you feel like you understood the whole picture, came up with a high-level design and have shown the interviewer you have a hold of the overall problem, pick the part which you are most comfortable with to go deep and explore it. **Focus on your strengths rather than your areas for development.** Most likely, the problem at hand has some exciting scale challenges for any discipline. Pick your favourite aspect of the problem that you can speak deeply of, regardless if it is client-side bandwidth optimisation, data model and partitioning, machine learning infra automation or whatever you want.

That said, resist the urge to get into the detail before you fully understand the problem. Attaining the conversation to motivations and expected outcomes first will help you make more assertive design decisions and make a few whys more evident to both you and the interviewer later.

### Talk about caveats and edge cases

What will happen if your system stops sending data to a downstream system? How do you notify upstream systems to rollback something which was mistakenly changed? How does the system work for the 99th percentile of your power users? These are all questions which can influence your design choices, so thinking of what could go wrong gives you either the opportunity to change it or to confirm that you made the right design decisions.

Especially in large scale distributed systems, you usually will have to optimise for specific characteristics. That inexorably introduces unwanted behaviours – which you need to be aware of to make the right decision. **Talk about trade-offs you've made and why** you chose an approach instead of all the other options you had.

Further, **exploring failure scenarios and recovery options** will show you understand the design that you have committed. This can get especially interesting when you can cover not only system failures but how users could abuse the system, which potential risks are introduced that you will have to accept, or even human error. When possible, talk about how you recover or prevent these from happening.

**Talk about how to make things right when things go wrong**. One example of this is a personal experience where I overestimated capacity in one interview – instead of going with 1GB storage for a free-tier product quota, I went with 1TB. I realised it later in the process, as storage and bandwidth started to feel absurd for the problem at hand with the volume the interviewer and I had committed to. After acknowledging something was wrong, I spoke about the steps I'd take to revert the mistake if this went live such as keeping users who signed up to the 1TB proposition with the benefits they paid for indefinitely, talking to teams responsible for advertising and intake about the mistake, and other damage control activities that could be done. I think this turned out to be an even more interesting conversation than it would be if I had calculated the right capacity at first.

In short, things will go wrong at some point – displaying readiness on walking the not-so-happy path will increase your confidence in your design choices, and if you made a wrong decision, you still have time to adapt and make it better or at least acknowledge it.

### Touch on adjacencies of the problem

Again, given the system design interview is extremely time-constrained, you need to be mindful of what you want to emphasise. Whilst it is great to have a narrow scope to work through, touching lightly on adjacent topics to the design itself can show even further breadth of knowledge. Here are some examples of subjects to cover, which might be off-scope but can increase the number of signals, thereby increasing your chances of performing well.

I believe most engineers appreciate that operating large scale systems is very hard. I personally like to **cover operations, not only design**. Especially at large companies, where you usually have dedicated infrastructure engineering functions, it is easy to take a lot of ops for granted. Briefly talking about subjects such as alerting, monitoring, tracing, observability can reveal problems on scaling a specific design.

Especially for highly regulated environments such as payments and abuse prevention, touching on **security, compliance & regulatory constraints** can be a plus. Some ideas of subjects to touch upon are data retention or data anonymisation for systems with personally identifiable information, or risk management by splitting components in different networks which are in scope for audits.

Maybe a subject more on the technical leadership or management side, design decisions will inherently dictate how teams will be mobilised for specific domains. A pretty large upside of microservices is making scaling independent – people and organisational design included. Talking about how the design will likely impact **how you mobilise folks in the set of teams owning the design** and showing awareness of scaling not only infra and systems but also organisations can spark engaging conversations.

My examples here are highly biased to my own experience, but making a short aside whilst you cover something within the scope of the interview can serve as an additional signal and increase the interviewer's confidence in you.

___

In closing, it is worth noting that all of these tips are based on my own experiences and preferences. Different organisations will focus on different things, and your best starting point is understanding the expectations of the company you are applying to. I believe incorporating the topics above to my posture when interviewing has helped me, and I hope it will help you too.

___


### Appendix

Below I've added a small appendix for some resources on the technical side of things. I hope you like it!

- [Grokking the System Design Interview](https://www.educative.io/courses/grokking-the-system-design-interview) course by [Design Gurus](https://designgurus.org) at educative.io;
- [Designing Data-Intensive Applications](https://dataintensive.net/) book by Martin Kleppmann;
- [System Design Primer](https://github.com/donnemartin/system-design-primer) by Donne Martin;
- [High Scalability](http://highscalability.com/all-time-favorites/) blog;
- [How the Web Works](https://github.com/vasanthk/how-web-works) by @vasanthk;
- [SuccessInTech's](https://www.youtube.com/c/SuccessinTech/videos) YouTube channel;
- [TechDummies'](https://www.youtube.com/c/TechDummiesNarendraL/videos) YouTube channel;
- [How we've scaled Dropbox](https://www.youtube.com/watch?v=PE4gwstWhmc) video;
- Amazon's [DynamoDB](https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf) paper;
- Google's [MapReduce](https://static.googleusercontent.com/media/research.google.com/en//archive/mapreduce-osdi04.pdf) paper;
- Google's [Hypertextual Web Search Engines](http://infolab.stanford.edu/~backrub/google.html) paper;
- Google's [GFS/Google File System](https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf) paper;
- Facebook's [Cassandra](https://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf) paper;
- Facebook's [TAO, a social graph data store](https://www.usenix.org/system/files/conference/atc13/atc13-bronson.pdf) paper;


Some ideas on how to perform better in the behavioural and subjective bits of my favourite technical interview type: system design.

Posture in system design interviews


I've been a lot more interested in language lately. That's likely due to the fact that I spent some time with other people who talk about the subject often. As a consequence of this, I have paid more attention to how powerful it can be for multiple purposes.

Take the video below as an example. Jacob Collier explains harmony in music to a variety of audiences, starting with a 7-year old and ending with legendary jazz musician Herbie Hancock:

<Video id="eRkgK4jfi6M"/>

I love how in just a few seconds, Jacob can explain harmony in an appropriate language to many audiences, ranging from no technical expertise in music (see 00:00 to 1:05) up to meta-language (see 11:00-12:00). At the final stage, the interactions are wordless – yet, communication is still very much there. That is language's primary purpose, [communication](https://en.wikipedia.org/wiki/Language).

I can't help but draw a parallel to technology, especially when we live immersed in terms, concepts, abstractions which are non-trivial to be understood, such as harmony in music. With this said, there are some areas where language can help engineering teams to be more effective and communicate better.

### Cohesion between team and stakeholders

I think the best example I had in my career so far when it comes to language impacting a relationship with stakeholders and business outcomes was when I was exposed to payments systems for the first time. Trying to make sense of all the domain-specific terminology was terrifying. I remember trying to make sense of card authorisation, capturing funds,  clearing funds, settlement, reversals vs refunds vs voiding, chargebacks... it was even harder trying to understand how these are connected when my stakeholders would articulate the same concepts in multiple different or interchangeable ways.

My main takeaway from this experience was that **learning something new can be challenging, but when language is loose between business and technical folks, it makes everything much harder.**

My favourite approach to this problem is [Eric Evans' on Domain Driven Design](https://www.amazon.com/exec/obidos/ASIN/0321125215/domainlanguag-20). Here's a summary, in my words, of how he describes this problem in the book:

- When stakeholders and technical teams do not share language you have serious issues, as each group builds its understanding in a siloed manner;
- Because each party has its language, translation is expensive at best, or incompatibilities are unnoticed at worst;
- This situation ends up bleeding into system design and code, which may render technical jargon or domain-specific concepts incomplete or wrong;
- And to the same degree, language used by stakeholders doesn't serve the technical team's needs, leaving both in further isolation from each other.

The proposed way to solve it is what Eric coined as _Ubiquitous Language_: having a shared language which articulates a [domain model](https://en.wikipedia.org/wiki/Domain_model) in a simple, concise manner, without leaking implementation details or excessive domain-specific jargon. Everyone uses and plays a part in building this shared language. **The outcome is a language which you can use everywhere as it is representative of the domain at the right level of granularity and abstraction** for any context, hence useful for both technical teams and domain specialists.

Even though not related to a stakeholder/engineering team relationship, _Ubiquitous Language_ can reduce the learning curve for onboarding, support internal talent mobility, facilitate inter-domain knowledge sharing, and lower the bar for engineers to have a broader impact within a domain.

### Goal setting and accountability

When it comes to setting goals, it is common to use a combination of expected impact and measurable outcomes to achieve that impact. [OKRs](https://www.whatmatters.com/faqs/okr-meaning-definition-example/) are a great example of how to do that. Here are some ideas on how to improve a goal through language.

Firstly, **the benefits of achieving a goal should be obvious.** If it is hard to articulate the value yielded by achieving a goal, this could potentially be solving for the wrong problem, or just be masking the symptoms of a problem. It is even harder as part of a team, as there is a natural inclination towards confirmation bias and herd behaviour and the other team members can easily empathise. When challenging whether or not this is the right problem to be solved, one technique that can help is [five whys](https://en.wikipedia.org/wiki/Five_whys).

**To make the goal itself obvious, language should be simple.** To achieve that, avoiding overly technical terms, acronyms, component names, nicknames/aliases, business/domain-specific language, or lingo someone outside of your team wouldn't understand can help. Using such terminology in the context of extremely technical teams is fine as long as that's a conscious trade-off, as if someone new joins or there is a need to articulate the goal outside of that team, it will be harder to make the goal informative to them.

Moreover, **a goal should be opinionated and outcome-focused instead of output-focused.** An excellent read about this subject is [Phil Calçado's article on how he approaches OKRs](https://philcalcado.com/2020/01/31/how_i_like_to_use_okrs.html). Drawing the parallel of using KRs as the test to the Objective is very interesting from a language standpoint as there is an inherent opinion of what achieving the desired impact is through the choice of measurable results.

Finally, **goals shouldn't be bendable.** As a result of ambiguous language, I have seen goals be relativised unintentionally. Language should support accountability and keep the team honest about what success looks like. Ways to remove ambiguity include the choice of words for an objective and key results as previously described, but also the options on how to grade key results on review sessions. Common ways to do it are through a boolean outcome ("yes"/"no") which has less inclination to ambiguity, and percentages (x% completed) or statuses (completed, pending, in progress) which have more tendency to ambiguity.

In short, **a well-written goal has an obvious upside and is written in simple language**, has an obvious why, one or a set of obvious "how much"s, and should communicate what success looks like very clearly.

### Metrics and baselines definition

Metrics are a fundamental part of goal setting, but goals also implicitly call for focus. **It is hard to articulate a metric concisely while capturing all the nuances of that measure** such as supporting metrics, baselines for competing metrics, or upstream or downstream consequences of optimising for a specific goal.

Nevertheless, it doesn't mean that a metric that isn't driving a goal isn't relevant. Not paying enough attention to supporting metrics or competing baselines might set you off course by meeting the target which you expected in a goal, yet not delivering the value which you expected. As [Goodhart's law](https://en.wikipedia.org/wiki/Goodhart%27s_law) explains well:

<Quote quote="When a measure becomes a target, it ceases to be a good measure." author="Charles Goodhart" />

To exemplify, imagine a hypothetical situation of a set of teams responsible for onboarding new users to a product, with the goal of "increasing the number of registered users by 20% within the first half of the year". When over-indexing on lead quality, there is increasing friction through identity checks, which will increase churn and turn into additional cost upstream, on advertising for lead acquisition. On the other side of the spectrum, there is over-indexing on intake, which then will incur into fraud costs downstream for misuse of the product, or additional operational overhead for terminations for fraud reasons.

**A way that language can help is creating a new metric**, let's call it for the above example "genuine registration" **which takes into consideration both baselines** – keeps identity check churns at <5% and identity fraud declines at <0.1%. The new goal would be "increasing the number of genuine registrations by 20% within the first half of the year". That's a much more transparent metric: adding sign-ups while maintaining quality and intake at the same levels. As a complementary effect new metric is now attainable to the domain that set of teams owns and can help with focus with what must be done:

- What could be done to improve the user experience when signing up?
- What can we do to reduce friction or churn when signing up?
- Which other ML fraud model features we can use for predicting fraudulent behaviour when signing up?

This technique turns out to be helpful not only when you have associated baselines, but also when you have implicit supporting metrics or a complex definition where value comes from. A great example of this is [monthly active users (MAU) and daily active users (DAU)](https://en.wikipedia.org/wiki/Active_users). Every product will have its  definition of what "active" means, such as product usage or engagement time. You can dive in if you want, or just get the information that you need from the word "active" itself.

An interesting read about baselines is [Will Larson's article on Goals and Baselines](https://lethain.com/goals-and-baselines/) where he explains similar dynamics to the above and a different approach to goal setting which I found very interesting.

___

In closing, as Jacob Collier shows incredibly well in the video at the beginning of this article, language is most effective when it is considerate of the audience. It will take different forms and shapes in different settings. The most exciting part of this journey is being open to trying and figuring what works out together.


A take on how to overcome problems engineering and product development teams face with stakeholders, goals and metrics through language.

Language as a tool for engineering teams


Earlier this year I was introduced to [Radical Candor, by Kim Scott](https://www.radicalcandor.com/the-book/), amidst an interview process. The book is a gem on leadership and management, regardless of at which stage in your career you are at and if you effectively manage people or not.

The first part covers a set of anecdotes from executives at large organisations such as Google and Apple – including Kim herself, whose experiences include leading hundreds of people in her tenure at Google. Then, the second part is more actionable, with tips on how to put it into practice, and how to effectively execute what the anecdotes touch upon.

After reading and digesting it, I thought I'd share my three favourite reflections from the book.


### Reflection #1: Challenging is, effectively, caring

The main framework on the book relies on two dimensions: _Caring Personally_ and _Challenging Directly_, splitting people's behaviour into four quadrants. Kim uses anecdotes which exemplify the side effects of over-indexing on any of the dimensions: _Ruinous Empathy_ when you care, but don't challenge, and _Obnoxious Aggression_ when you challenge without really caring. When your behaviour lacks both, you are falling into _Manipulative Insincere_, and finally, when you excel on both, you achieve _Radical Candor_. It's worth noting that these behaviours are transient, meaning nobody fundamentally _is_ any of these, but instead, _expresses_ these in different situations.

<Image src="/assets/uploads/2020-09-12/framework.jpeg" alt="The Radical Candor Framework" caption="The Radical Candor Framework" placement="default" width="450" height="300" />

As you know, it really can be tricky to challenge your boss. This natural pullback can come from multiple places, for instance, overarching cultural differences, such as coming from a context where hierarchy is overly respected. It can come from the fact that you belong to one (or multiple) minoritised groups. It can come from the fact your work environment and past experiences didn't allow for candor to flourish. It can come from fear of judgement, lack of confidence, or from feeling that your opinion is less relevant than others in the room. The list could go on, but bottom line is that it isn't easy to get started.

My main take on the subject is that firstly, **as a leader you must incentivise and reward challenge, but not only that, you should help people to challenge you and each other**. Challenge will most likely start with a subtle note, or one can be dancing around the subject to tell you something they didn't agree with. People will give you signs that they're trying to disagree with you, and it is your responsibility to help them to challenge you when you think they are trying to.

Further, **we only argue for things that mean something to us, the ones we don't care about we just dismiss.** If people are voicing their opinion out is because _they care_, and that's the most important quality you can have from anyone in your team. The best teams I have ever worked with had a strong sense of pride, belonging, and giving the team the ability to change your course comes with effect way more valuable than attribution, or ownership of a solution: it provides the team with a shared purpose.

Finally, that shouldn't be a manager-report thing. Peers should be able to challenge each others' work or behaviour, and that is usually a very good starting point if you don't feel comfortable challenging up. **Increasing cohesion from a culture standpoint by challenging sideways can be a great step towards challenging upwards.**

In conclusion, the framework in the book helped me to further bring to consciousness the extent that the two dimensions (caring and challenging) are entwined.

### Reflection #2: Clarify to get to the real meaning

Another tool the book offers is the [GSD Wheel](https://www.radicalcandor.com/4-ways-help-new-managers-succeed/). The _Clarify_ step caught a lot of my attention. In short, this step explains how important it is to let ideas breathe, and give them time to reach maturity before debating, so you don't cut it off too early or too short. The section starts with a quote:

<Quote quote="It is only by selection, by elimination, and by emphasis that we get at the real meaning of things." author="Georgia O’Keeffe" />

What I got to is that _selection_ helps to pick the right balance between known and unknown, and how much of each one of these ingredients to allow for each circumstance. That would be something like defining the appetite for effort and risk. Another way to think of it is a highly successful product which seems to have very few features. What happens there is that it usually slices a part of a problem, and focuses on **solving that problem and its adjacencies incredibly well**, whilst being very opinionated about what it shouldn't and doesn't do. That brings us to the next point.

_Elimination_ is about defining the boundaries and thresholds, or in other words, **what you are not solving for at the time.** Good examples of elimination are:

1. **Clearly articulating rabbit holes:** we are doing A and B, but we don't know much about C and how complicated it will be, so let's leave it out until we know more;
2. **Defining domain boundaries:** we'd love to have this feature, but we believe it should live somewhere else other than this domain, so  we'll give it some more thought;
3. **Trimming scope down:** through X and Y we'll achieve 85% of a key result we're trying to get to. We'll leave Z out for the time being as it increases the complexity of X and Y drastically and can compromise their delivery;

In short, _elimination_ is about reducing noise from your message, so you don't dilute it with less relevant things. But is saying enough "no"s sufficient?

Most likely no, and that's when _emphasis_ is important. Emphasis is about **doubling down on what really matters for the slice of the problem you are solving**, so you increase the chances of success. Just saying "no" to a set of things doesn't guarantee that someone will know exactly what you mean, so intentionality, consistency and repetition are important so you can make your message more relatable, reach a broader audience, and make sure you clarify what you are in fact doing.


For the sake of comparison, some anti-patterns to this I could think of are:
- **Selection**: over-indexing on customer needs and ending up in a situation where you lose the thread of your own strategy;
- **Elimination**: not having a strong stance on saying enough nos, and leaving too much room for misinterpretation;
- **Emphasis**: going too wide too early or having an overly abstract strategy, lacking opinion on tactics, making it hard to attain.

Having this frame helps to clarify whatever you are doing in a simple, yet powerful and opinionated way, _to get to what you mean_ – which by the way is the book's subtitle.


### Reflection #3: Context awareness is key for development

Another subject which I found fascinating was [career conversations](https://www.radicalcandor.com/how-to-have-career-conversations/). This is the structure proposed by the book:

1. **Start with the Past:** Go through the person's life story;
2. **Talk about the Future:** Talk about their goals, or preferably, their aspirations;
3. **Plan for the Present:** Put together the action plan;

What I tried doing in my team's last development cycle is putting forward their development plans using this structure.

_Start with the Past_ feels similar in format to [topgrading](https://www.greenhouse.io/blog/what-is-the-topgrading-interview-process), but with different purpose: instead of evaluating values and fit, **understanding drivers and motivations for each event in their lives**, such as:

- Why did you pursue a degree in X? And why did you drop out?
- What made you pick a job at Company Y over other options?
- What was the most pleasing project you worked on at Z?

The main goal is finding patterns, for instance, leaving a few places because of lack of growth opportunities, and mentioning a project which felt like a massive leap in their career might belong to a driver named _Seeking Growth_. That'd be different, let's say, to someone being driven by having a large impact. There's a difference between these motivations as the former is driven by progression and the latter by the outcome. As a side note, for senior team members, who may have decades worth of experience, instead of looking at specific tenures, I recommend grouping roles into cycles which you define together instead.

As you get to 3-5 drivers, writing down a few questions based on each driver might help, such as: _what are the largest opportunities we have here for you to grow and why?_, for _Seeking Growth_. Later, when you and the person are defining what the opportunities for the present are, these questions can be insightful.

I love Kim's approach to _Talk about the Future_ as it includes aspirations, not only goals. **Understanding someone's personal needs** reinforces your understanding of their context and helps you gauge and define what are the right set of initiatives for them, at the time. The book outlines an approach around finding 3-5 dreams, such as getting to an influential management role, starting your own business, or winning a sports championship, and then breaking these down into skills you need to achieve them. I personally like the idea of requesting at least one non-work-related objective to have extra context, as well as get to know who you work with better.

For instance, you might discover a huge undertaking a team member will have to move houses, or something they have been working on for years to achieve. Whatever it is, it will help you be a more empathetic leader, as well as guide you on what's really important for them at the moment.

Of course, after having these two inputs, you are in a much more considerate position to put forward a _Plan for the Present_ for anyone. Through this acquired knowledge, you can challenge yourself whether the areas that you expect someone to develop is in line with their own motivations. This awareness helps and supports the whole framework – to have candid conversations while caring personally and challenging directly. At this stage, it is mostly tactics: **finding out opportunities which exist for them to achieve whatever they're looking for.**

___


In summary, Radical Candor was a very pleasing read for me. I appreciated the mix of anecdotes and very attainable tips to try out. There are many more interesting concepts on the book; therefore I highly recommend that you should [check it out](https://www.radicalcandor.com/)!


Three reflections after reading Kim Scott's book "Radical Candor" around caring personally and challenging directly.

Engineering Management