9 mins
You have 0 further articles remaining this month. Join LeadDev.com for free to read unlimited articles.

So, you’ve been promoted to manager.

It’s been something you’ve been looking forward to for quite some time, and it’s your cue to get ready to face one of the most complex changes in your career.

Let me guide you through that journey: we’ll focus on some behaviors you should pay attention to and some techniques that can help you navigate this transition.

Skyscanner advert

The reality check

Do you know the saying, ‘Management is a step to the side in a software engineer's career’? It means that when you become a manager, you become responsible for the team's success. So, you might believe that you'll make the rules based on how your previous managers acted. However, you'll soon understand that this is not the case.

The reality is that different people – stakeholders – want something from the team, your  team. You’ll most likely be involved in multiple negotiations with various stakeholders – product managers, software architects, product designers, you name it. You could be requested to work on security, product needs, tech debt, and to make it harder, the decision criteria you’ve used in the past may no longer be valid.

For example, today, security may be a hot topic for your organization because you’re working in a public company, whereas when your org was a small startup, it wasn’t so high on the priority list. Your new job, as a manager, is to help the team handle all these requests and deal with the influx that sometimes may feel overwhelming.

The bottom line is, you're not the only one making the rules, yet you’re the only one responsible for the team's success. This newfound sense of responsibility comes with its own set of issues – so, how can you navigate around the common traps?

When managers paternalize the team

The moment you become a manager, it may feel like you now ‘own’ the team. Quickly, the team turns into your  team, and you might start referring to it as my team all the time. This expression is something I’ve listened to over the years, and it’s a red flag in my 1:1s, so pay attention to it because you may be falling into a trap; you may start feeling that your main job is to protect the team, to deal with any attacker from the outside, but that’s not your job – you are there to help them grow.

Over-protective managers trap

When you realize that different stakeholders want something from the team, you may want to turn the fight-or-flight mode on. This means that you start protecting the team because you perceive good leaders as those who take the bullets. You believe a good leader decides everything for the team and assumes the risks that come with it, thus preventing failure and owning responsibility.

The truth is that those types of managers who take the shots don't actually help anyone move forward in their career paths. Do you recall what helped you grow from junior to senior software engineer, and up to your position as a manager? It was your professional experience: the number and variety of challenges you faced throughout your career, of course. Now that you're a manager, it's time to allow team members to face the highest number and variety of challenges possible.

You still need to manage the team's work and guide team members when executing that work. But you shouldn't prevent them from taking on responsibility. In fact, it's quite the opposite: you should give team members space and push them towards responsibility.

Share the burden of owning responsibility

Team members should develop the ability to make decisions based on context. But remember, you're the one responsible for creating the structure and processes that foster effective decision-making.

There's no problem using the expression ‘my team’, but words have a powerful impact and play a tricky role. In this case, the word ‘my’ might tell the team members that the manager owns responsibility for every team's decision.

That's not good practice. Although some might wish for it, managers are not omnipresent. Therefore, teams are the ones with all the context to make the right decisions at the right time. You might be wondering, ‘How can I transfer ownership to the team for decisions if I'm responsible for the team’s results?’

Tough question. Managers are indeed responsible for the team's results. They own the team's failures and successes, but they also own the team's autonomy level. So, here's the deal: people shouldn't demand autonomy without expecting responsibility, and vice versa.

Remember that team members have more information about the issues they tackle than managers. In fast-changing environments, the challenges that teams face are completely different from the ones you have faced throughout your career; you need to accept that you don’t have all the answers and you need to let go. As a manager, you should support team members, but they should make most of the decisions.

This becomes harder as you move up the management ladder and you become a manager of managers. At this stage, you have more layers between you and some of the team members’ decisions, but you keep being responsible for their actions.

Here, you will no longer be able to have all the information, so you need to avoid the ‘let me be in all teams’ meetings’ mindset. I know you just want to ensure that you have all the information – either to be sure you support the team or to report to your manager – but this strategy no longer works. At this level, you need to clearly communicate goals and trust that team members will do their job.

Building trust

The only way you can give true autonomy to teams is by building trust. Trust should flow in both directions: managers should trust teams, and teams should trust their managers.

