The Engineering Manager's Survival Guide 👩‍💻

Introduction​

Congratulations, you've been hired or promoted to an engineering manager position. 🎉

Becoming an engineering manager is not a promotion. Becoming an engineering manager is choosing a brand-new career. To succeed in this transition, you'll need to learn to unlearn, change your habits, train new muscles, and change your focus.

I'm Nico, co-founder and chief product officer at Akeneo.

Since 2009, I have worked as a software engineer, lead developer, technical project manager, engineering manager, head of product, vice president of engineering, and chief product officer. I had the opportunity to lead engineering, product management, design, and customer support teams.

In 2013, we created Akeneo to solve the pain of inefficient product information management. We help our customers create compelling product experiences to drive business growth on their sales channels.

During this journey, I led and grew a team from a few engineers building a new product to a product department of 160+ teammates delivering an enterprise suite to create solid value for our customers and business.

I made tons of mistakes (and keep doing a lot) and went through many tough times. One of my most challenging personal shifts was transitioning from software engineer to engineering manager.

Since then, I'm mentoring engineering & product leaders. During these sessions, I discovered that most new managers struggle with the same issues.

I decided to write this short guide, "The Engineering Manager's Survival Guide" to share a comprehensive overview of the main aspects and activities you'll have to handle. You'll find personal tips, insights, and valuable references to dive deeper.

There is no silver bullet; each context is unique. Don't take this guide as a playbook. It only surfaces the aspects you'll need to learn and then master to be successful in this new exciting career.

Some chapters are opinionated; those are my views only.

Do it your very own way! 💥

Career Ladder​

In the early days of a startup's life, the technical team is made of a CTO and a few engineers. The CTO is the tech leader, and she leads the small crew throughout every aspect of value creation. From the architecture to the best practices, through security, processes, projects, hiring, onboarding, etc.

As the team grows, all these aspects can no longer be handled by a single person. We start to distribute the activities and the related responsibilities amongst several engineering leaders.

For an engineer, two different career paths start to emerge in the company. The technical expertise path, also known as the individual contributor path, and the people management path.

Being an Engineering Manager, or EM, is the first step on the people management track of the engineering career ladder. An EM is the hierarchical manager of other engineers. The EM position tends to appear when the engineering team gathers 10+ engineers.

Here is a simplified engineering career ladder with an individual contributor track and a people manager track. You can find many more intermediate levels if you work at a large company.

An Engineering Manager is the manager of a team of individual contributors.

In a small company, he is often managed by the CTO. In a larger one, his manager is usually an Engineering Director. An Engineering Director is the manager of a group of Engineering Managers.

Leading a team of five engineers in a startup has nothing to do with leading a department gathering hundreds or thousands of engineers in a large corporation. It's not the same job.

The first step to evolve to the engineering management path is to lead the delivery of a technical team as a lead engineer. Acting as lead engineer, technical project manager, or team lead is an inspiring test. It's a way to discover some aspects of engineering management.

Mission​

Don't get me wrong, there are a lot of other roles where you lead tech teams, animate the delivery, mentor engineers.

The difference is that people management becomes part of your responsibilities when you are an EM.

It's actually your very first mission.

Your mission is to lead, and support a team of engineers to maximize their positive impact on the expected business outcomes.

Individual and team management is the cornerstone of this role. That's what makes the transition tricky, it requires an important shift in your focus, and it requires training new muscles.

By extension, the mission will also include responsibilities for the team's delivery, guiding the team, its cross-functional communication, and its alignment with the company's strategy.

Pillars​

Each company has its very own definition and expectations for the EM position.

This definition can evolve over time, even within the same company, depending on the team's maturity and the company's growth stage.

This is precisely what makes this role so difficult to define. There is no one size fits all.

There is no universal definition for the role of the EM, but we find some common pillars in every single engineering organization:

Most of the EMs are working for product companies, by consequence, there is often a fourth pillar: the Product 🎁

The balance between each pillar and their own individual value is very different from an organization to another.

To figure it out, let's discuss a few engineering manager archetypes.

Archetypes​

💻 The Tech Lead EM

She has a strong focus on technical guidance and architecture. She's very hands-on with the codebase, doing code reviews, making architecture choices. She usually leads a small team of 4-5 engineers at max.

👥 The Team Lead EM

She has a strong focus on the team's activities, communication, and cross-functional collaboration. She works closely with a tech lead or a senior engineer for technical aspects. She usually leads a larger team or two smaller ones.

