
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.

### Safeguarding 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


A usually overlooked, yet fundamental part of designing high performing systems is capacity planning. I particularly didn't pay much attention to this topic in the past. I had a tendency to only think of it only at a very early stage of designing systems and thought it was only valuable for massive scale systems.

In fact, capacity planning is an incredibly informative exercise. It can help you understand the feasibility of a particular design and can also hint you better options. Approaching it as part of the design process in any considerable change – "considerable" defined as a function of how the change impacts relative scale – can be tremendously helpful.

That said, I thought I'd share some of the basics of capacity planning for system design.

### Clarify the design scope

If you're building a new system from scratch or introducing change, the usual process is understanding what the software is supposed to do. **Understanding [functional requirements](https://en.wikipedia.org/wiki/Functional_requirement), as what features are needed, and [non-functional requirements](https://en.wikipedia.org/wiki/Non-functional_requirement), as constraints the system should abide by** are a good place to start. An example of a functional requirement is adding video upload to a social media post/feed that only supports pictures. A non-functional requirement could be a need that these videos should work in 2g connection.

**Once you understand what the change entails, explore its characteristics.** For instance, observe read vs write ratios. Different systems will need different optimisations because of these characteristics. For example, a news feed will likely have more reads than writes and a wellness app that tracks your activity while exercising will probably be the other way around.

Another set of characteristics that will impact the overall capacity planning exercise are **understanding how non-functional requirements impact storage or bandwidth.** For instance, for a messaging app, choosing client over server persistence for messages will drastically impact storage investment. Nonetheless, it will also have its own set of challenges when syncing up data across devices.

At this stage, clarifying what matters will support defining the best trade-offs and potentially will simplify implementation.

### Estimate a few options

Once you know the scope, you are ready to move to some estimates. At this stage, you likely have a rough idea of which features to pick for estimation. **Your initial measure for quantifying capacity is usually an assumed throughput**, inferred from a similar feature or another number such as daily active users.

Firstly **come up with a ballpark estimate of how much a request costs in bytes.** Rounding up is a good idea to keep figures conservative. Estimates for text should be straightforward as you can assume a set of fields and their sizes in bytes. For object storage, such as images or videos, think of versioning, for instance, the average size of a thumbnail vs full-size, or video in 480p vs 1080p. Note how this interacts with non-functional requirements and which options you have available to fulfil the specification.

**Once you know how much each record costs, think of bandwidth per operation.** Think of how you can potentially reduce the amount of data sent both ways: client to server and server to client. Especially for reads, you usually have opportunities for savings. For instance, instead of fetching the entire record and all of its fields every time, you can likely send a fraction of the content from the server sometimes. Examples of that are truncating content or rendering versions. In short, not every operation will need the whole record so you can factor it and discount accordingly.

From there on it is just byte maths and [back of the envelope calculations](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html). **With the average record size per operation you can get estimate measures** and understand trade-offs for different design options.

### Seek opportunities for optimisation

Next up, optimisation. **A very typical opportunity for storage optimisation is defining data retention.** Not all systems need – or even can, because of compliance – keep data forever. A typical opportunity is looking into data granularity, for instance, aggregating data by a dimension such as time or user. Especially at large scale, an appropriate data retention policy can drastically improve systems performance and save costs.

Another opportunity to reduce overhead is caching. **For read-heavy systems, usually, a small portion of the content gets a disproportionate amount of reads**, and caching can reduce bandwidth dramatically for such cases. There's a myriad of ways you can explore optimisation for reads such as lazily loading content based on what's on the viewport, making use of content delivery networks, incrementally improving video/audio quality over user engagement time, and so forth. These are very much dependent on non-functional requirements as well.

Similarly, you can **leverage caching for write-heavy systems as a way to reduce storage capacity needs**. For instance, in a time-series event-based architecture, omitting writes where there is no state change. Temperature-reading sensors which push updates on a fixed time interval to a server are an excellent example of that. Temperatures aren't prone to change drastically within a short timespan, so you can cache a sensor/temperature pair and only write to longer-term storage when a change happens.

In short, there are many ways to go about capacity optimisation. I believe two key aspects to keep in mind are how optimisation impacts relative capacity, and what you are optimising for.

### Be prepared to operate

Much of the truly challenging work for capacity planning, in my opinion, is in operating capacity. **Sometimes, assumptions we base off capacity planning at the design stage are untrue in practice**. That's why being prepared to operate and thus, continuously plan, is extremely important.