How team leaders can build trust

Trust doesn't develop overnight – it takes time. And in an engineering environment, trust will only develop when the manager and team overcome challenges together. Transparency also plays a vital role in developing trust. You should not only be transparent but also explicitly encourage it among your engineers – for example, openly discuss your own and the team’s inefficiencies. (Later on, I’ll give you a great technique to achieve this.

Most of the time, as a manager, you should assume a coaching mindset and let teams learn by themselves. You should allow team members to go in directions that you believe will fail. Let them own their failures, as they may take you by surprise and succeed against your expectations.

Other times, you'll need to step in and mentor teams to guide them in the right direction. This may be due to a high risk of failure that could compromise goal achievement, or due to tight deadlines. Although faster, mentoring leads to smaller learning opportunities for team members. But on the other hand, success leads team members to trust the manager more.

There are situations, like crises in a project, where you should be directive and determine how team members operate, overruling their autonomy and decisions.

Mastering these three management styles will be critical for you to balance learning opportunities with successful initiatives.

Communication as the cornerstone of trust

A key aspect of building trust is communication: ensuring that you foster a culture of openness and honesty. Simultaneously, you should make it clear that you won't be glued to the side of team members all the time. Trust the team and let them know that you expect them to raise flags as soon as concerns appear.

Here's a list of specific communication events that you can organize to build trustful communications with the team:

  • Ask-me-anything sessions. Gather a group of teams and promote a fully transparent discussion about anything – really, anything. Managers should expose themselves to hard questions for which they might not have an immediate answer.
  • 360 feedback sessions. These are group meetings in which team members give feedback to each other openly as a team. Any team member's challenge is a challenge for the whole team. The whole team is responsible for the success of each individual.
  • Skip-level 1:1s. These meetings allow managers of managers to check the pulse of the organization. It allows them to get more context and to ensure that their messages become clearer across the organization. It also allows them to get feedback that they can then use to mentor their direct reports.

All these communication activities allow you to gather and reinforce the information flow across the organization – something which is critical as the organization grows.

Information flow

Context allows managers to trust the team. So, whenever you want team members to be autonomous and responsible, provide them with enough information for decision-making. Too much information and they go into an analysis-paralysis state; too little information, and they might not be able to make good decisions.

Jeff Bezos says that people should decide with 70% of the information, and I totally agree. Managers should consistently provide teams with the right amount of information and then support them in their decisions – and vice-versa. You already know that not all information will be relevant for the team, just like how not all information from the team is relevant for you. For example, you may not want the details of the code, but you’ll want to know the overall architecture. The team will want to know why they are doing something, but they will be less interested in what you are working on with marketing to launch the product.

As a manager, you're responsible for that two-way information flow. Like water in a hose, you need to control the amount of information flowing within the team – you included – to maximize effectiveness. For example, when in crisis you need to know when to expose team members directly to a customer, and when to avoid it. Managing information and effectiveness are some of your core responsibilities. 

By properly controlling the information flow, you contribute to growing your trust in the team. In turn, team members trust you and feel comfortable when you point them in a specific direction. They might not even understand exactly why you're pointing them that way, but they'll accept it.

Autonomy is a mindset

We live in a world with problems to solve and business needs that constantly change. As a result, there's no way you have the time to control all team members' decisions directly. You are responsible for the team's results, but you should minimize your direct influence on them. Otherwise, team members would lose their autonomy, and you all wouldn't meet business goals as fast as the business needs.

Managers are responsible for defining how they conduct the team. They might use strategies such as directing the team or coaching. The first yields to less growth in individuals, whereas the latter favors learning despite being slower. As a manager, it is your job to achieve a balance of these strategies that results in the best overall outcome.

You should make the team feel empowered yet responsible for their actions. Develop a bilateral trust, and team members will quickly understand that the team's success is the organization's success. They bear that responsibility, but you, as a leader, should support them all the way through.

Skyscanner advert

Creating and sustaining motivation in engineering teams
Episode 01 Creating and sustaining motivation in engineering teams
The art of self-organizing engineering teams
Episode 03 The art of self-organizing engineering teams