🔄 The Delivery EM

She has a strong focus on the delivery process, the planning activities, the project management, and cross-functional communication. She works closely with a tech lead. She usually coordinates the work of several teams.

⚠️ Beware of stereotypes!

These archetypes are stereotypes. Each organization will have its own expectations when it comes to its EMs. They will likely be a different mix of the previous over-simplified definitions. There is no one size fits all.

When you undertake this role, the common practice is to start by taking care of a small team gathering 3 to 5 engineers. It's uncommon to start with several teams, or with teammates scattered across different teams, but it may happen.

A seasoned EM can be in charge of a larger team or several teams, working with up to 8 to 10 engineers. Handling more teammates is unlikely, but it may happen during a hyper-growth phase or to handle a management transition.

To be successful in this position, you'll need to understand the expectations and priorities in your given context. What matters is to be the engineering manager that your organization needs.

Anti-Patterns​

Engineering manager is a difficult role to handle.

Depending on your personality, you can fall into several anti-patterns that will have a negative impact on the team.

👥 The Cloner

You try to turn everyone into yourself by advising each teammate to act like you or to do the exact same things that worked for you previously. There is no successful one-size-fits-all approach, each context is different, each teammate is hopefully unique, and he has his own way to learn, to act and react. Individual development means something different for everyone.

🎖 The Decider

You know the system, you know each portion of the code, how everything works, you see all the inefficiencies or whatever needs to be changed. You want to make the team save time by deciding everything for them.

This is the best way to disempower the team. You should see every single problem as a learning opportunity for the team. Some decisions will be yours, but try to involve the team to strengthen their decision making muscle, and to scale the organization.

🧸 The Buddy

You want to be liked and loved so badly that you will never give a single piece of negative feedback to a teammate, or share the hard things. Your behavior will not create any positive outcome for you or your teammates. You're slowing down their learning, and you're endangering their trust in you.

💩 ☔ The Shit-Umbrella

You hear a lot of noise around the team. There are some organization dramas, some customers are complaining, you had a system outage, etc. Your guts tell you to shield your teammates from all this agitation, you want to keep them safe from any distraction.

No-one can learn from problems without knowing about them. No-one can make a good decision without having access to the relevant information. The team is living in a bubble. You should balance it out, by sharing and explaining important problems to allow the team to learn and adapt.

Don't worry too much about these anti-patterns, most of the EMs will fall in a few of these traps. I personally experimented most of them. Being aware they exist and knowing their impact will help to reassess your behavior.

Motivations​

Let's talk a bit about your motivations to apply for this position.

🕶️ Fame!

I'm going to become a rockstar in my organization and in the whole world!

❌ When the team fails, it is your fault. When the team succeeds, the team becomes famous, not you. You're here to serve and help your teammates to expand their impact. You're not here to be in the spotlight, your role is to make them shine!

🎖Authority!

I have a say in everything and my teammates will have to do whatever I tell them!

❌ If you try to do so, you'll soon be labeled as the worst manager ever. You need to trust your teammates to do the right things and guide them along the way. You're responsible for developing their skills, making every decision for them will not help.

💵 Money!

I will make a ton of money!

❌ Compensation is a matter of experience in a field, impact on your area, and market practice. An individual contributor can have a better salary than his manager.

✨ Fancy Title!

Yeah, it will look so cool on LinkedIn!

❌ The title means nothing without the related set of responsibilities and duties.

🤔 Why?

If one (or several) of the previous motivations is your main driver to become an engineering manager, you should seriously reconsider your stance.

These aspects can be seen as nice perks, but without a genuine interest in the role's missions, you will have a very low chance of succeeding, and you'll soon be unhappy.

On the other hand, having one or several of the following motivations will increase your chance to succeed in this role:

• ➕ I want to help engineers become better at their craft.
• ➕ I want to help teams to create more value, in better conditions.
• ➕ I want to have a different impact on the organization.
• ➕ I want to learn and develop a different set of skills.
• ➕ I want to evolve in a new job, a new path in my career.

The Shift​

The transition to engineering management is complex.

You need to change your focus, to reframe the way you see the organization and your contribution to its success.

Your role is no longer about your individual contribution and your individual impact.

Your new role is about what the team does, about how the team contributes to the company's success. It's about leading the team to strengthen the impact of its contribution. It's about helping each engineer to grow his skills and his individual impact.

