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

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

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

### Transitioning from IC to EM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#### Build a well-functioning team

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

____

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

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


Article originally written for The Pragmatic Engineer, in May 2022, about how to navigate this very common career lateral movement.

Navigating the engineer to engineering manager transition


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


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


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.

Personal Growth

Navigating the engineer to engineering manager transition

What I have learned in 2020

Review: The Making of a Manager

Review: Radical Candor