**A good practice for detecting misconceptions is writing some of the assumptions made at the design stage in the form of alerts**. Let's say at the design stage you assume the system will have 20% cache hit, and in practice, you have 5%. Even though you likely will have monitoring in place, the assumption made can slip off. Monitoring the assumptions made previously gives you the ability to act proactively instead of only knowing it on your next infra bill arrives or when an incident happens.

Even though you have ways to rely on data to forecast and know how load evolves, you can't predict every single scenario. To reduce this risk, what you can do on an ongoing basis is **using some concepts of [threat modeling](https://en.wikipedia.org/wiki/Threat_model) to understand which safeguards are missing**, what happens if a certain characteristic changes, or if a non-functional requirement changes. These help to indicate where you might have blind spots.

___

With this said, capacity planning is a deep and fascinating subject. It can inform design decisions, support systems operations, and even help you challenge your initial requirements. Having this as part of the design process can help increasing awareness of the trade-offs you make, and puts you in a stronger position to approach change.


Capacity planning is an underemphasized subject in system design. Approaching it as part of the design process can be tremendously helpful. Here are some of the basics.

System Design: Capacity Planning basics


Despite 2020's macro context, it was a fantastic year for me. I understand my multitude of privileges; I was able to stay safe for the whole year and support my loved ones to stay safe as well. Amidst high entropy and many changes, I grew a lot both professionally and as a human being.

This past year I had to learn again the essential things I took for granted in day-to-day life by moving countries: how to move around the city, how to pay bills, why houses need boilers, where to buy fresh ingredients for cooking and even how to put the rubbish out for collection – the latter being a journey of weeks to get to a conclusion, given we were hesitant to do something wrong and get fined by the council, and well, it turns out that this works exactly as it did in Brazil.

On a more serious note, at work, I've also learned a lot. Being a manager at massive tech companies felt different to me, even though I had experience managing even larger teams. Given most of my experience until then was working in early-stage startups, it felt paradoxical to me to think about how I could do my job well in this new context. Observing how things got done in such large scale and understanding why everything was designed in specific ways was fascinating, and frankly, also intimidating and daunting.

With all that said, I thought I'd share some of my learnings this year. I'll save the rubbish one for later.

### Be curious and assume less

Given that sometimes startups tend to transplant larger organisation's practices, I believed in a lot of these practices blindly. Microservices are the way to go. Good software delivery is deploying faster, including on Friday evenings. Matrixed org design makes teams more agile. All these statements might be true, in some context, and to some extent. **My new canned answer to almost anything is: it depends.**

Let's say you join a team, and their release cadency is every 30-days. One way to look at it is being judgemental and saying that it is likely bad practice. Another way to look at it is being curious and trying to understand why. Things are always uglier in practice than they sound in theory. This team might have all the reasons to do so: dependencies with a vendor releasing software on-premises into your infra, having high availability needs on a small team which isn't spread across timezones. Being curious opens doors whilst being judgemental closes them.

This learning serves the same for relationships with people. Instead of assuming what is someone's trajectory, what they need or want, ask. **Being curious, asking, listening, and trying to approach conversations from multiple angles which are not my first conclusion has helped me tremendously** to unblock people, enable them and honestly, get out of their way too.

### Focus on living the present

When I came to Europe in 2019 to interview at Spotify, I was incredibly intimidated. Potentially passing the interview meant so many things for my family and me. Moving to a new country that I knew very little about, being part of a larger company, deepening my understanding of machine learning and distributed systems... I could go on here.

I was also terrified. I felt as if I had lucked out through the process and now was at the onsite stage. Because I had left my previous role feeling that I had failed people around me, I thought I wasn't worthy of the position at Spotify. So three days before the onsite interview, I saw [a tweet by Jason Fried](https://twitter.com/jasonfried/status/1150507034250530817) about the [The Manual](https://www.amazon.co.uk/gp/product/1545461112/ref=dbs_a_def_rwt_bibl_vppi_i1), a collection of Epictetus' essential teachings. I read it in that same night, and I believe this was the event whereby **I decided I'd focus on what I could control for the next three days, which was myself**. This decision gave me peace of mind to go to the interview and be present, listen, live the moment, and whichever verdict came back that was it.

Even though the first spark for me for Stoicism was this circumstance in 2019, I used the things I've learned from it throughout 2020 uncountable times. I already knew that living in the present was spoken of in many cultures and beliefs, such as Buddhism. Still, I think this specific event made it click for me and now **every time I feel like I'm spinning wheels, I get back to some of the learnings I had through what I've read on Stoicism**, and it always helps me.