It doesn't matter how good you used to be as an individual contributor. You may have been one of the very best engineers, listened and respected by your peers, being able to create elegant solutions to complex problems. Now, you're a junior manager, and you have a long way to go before you acquire the same excellence in another field.

What matters now is the impact of each of your reports, the impact of the team you're in charge of. Your role exists to make your teammates and your team better.

Your actions will be more indirect and their outcomes will be visible on a longer time frame. The rewards will be less immediate, actions of today will hopefully produce greater outcomes in the upcoming months or quarters.

It's no longer about you, it's about the team.

Manage your time​

One of the most surprising aspects when becoming an engineering manager is that your agenda will radically change.

Meetings!

You'll now be part of a bunch of meetings:

• 📅 Team meetings
• 📅 Individual meetings with your reports (one-on-one meetings)
• 📅 Meeting with your management peers
• 📅 Meetings with cross-functional partners
• 📅 Meetings with other teams
• 📅 Recruitment and interviews meetings

Your agenda will evolve from large blocks of 2-4 hours with a few meetings around from small blocks of 30-60 minutes, mainly packed with meetings.

You can feel overwhelmed, with not enough time to handle your current tasks, and with a lot of context switching.

Time is our scarcest resource. You need to manage it very efficiently, with discipline, and to be fully aware of how you invest it. Your agenda becomes a critical tool to master.

Getting Things Done (GTD)

An excellent methodology to manage your time efficiently is the Getting Things Done (GTD). This practice can be summed up in five steps.

📝 1. Gather what draws your attention

Someone asked you something, resist the urge of doing it right now. Write it down in a referential. You can use a single document or a todo list. Personally, I use a dedicated Kanban board. This step is critical as it will avoid having to keep everything in mind.

🤔 2. Clarify what it means

Once written, try to really understand what it means. Is it a simple task or action? If it just takes a couple of minutes, do it right now. If it requires more work, you can record it to work on later. You can also decide to do nothing about it. It seems counter-intuitive, but something the best to do is to do nothing. A meaningful way to detect a useless task is to ask yourself what will happen in one month if you do nothing?

🗃 3. Organize and categorize

If it is not a simple task, what could be the next action? To which project does it belong? What's the importance? What's the priority? Describe the steps and categorize the item in the relevant system. Schedule some time in your agenda to progress on it later or delegate it. But don't do it right now.

🔍 4. Review it frequently

Review your detailed todo list on a regular basis. Reflect on the priority and impact of the items, reprioritize them. Decide what to do and what to put on hold. Personally, I book 20 min on Monday and Wednesday morning to do it.

✅ 5. Engage and do the things

Keep some time to efficiently engage, and for the tasks that are in your priority. Personally, I tend to do the most complex tasks in the morning and to do the easy ones at the end of the afternoon. We usually have less energy at that time, it's good to complete them in automatic mode without thinking too much.

💫 Benefits of Getting Things Done (GTD)

The main advantage of this method is to capture what draws your attention to avoid being overwhelmed. Once written, your mind is free and available to be focused on your current activity.

Taking some dedicated time to reflect on priorities is an excellent exercise for a new manager. It helps to avoid falling into the trap of doing only reactive actions. It will give you more control over how you invest your time. Last but not least, it's a great way to identify the actions you can delegate to give growth opportunities and new challenges to your reports.

Help yourself, take care of your agenda

One of my favorite questions when mentoring an engineering manager is how do you invest your time?

This is a hard question to answer. And, in fact, we have a pretty wrong idea of how we effectively allocate our time. We have bias because some activities are more present in our mind, because times sometimes do not feel linear. One hour fulfilling a report may look longer than one hour having a chat with a teammate.

The goal is to choose where we allocate our time.

Time allocation is a strategic decision. On which activities or project do you want to invest your time to increase your impact and the impact of the team?

Time management is hard. However, we already have a great tool to manage our time: our agenda. With solid practices and some discipline, we can make the best use of our time.

My own method is the following one.

📅 1. Record everything in your agenda

I record any single activity in my agenda. Not only the meetings, but also each significant task I will dedicate time to, even when I work on a task on my own.

🤔 2. Analyse on a regular basis

On a monthly basis, I extract, consolidate and analyze how I invested my time. I wrote a small Python program to easily consolidate the activities per theme.

🎯 3. Set goals and prepare

Then, I rebalance the time allocation on my activities. How much time is dedicated to hiring and onboarding, to one-on-one with my direct reports, etc? How regularly do meetings take place?

To try to make the best of my time, I define my top 3 priorities for the upcoming month, and I make sure I will heavily invest on these priorities. I book some large time slots in my agenda to make progress.

Being an engineering manager, you'll always have some reactive work, surprises, changes that will happen overnight. But being aware of it and controlling your time will make a huge difference when it comes to increasing the impact of the team.

Managing your own time is a thing, but keep in mind that you need to do it in a way that does not break the flow of the team. A team meeting in the middle of the morning is the best way to destroy the productivity of everyone. The sweet spots for the team meetings are the beginning of the day, just before lunch or just after lunch.

When moving to engineering management, you may have mixed feelings regarding the outcomes of your actions. Most of your activities will not bring an immediate result. You lost the benefits of a regular and direct reward of having created something that works today. It's especially hard when coming from a developer position. You can feel that you're achieving less.

It's a pretty common feeling at the beginning. You're working on longer term actions, they will bring results later on. Keep going.

Leadership​

One critical aspect of your mission is to lead a team of engineers.

We can question ourselves about the differences and the dependencies between leadership and management. Grace Hopper had an interesting point of view on this question: “You manage things; you lead people”.

Leadership is about leading a group or an organization. Leadership is about setting a direction, and nurture the willingness of teammates to follow you in that direction. Leadership is about influencing and convincing the team.

There is no silver bullet to lead a group of people.

As an engineering manager, you're a hierarchical manager. You can be tempted to use this power to force people to do what you want. This is not leadership.

Once again, in your role, it's not about you. It's about the team.

Why would the team follow you?

You can establish leadership by being authentic, by being honest, by listening, by taking their opinion into account, by respecting them, by being reliable, by having a positive impact on their professional life, by making the team successful.

Earn Trust​

You just became the manager of a team of engineers.

I bet you will recognize yourself in one of the following categories:

• ✅ you've just been promoted from senior engineer or team lead, and you're now managing some mates who were your peers.
• ✅ you've just been promoted and given the lead of another team you don't know.
• ✅ you've just been hired as a seasoned engineering manager in a team you don't know.
• ✅ you've just been hired as a junior engineering manager in a team you don't know.

The last case is unlikely, it's very uncommon to hire an engineering manager who never handled this role, or a people management role in a previous company.

Whatever your category, whatever your past experience or achievements, you will be labeled as a newbie. Because you don't know the team, or you don't know the activity, or because you're a junior in your position.

You have to acknowledge and accept it. Especially if you're starting this new career, you know nothing about the job.

You'll need to work hard to build trust with your team. Being trustworthy does not happen overnight. So how should you proceed?

Listen more than you speak. Listen a lot, gather as much knowledge as possible, ask genuine questions, and show your sincere interest.

Be fully present when you're discussing, and never do other things like watching your mobile, your laptop, etc.

Be humble, don't start to explain X, Y, Z to a team who knows more than you. If you used to be a tech specialist, resist the urge of showing off your tech talent or bragging about how you would build this tech piece.

Your tech knowledge is a great asset. It will help you to mentor your reports, to understand and anticipate problems, to articulate great plans, to build credibility. But you should avoid using it too much at the beginning, you need to first establish trust and master the context.

Be reliable. Say what you do, do what you say. Never lie, never over-promise, never tell things you're not sure about.

Resist the urge of changing things. You may have the feeling that that's precisely why you're here. But don't try to change things before having a very strong understanding of the context, and the potential impact of a change.

List the pain points raised by the team. Identify among them some low hanging fruits, easy to fix, creating a positive impact and fix them by yourself. It will highlight the fact that you're here to support the team, that you're actively engaged in improving their work situation.

It will also help you to train your new muscles. Starting with small things, winning small battles. Like when you started as a software engineer, you didn't start by revamping a super central or complex part of the system. You fixed small bugs, you made small improvements.

A good way to identify the complexity of an organizational problem is to look at who will be impacted, few mates, one team, several teams, one department, several departments, the company. At first, deploy some local improvements, impacting only your team, and do it by involving your reports.

Communication, both written and oral, is a critical aspect to work on. Use your first improvements as examples to muscle it up. Why do we need to change? What do we change? How do we change? What are the expected benefits? Who should be consulted, involved, informed?

Use these examples and actions to assess the boundaries of your own playground with your manager. Depending on the companies, and contexts, you can get a huge push back when trying to change something a bit out of your scope. If it happens it might also mean you didn't identify the impacts of this change well.