### Model problems as systems

**I always have been a massive fan of slicing large challenges up into smaller challenges**. That's a core part of system design, and I always appreciated how hard it is doing it well. What has been new for me about it this in this year was using it consciously as a tool for finding clarity for any situation I cannot digest easily.

For instance, how to resolve a conflict between groups of people who have antagonistic interests. You likely won't find the exact solution to your problem by googling. Although, I learned that breaking any problem into smaller problems helps. Observing what each constituent is optimising for, what goal they're seeking, how they get their feedback to reach their conclusions makes it much easier to come up with a hypothesis on why things are how they are, and then experiment with change.

**I learned there's a large field of study for this called [systems thinking](https://en.wikipedia.org/wiki/Systems_theory)** and it is not only useful for solving adhoc misalignment, but also for creating mental models which you can reuse whenever you experience new scenarios, which has made me much more pragmatic and effective as a manager.

### Be led and lead omnidirectionally

A very typical interview question for managers is "what is your leadership style?". I had different answers for it: enabler, supporter, etc. These still hold, but my newest answer to it is that I am led and lead omnidirectionally.

What I have learned is that leadership shouldn't be a hierarchical trait. **Leadership is situational, and the best managers I have worked with are very self-aware of their shortfalls**. They know what they're good at, and when they need to step back for others to lead, regardless of who others are. By stepping back, delegating, or letting someone else drive direction, you truly fulfil your role: you seek the best outcome.

That said, I learned how to be vulnerable and open by default. **Sharing my quirks openly and talking about them has helped me put people in a better position to help me**. And what I have observed is that generally, people do it back as you build trust with them. Consequently, you – and the whole group of people around you – know when to step in, and when to step back. I learned a lot by allowing people to lead me, regardless of where in the reporting chain they are, and most importantly, I achieved better outcomes by doing so.

___

In closing, I also wanted to share how much joy I found through writing this year. It is quite early; still, I have learned so much by doing it. I hope this has been an exciting journey for you too. Thanks for reading my blog, and I hope the next year brings closure at a macro level, and for you, some of the greatest feelings I had this year.


This year I moved overseas and had to learn many things, both professionally and personally. Here I share some of my key learnings.

What I have learned in 2020


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