Don't try to impress everyone. Reward the team for their successes, take the blame when it happens. Don't claim the merits. Once again, it's not about you, it's about the team.

Accept and acknowledge your mistakes. Don't try to hide things when you mess up. Teammates know you failed, trying to hide or argue or reject the fault on someone else will destroy the trust. Own your mistake, apologize, take actions to not reproduce it, and move on. The only way to make zero mistakes is to do nothing. Mistakes will happen, it's ok.

Find the right balance between protecting the team from external pressure and making them aware of the overall context and situation.

Understand that you're now the representative of the team and they deserve to be well represented. When you talk, you engage them as you engage yourself. We build trust by our actions and our behavior, by being consistent, by being reliable, by helping others. A lot of small and concrete actions will contribute to building the strong grounds, the foundations of the team's trust.

Alignment​

To strengthen the impact of the team on the company's outcomes, you will have to ensure the alignment of the team's actions with a broader strategy.

But what is strategy?

Strategy is neither a path, nor a plan.

“Strategy is a deployable decision-making framework, enabling action to achieve desired outcomes, constrained by current capabilities, coherently aligned to the existing context”. Stephen Bungay, The Art of Action.

Strategy sets a destination, expresses an intent. It is the decision to achieve something in order to generate an expected outcome.

To achieve the expected outcome requires to properly align three components: the strategy, the operations and the tactics. Tactics are the short term actions we realize, for instance, a project for the team. Strategy is about doing the right things. Operations are about tying the strategy to the tactics, and doing things right.

To become a successful EM, you'll need to deploy a very strong execution model with the team. You'll have to take actions to align properly the strategy, the operations and the tactics.

As an EM, it will often be about communicating and explaining the overall context, why we run these projects, how they are connected to a broader initiative, how the team is contributing to the success of the company.

A powerful way to achieve this is to create a shared understanding with the team by stating their mission clearly. Then it becomes easier to connect the dots, and to have the same articulated mental model to link the why, what, who, how, when.

Communication​

Good communication, or the ability to efficiently convey information, is the most important characteristic to perform well as a group of individuals.

The bigger the human organization, the harder the communication.

The size of the organization is not the only factor. Each message can be more or less ambiguous. Each person will interpret a message with his own knowledge, his bias, his past experiences and his beliefs. As an engineering manager, you have a critical role to play in order to clarify the exchange of information, to nurture good communication in the organization.

Your communication is a muscle that can be trained.

To increase our awareness, and to decide how to convey a piece of information, we can answer a small set of questions:

• ✉️ What is the message to convey?
• 👥 Who is the audience? Who is impacted? Who should be informed?
• 📻 What is the relevant medium or communication channel?
• 🧠 How to make the message as non-ambiguous as possible for the audience?

Frictions, misunderstandings, or misalignment are as many potential signals of a broken upfront communication. They can be interpreted as warnings of poor communication.

Most of the wasted efforts that are produced by an organisation are coming from misunderstandings. Communication is a vast and complex subject. Maintaining a good communication system requires a lot of constant efforts and actions.

We can observe that the more a human organization grows, the more we tend to use written media to convey information. Writing is also a way to keep a record of the organization's knowledge.

Communication depends a lot on the context. As our context evolves, an efficient communication framework today will probably be inefficient tomorrow.

Master the Context​

In your daily work, you'll often have to clarify why the team is working on this project, how the project is connected with broader goals, what are the expected outcomes, how the team is contributing to the company's success.

You need to have a crystal clear understanding of the context of your organization.

Mastering the context is a prerequisite to enable great teamwork, to nurture efficient communication and to support excellent execution.

Let's discuss how to clarify the context by answering a list of questions.

The Company 🏢

• 🌟 What is the company's mission?
• 💵 What is the company's business model?
• 🎯 What are the company's main goals for this year?
• 💌 What's the company culture, what are the main values?

The Department 🏠

• 🌟 What is the department's mission?
• 🎯 What are the department's main goals for this year?
• 💪 What are the current challenges?

The Team 👥

• 🌟 What's the team mission?
• 🎯 What are the team's main goals for this year?
• 👤 Who are the team's members?
• 🔄 What are the relations and dependencies with other teams?
• 🏗 What are the team's current projects?
• 🏗 What are the team's future projects?

The Technology 🖥

• 💻 What are the programming languages and tools?
• 🗺 What is the overall architecture?
• 📦 What are the main components?
• 📈 What are the parameters of scale?

*The Process ♻**️

• 🚅 What is the Software Development Life Cycle (SDLC)?
• 👩‍💻 What is the development workflow?
• 🛡 What are the quality assurance and testing practices?
• 📝 What are the documentation practices?

Answering the previous questions will help you to better understand the context and will help you to connect the dots. If you can't answer some of the questions, ask your manager, ask your peers.

You'll have to navigate this context, each aspect will have an impact on your actions and decisions. The context must be crystal clear for you.

Your Team​

We can define a team as a group of individuals collaborating to achieve a common goal. A team is a small social group, which has its very own culture and dynamic.

The team is more than the sum of the individuals who are part of it. By gathering knowledge, skills, views, a team collaborating well will multiply the impact that each individual ever had working alone.

As a team leader, your mission is to foster this collaboration, to support great teamwork, to identify growth opportunities in order to make the team successful.

You'll have to support the internal collaboration between the team members, as well as the external collaboration with external teams and stakeholders.

A lot of practices can contribute to leveraging and improving the internal team-work.

Having a clear and shared mission is a very powerful way to align the team to a common goal. The common understanding of each other's contribution to the mission, making these contributions visible consolidates a team spirit, a sense of collective progress and collective achievement.

As in any social group, learning to know each other, establishing trust, and creating solid relationships will take time. As an engineering manager, you can have an influence on the system to encourage collaboration on tasks or projects.

There are plenty of opportunities to work together. By using them, we accelerate the creation of the team and grow its impact and success.

In software architecture, the complexity tends to increase exponentially with the size of the system. We tackle this complexity by slicing the system into highly cohesive components. Each component is decoupled by exposing a clear API, a documented communication contract. Each component now becomes a unit.

In a growing human organization, the highly cohesive and decoupled unit is the team. You have a critical role to play in the communication and orchestration with other units.

Depending on its mission, your team will depend on other teams, or other teams will depend on your team. Knowing and clarifying these dependencies is key to support inter-team collaboration and the success of the organization.

When dealing with teams inter-dependencies, a customer-supplier relationship, and different priorities can create friction and tensions. They can be mitigated by anticipating the blockers, and maintaining a strong communication.

Tying the respective contributions of interdependent teams to a broader goal is an efficient way to re-align everyone. The point is to succeed as an organization.

All Models are Wrong​

“All Models Are Wrong, but Some Are Useful”. George Box.

I love this quote. The first time I heard it, I felt like I discovered a small treasure. Something that will haunt me for years, coming back over and over.

The former context was “... all models are approximations. Essentially, all models are wrong, but some are useful. However, the approximate nature of the model must always be borne in mind....” (cf source).

Yes, everything we perceive, all the mental models we build based on our perception are approximations. Reality is always more complicated, fuzzy, chaotic than our representation. And it's especially true when it comes to organization and human interactions.

Models also have the power to make our reality far easier to understand, by over-simplifying it.

We are going to dive into some well-known management models in this guide. They help to shape our mind and the way we look at the challenges we are facing.

These models are like design patterns, they create a shared reference to allow us to express something complex in a simple way. However, the specific context of a problem is too complex to be captured and solved with a simple pattern. Keep in mind to never blindly apply them.

These are simplified representations of a reality, not the reality.

Conway's Law​

A wrong but useful model I like is the Conway's Law, stating: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." (cf source).

I often found it relevant. We reproduce the communication patterns into what we build as a team. When looking at some products or software architecture, I like to imagine the setup of the team(s) who built it.

Ex: a very strong decoupling between two features with a light integration in between in terms of UX/UI and navigation, there is a good chance that two different teams built them.

Ex: a very strong separation between frontend & backend code that looks like two different applications in the code base, communicating through web API. I'd bet the team is organized with the backend team on one side, and the frontend team on the other.

As a team, we look for autonomy and ownership of the things we're working on.

We tend to reproduce the communication constraints or the contracts we may have with other teams or other teammates.

When I craft a new organization or form a new team, I like to use Conway's to try to predict or to guess the outcomes. It's also known as Inverse Conway Maneuver.

It's a way to promote the desired architecture or expected result by shaping the organization upfront.

Tuckman's Stages of Team Development​

Another wrong but useful model is the Tuckman's stages of group development.

This model articulates the four different stages that a team will encounter when starting to collaborate together.

Each time a member leaves a team, or each time a new member joins a team, it's not the previous team +1 or -1, it's a brand new team.

And this new team will go through the stages all over again: Forming, Storming, Norming, Performing to learn to collaborate efficiently.