Beyond contextual reasons why this would be a timely read to me, [Julie Zhuo](http://juliezhuo.com/)'s [The Making of a Manager](http://juliezhuo.com/book/manager.html) is a great book. One reason to start with is Julie's story: she was Facebook's first intern grown into VP Product Design in her 13-year long tenure.

The book's chapter structure expresses the same progression than the title, as it starts with "what is management" and ends up in "nurturing culture". Surprisingly though, as the chapters have minimal dependencies between themselves, the book is easy to pick from where you left and to go to a chapter further and come back afterwards as you wish.

Furthermore, beyond going over foundational management themes in an unpretentious tone such as how to give feedback, how to run meetings and how to hire and build teams which work well together, the book also covers some concepts which were very interesting to think about.


### Concept #1: The multiplier factor

Very early on the book Julie talks about how **managers have the responsibility to be a multiplier factor to the team**. That is, **a manager's responsibility is to improve the outcomes of a team**. Through a metaphorical growing business story, a lemonade stand, she mentions how common it is for one transitioning into management roles to hesitate reducing or stopping their individual contribution as a response to the fact that it will reduce the team's pace, at least temporarily, and get it further away from its goals.

The trade-off on slowing short-term is a fair one: as the book mentions, there is much more to yield through finding opportunities that make the team more efficient as a whole. Regardless if it is by finding skill gaps, fixing process flaws or mentoring team members  – you will be able to add a multiplier factor to your team's outcomes if you focus on figuring out what is slowing you down, or in what could be better.

Even though the book attains itself to the context of individual contribution to line management progression in this chapter, there is clear applicability to progressions from line management to senior management roles too. Given the similar paradigm involving responsibility shifts and the counter-intuitive reality of the new position – less depth and further away from the craft, more breadth and larger context switch propensity – you will likely have to gradually step back and repurpose your contribution at a different level.

### Concept #2: The critique meeting

Another great concept Julie talks about is the critique meeting. Here is how it works:

- The team gets together and spends 90 minutes every week to share their progress for the week to each other;
- One team member starts the presentation and shows what they've achieved and then opens up for questions, concerns or suggestions;
- Every other team member raises their points, asks questions, proposes other approaches and expresses their point of view, regardless of whether the criticism is strategic or tactical;
- The presenter then takes notes from the feedback given, agrees on a list of next steps with their peers, and moves the conversation to the next person;
- The process then repeats until everyone had their turn.

I believe the main reason this concept caught my attention is that **every team has different dynamics, and collectively learning how to productively criticise each other's work can take considerable time**. With a structured session centered on criticism, you likely will learn how to give/receive feedback for the team setting much faster, while also reiterating the sense of trust between team members, which is invaluable to any team.

Differently from [agile retrospectives](https://www.agilealliance.org/glossary/heartbeatretro/), where the focus is usually behaviour, attention is sparse, and feedback can be less objective, and from [reviews and demos](https://www.scrum.org/resources/blog/sprint-review-much-more-just-demo), which the primary intention is usually gathering feedback from users or stakeholders making it is shallower from a technical standpoint and outcome-focused, **the critique meeting results in specific feedback by design**, has narrow focus with the intention of raising concerns, giving feedback, finding consensus of next steps, and then holding each other to account for progress and improvement.


### Concept #3: Peg your work back to the mission

Another very entertaining part of the book is Julie's story on how her team approached the extension of Facebook's iconic Like button. For context, Facebook's mission statement is "to give people the power to build community and bring the world closer together", which makes that specific capability – liking a post, a photo, etc. – an incredibly strategic feature.

When extending the design of one of the platform's most critical features, options were many, including a "dislike button". Even though it sounds like a good idea at first sight, additional insights guided the feature's extension in another direction.

Whilst diving deeper into the user's motivations, Julie's team found some interesting insights. Firstly, users were asking for a dislike button, although this was an oversimplification of how they felt. "Dislike" in fact means a range of emotions which are can be more specific such as sadness, anger, surprise. But most importantly, a dislike button doesn't get you any closer to _bringing the world closer together_. It actually sets people apart. With that said, the team decided to pick another route which made more sense.

In conclusion, it is easy to disconnect yourself from the company's mission, especially when you are trying to make a decision which can feel very practical, or when you feel under pressure to move on. With that said, **a great candidate [eigenquestion](https://coda.io/@shishir/eigenquestions-the-art-of-framing-problems/eigenquestions-3) for hard decisions is "how does this fit into the company's mission?"** as it can likely help you reframe the problem, as a consequence of that, pick a better solution instead, and also increase your cohesion to the overarching goals.

### Concept #4: Aim to put yourself out of your job

Lastly but certainly not least, as this is my favourite concept in the book, Julie talks about how her process for delegation is "aiming to put herself out of her job". Expanding on that, her work delegation strategy comes from working on the intersection of two factors:
- Most important things for the organisation;
- Things I can uniquely do better than anyone in/for the team.

If the task at hand isn't both, you should delegate. Here is her rationale on the subject:

1. **If anyone in your team can do one of the most important things either as good as you or better than you, delegate it.** This will allow them to increase their impact while freeing you up to pursue further support other opportunities for the team.

2. **For things you can do better and are not necessarily the most important ones, delegate to someone interested in the challenge and coach them to achieve it.** This will be a valuable learning experience for them and will help you reduce this capability gap in your team.

3. That leaves to you things that align with your skillset and are most impactful opportunities to work on within your remit. **These should be your priorities** – for the time being.

In due time, as you delegate enough lower risk opportunities, the team will be better positioned to do the most important things for the organisation which they initially couldn't. As that happens, firstly, you have fulfilled your role as a manager by improving the team's performance to achieve better outcomes. As a consequence to that, you are also taking care of succession planning, which as Julie says, puts yourself out of your job – but for your team's growth and your own progression's sake too.

Even though many management book authors talk about the motivations and mechanics of delegation such as growing people, managing risk, and the dynamics between full abdication at one side of the spectrum to being overly prescriptive/protective at the other side, what I particularly love about Julie's lens on this subject is her pragmatism on putting together an incredibly simple framework that is practical and has unambiguous criteria for putting it into practice.

---

In closing, [The Making of a Manager](https://www.amazon.com/dp/B079WNPRL2/) was a refresher to some extent, by bringing me back to my first management experience. It also reminded me of how it is fundamental to focus on building a strong foundation and gave me a pragmatic perspective to subjects which are often spoken about but very rarely fleshed out that simply and clearly.


My favourite concepts from "The Making of a Manager", a book written by Facebook's former VP Design, Julie Zhuo.

Review: The Making of a Manager


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.

Diego Ballona

Latest Articles