Each member has to find their own place within the new group.

The group has to find its own way to operate.

This model can help to get prepared for the upcoming impacts when a team onboards a new teammate. It can also be used to trigger a change in the dynamic of a group. To help a team to change or re-invent their way to collaborate.

This model has been enriched later on with a last stage, the Adjourning stage which involves breaking or stopping the team.

Bus Factor​

Another interesting model to keep in mind is the Bus Factor.

This concept is useful to figure out the impact on the team or the project if a teammate is suddenly not available anymore (or hit by a bus).

It brings up some interesting questions. Who knows what? How do we share our knowledge? Is a part of the product or a piece of technology only mastered by a single teammate?

What is at stake here is risk management. Some events are very unlikely to happen but can have a dramatic impact on the organization and the business.

As an engineering manager, it's part of your job to deal with these risks.

Each identified risk can be enriched with two properties:

• 🎲 The probability for the event to happen
• 🔥 The criticality if it happens

Depending on these properties, you can define the appropriate actions, and follow their resolution to mitigate the risk.

A critical property of a software is its resilience. The same applies for a team, if you unfortunately lose a teammate, the team should not fall apart. Encouraging documentation and knowledge sharing is a key practice to mitigate the Bus Factor.

Your Reports​

A report is a teammate reporting to you, means you're his hierarchical manager.

I personally don't like the term report but for the sake of readability, I'll stick to this standard term. I learned the hard way that using non standard terms only brings fuzziness in your organization.

As an engineering manager, helping your reports to learn, grow and become better at their craft is part of your duties.

To achieve this goal, you need to learn to know individually each of your reports.

The idea is to have a good understanding of his personal situation, what he likes, don't like, what drives him. The point is not to become friends but to be able to adapt your management style and your actions to his context.

For instance, if one of your reports is the father of a young baby, it can explain why he's been so tired recently and under performing.

Never be too curious or ask too much personal stuff. Your report will share only what he wants to share about his own life.

At the beginning, it can be easier to share more about hobbies. These are quite neutral topics and can be good ice breakers to help to create a relationship.

The relation is bidirectional, so get ready to share a bit about you. But don't overshare, don't complain, don't share your problems.

And the most important point, never ever criticize, or speak badly, or share confidential information about another teammate.

If you do so, you'll show by the example that you can't be trusted. The individual discussions you have should remain super confidential.

The idea is not to act as a mother or a father either. Your report is a skilled adult, like you. Don't fall in the trap of over protecting or over driving him.

To help your reports to learn and to grow, you will mentor them. Do it by actively listening to their challenges, by asking questions, by sharing some tips, some ideas, or some useful resources. However, never try to make them blindly apply what worked for you in the past, each context, each person is different.

Great managers know how to adapt their management style to the given situation and the person. Adapting our style is not an easy task. We have our very own personality that drives our default behavior. But it's something that you need to learn to effectively support the growth of your teammates.

Last but not least, each project contains plenty of learning opportunities. Detecting these opportunities, and giving the right opportunity, at the right moment to the right teammate is a wonderful way to invest into his growth.

One on One​

The One on One (1:1) is an individual meeting between a manager and her direct reports. It's usually a 30-min to 60-min long meeting which occurs on a regular basis like once a week, or every other week.

It became almost standard in our industry. And even if it's not a common practice in your company, I would advise you to set a regular 1:1 with each of your reports.

The 1:1, when it's properly done, is an extremely powerful tool. The 1:1 is the meeting dedicated to your teammate, the moment chosen to talk about him, about his progress, about his challenges.

Spending regular time together contributes to creating a stronger relationship. It will support establishing a reciprocal trust, sharing the same understanding, being aligned on each other's expectations.

I recommend you to have a small template to run these meetings, and to keep track of all these meeting notes and related actions. For instance, I create a shared space between me and each of my reports to keep the record of the meetings.

I personally expect this meeting to be prepared in advance. I encourage my report to write down during the week any question he may have, any topic on which he may need help or guidance. All the topics he wants to discuss are listed in the shared space.

During the meeting, you need to actively listen to the different topics and to ask questions to ensure you have the same understanding.

This meeting is the perfect opportunity to assess together what can be improved, to set and follow different actions, to identify learning opportunities. Be extremely clear on your expectations, and make sure they're well understood.

Share some constructive feedback and ask for feedback in return. Ask your teammate how you can help him.

Giving negative feedback is difficult, you may find good excuses to not do it or to postpone. Keep in mind that if you're not sharing this feedback, you give zero chance of improvement to the teammate.

Break the bad news, be very open, and discuss together what he needs to work on. Prepare yourself to do it, make sure you have the elements, that you're able to properly explain, and that you'll have time to discuss. Don't wait for the last minute of the meeting to disclose the touchy topics, don't sugarcoat it with good news.

Always keep in mind to avoid blaming a teammate publicly, discuss the problem individually with him. The exception being when you see inappropriate or unethical behavior. If you say nothing, you tacitly accept this behavior that can be extremely toxic for the culture.

These meetings can also be run in a very informal way. For a long time, I used to do them while walking with each teammate. This format was less adapted to leverage the preparation, to keep track of the previous discussions and to capture the non-verbal communication. However, it worked pretty well.

The most important aspect here is to actively invest your time into the individual growth of each teammate.

Learn to Delegate​

🤔 Delegating?

Delegating is the act of assigning a task, or a piece of work, or a responsibility to a teammate or a team.

Delegating is a critical management skill to acquire. Junior engineering managers often struggle with delegating efficiently, it's not an easy skill to learn.

The goal is not to individually assign every single piece of work to teammates. Doing so would totally destroy the autonomy of the team as well as create a crazy workload for you.

For most of the work that has to be done, the system and the related processes will create a context where everyone knows what he has to do, or what he can pick as a next task.

For instance, in a product development team using a scrum-like framework, the work planned for the current iteration is visible and known. Each teammate can easily pick a new task when the previous one is done.

If you find yourself having to assign a lot of new tasks every single day, you should look at the process and at the system to fix it.

With a proper system in place, delegating is about assigning a task which is on your plate. The purpose is not to randomly push all your work on the team. The goal is to identify which task can be a learning opportunity for a given teammate.

Ultimately, as an engineering manager, you want to make the team as autonomous as possible. They should be able to efficiently work without you being around.

It's also your responsibility to identify and to train the future organization leaders. The leaders that will be fully ready and proficient to replace you at some point.

So, how to decide what to delegate and how to do it efficiently?

📝 Identify and list the tasks to be done

You should maintain and nurture a list of your current tasks to be done. As discussed previously, my trick is to use a dedicated Kanban to capture these tasks, and work on them following a Getting Things Done workflow.

👤 Assess the skills and the autonomy of a teammate for a given task

The goal is to pick the right task, for the right teammate, at the right moment. It should be a bit challenging, give a growth opportunity, without putting the teammate totally out of his comfort zone.

We use the word task as a generic term here, a task can be a complete project, or a large initiative. The size of the task has to be relevant with the teammate's mastery.

When you can, avoid delegating tasks seen as too simple, or boring to a senior mate when they could be super exciting for a junior. It's a missed learning opportunity.

We can notice that we're all junior or senior depending on the task, a very seasoned backend software engineer can be extremely junior on frontend dev for instance.

Try to pick a task that will contribute to the learning wishes of a teammate, that will contribute to his goals. It will create a strong engagement as well as showing that you're investing into his personal growth.

✅ Decide to delegate, prepare and communicate

Some tasks can't be delegated. Because they are too critical, too important, and because no-one is ready at that point to handle them, even with guidance. Keep track of these ones, being the only one able to do a task can be a strong signal that there is a bus factor risk here.

While deciding to delegate, make sure the task is clear enough, prepared enough to be delegated to a specific teammate.

Don't let a teammate handle a complex task without any guidance or preparation. Explain you want to give him this opportunity, slice the task in steps with him, enjoy this opportunity to teach him how to articulate this work.

Don't over prepare upfront for a teammate who is skilled and autonomous on this task. Explain to him why, what's the purpose of the work and let him fully own it.

💬 Follow up until completion

Once delegated, it's critical to follow the progress until completion. It's usually done during the One on Ones. Depending on the level of autonomy and maturity of a teammate on a given task, you will have to adapt your style.

Conclusion​

I hope you got some value from this guide and enjoyed reading it.

You'll discover and learn a lot of other topics during your engineering manager's journey. You'll need to experiment to figure out what works for you in your context. Don't be afraid of making mistakes. Everyone does, and this is the best way to learn. I may add sections later; contact me if you identify a topic of interest.

Thank you to my proofreaders and readers; your valuable feedback and insights helped complete and polish this guide significantly. Thank you to my pairs, reports, and mentees; this guide would not exist without you; our discussions helped me become a better leader. 🙏🏼