The job of a manager — Part 2

In Part 1, I shared why companies need managers and what their responsibilities are. And in this part, I’ll share more about who gets to be a manager and how their careers can evolve.

How does a manager fit inside the organisation

The previous section covered your role concerning your team. But managers are a crucial part of the broader organisation. As such, you play an exciting role in the global context too.

Enforcer

You can view any organisation as concentric circles emanating from the CEO. The CEO is the centre, their reports in the first circle, their skip-reports in the second, and so on.

As a manager, you’re in a more central circle than individual contributors. Roughly the circles correspond to performance, experience and responsibility. It’s a crude analogy, but even as an L1 manager, you’re in the top 20% of the organisation, helping it succeed. As L2 managers, you’re in an even more select crowd, and so on.

Being more central means you’re supposed to take a different type of view on some ‘organisation vs individual’ topics. Suppose you consider that the CEO considers the organisation’s best interests and an individual contributor considers their own. In that case, you, as a manager, are somewhere on that scale. Where exactly? It depends on how close to, or far from, the CEO you are. But you shouldn’t think of issues simply from the IC angle. You’re instead an enforcer of the diktats of the company.

For example, our processes have an elaboration and an implementation phase. You may, or may not, be part of the elaboration phase. And you may, or may not, agree with what has been elaborated. But you must ‘disagree with and commit to’ the implementation phase — and especially present a unified front for the broader organisation.

I hope the last sentence has stirred you a bit. It’s not an approach that comes easily; ‘disagree with and commit to’ can sound like ‘just following orders’. But organisations cannot function well in split-brain mode. Hence it’s vital everyone works the same way. It’s on the leadership to arrange things so that the elaboration phase is inclusive and gives folks a chance to shape it in a way they think is essential.

But even so, not all suggestions will be heeded and, in some cases, this ideal of inclusivity won’t even be attempted. Hence, you’ll likely encounter at least one process with which you disagree.

Conversely, ‘disagreement with and non-commitment to’ is not an option. It’s essentially not doing your job, which doesn’t go over well.

To add even more complexity to your life, you’re also supposed to be your team’s voice in the organisation. This is distinct from your voice. The interests of your team might be different from yours from time to time. Indeed, your organisation’s interests will differ from those of the broader organisation. So, you must also navigate this tension and know when to fight for your group.

Supporter and leader

We all know the mantra, “Management is different from leadership”. At Bolt, the two come as a package, however. We expect engineering managers to show leadership first. This means handling strategy and vision issues, teaching people to yearn for the vast and endless sea, etc. We secondly expect them to be good managers. This means handling problems of control, predictable delivery, planning, budgeting, staffing, etc.

But there are formal leadership roles outside the management track. Our Staff and Principal Engineers also need to show a lot of leadership, and the same for folk wearing the TL and GTL hats. But we expect and encourage leadership in many other situations. Anytime you do something outside ‘business as usual’, whether you’re a Customer Support agent or Junior Developer, you’re showing leadership.

Depending on the context, you’ll need to wear one, the other, or both hats.

Role model

A manager should also be a role model of those valued organisational behaviours. In our case, this means our Operating Principles. This is initially straightforward, as you’re hired or promoted based on these things besides your ‘technical’ contributions. But as the nature of your work starts to shift, you must keep these things in mind.

For example, the practices of code reviews and quarterly reviews are manifestations of our “We challenge each other, but mean well!” principle. Both are open to anybody. You shouldn’t be upset when a valid point is raised. Yet I’ve seen folks accept drive-by code reviews much more easily than drive-by quarterly reviews. That shouldn’t be the case. As a manager, you should accept the former just as well as the latter.

There’s another take here. There are some things you can no longer do like you could do as an IC, for example:

• Getting drunk at parties;
• Making stupid jokes;
• Having ‘opinions’.

At the very least, from a self-interested approach, you don’t want to be one like, “He/She is a good manager, too bad he/she …”.

My expectations

A common question that Engineering Managers at Bolt have asked is, “How do I know I’m doing a good job?” The following is my take on it.

It’s principled. That means it supports the theoretical description outlined in the previous sections and it’s also common practice at Bolt, as well as in the broader industry. Indeed, my manager has more or less the exact expectations of me, his manager of his and many other managers of their reports.

The core point is that there is no notion of individual performance. There is no, “How am I doing?”. It’s rather, “How is the team doing?”. If the team is doing great, then super, regardless of what you actually contribute to it. If the team is not doing great, it’s bad irrespective of how well you’re doing yourself. Of course, this will be hard to do without your help.

Then, as a simplification, the team is doing great if the manager is doing a great job of being a manager. To make things clear, I prepared many explicit topics.

The management career

As hinted, engineering management is a career in itself. Thus there are a lot of habits and customs surrounding it. In this section, I want to cover a bunch of them. This is the most Bolt-agnostic section.

Is management a promotion or a lateral career move

Yes.

Management is an activity anyone can do. Same as leadership. Engineering managers specialise in building the sociotechnical system that does the work. They get extra leadership cookies too! So it’s a different career track, like SRE or data science.

So, becoming a manager is a lateral move since you’re leaving one job — directly coding and building systems, to another type of job — leading and managing people who code and build systems. And it’s expected that you’ll not be good at it for some time.

But in another sense, it’s a promotion since you’re brought into a more central position in the organisation.

There are many places where we’re split-brained around this thing:

• We’ll commonly call the change a promotion;
• But then we’ll not offer a substantial compensation increase;
• We’ll allow the better-performing folk to try for manager roles;
• But then place no such restrictions on the individual contributor track.

This is a particularly engineering and ‘professional’ way of looking at things. In other company divisions, the move to management is absolutely a promotion. Indeed, in these cases, there’s only one path to career progression: taking on a manager role.

The above, coupled with the historical context, means that being a manager is considered prestigious. We know better, but an essential and complex organisational angle is also at play. We need high-level ICs just as much as we need EMs. We’ll be lacking in the former if we just glorify the latter.

Who gets to be the manager

In light of the above, the next question is who gets to be the manager? I’ll assume we’re speaking about a ‘you’, which is different from the ‘you’ in the rest of the document, because you’re already a manager.

The first and crucial test to pass is that you should try this out. There are options for high-performing folk, and management is one of many games in town. As this document makes abundantly clear, management is a different and challenging job. You will have a bad time if you’re only going in for respect, money, or power. If you like people and solving their problems, building an organisation, or shaping how the company works, then…you should still think it through.

The second test is whether you’re senior and experienced enough as an engineer. The level at Bolt is Senior Software Engineer, some quarters away from their promotion or hiring. Arbitrary or not, we have it.

Then you have to be someone with a track record of outstanding performance in the team — not necessarily the strongest in the group, but not in the ‘bottom half’ either. Perhaps you were the TL, someone responsible for some big projects, or someone the team turns to when things go down.

Finally, there needs to be an agreement between several people that this thing is a good idea. Besides your manager, there is also your manager’s manager, the PM of the team (if any) and their manager. If there are other stakeholders, they’ll be consulted too. Of course, the people you manage will have a say in the decision. Strong objections from any can tank the process or at least cause it to be restricted and treated even more cautiously.

Regarding where we source the manager from, there is a priority list. In higher-to-lower priority, we have:

From within the team:

• Pros: knows the product, knows the systems, knows the team;
• Cons: inexperienced manager might cause tensions.

From within the company but already EM or clearly on the path to becoming one:

• Pros: knows the people, knows the way we work at Bolt;
• Cons: relatively-inexperienced manager, doesn’t know the product or systems.

From outside the company, but already EM with several years of experience:

• Pros: experienced, brings a fresh perspective, etc.;
• Cons: doesn’t know the company, the product, or the team.

As you can see, the more we know of a person as a member of Bolt, the more we’re OK with offering space for them to grow into the manager role. Conversely, folk brought in from the outside need to have demonstrated experience.

Now, there are always going to be exceptions here. We’ve had middle SWEs with reports or seniors skipping straight to L2 management. Don’t count on it in the future.

The evolution of a manager

Associated with the management career is a management career path. What we’re doing at Bolt is relatively standard across the industry.

In this section, I want to sketch what a ‘traditional’ management career run looks like. In my view, it has two distinct phases — your first exposure to being a manager and the second, longer part of going deeper into the path. I’ll cover them in the sections that follow (and throw in a bonus wildcard career option).

From IC to a seasoned line manager

You start as an IC in a team. You do a good job and it’s externally recognised as such. At some point, the previous manager may be moving, or there’s a subteam coagulating across some well-defined ownership. In any case, there’s a need for someone to take the manager role. You volunteer and are appointed. There’s a shared understanding that this is a test period. You need to see if the position is what you want and the organisation needs to know if you’re good at it.

The initial team is tiny — just two to four people. Your title is still Senior SWE. You’ll be both TL and people manager in the group. And you’re still expected to do IC work for the most part. But you have extra responsibilities around quarterly and yearly planning and get a more significant say in the team’s processes.

Three to six months into your journey is the time to reflect on how things are going. There are four possible outcomes.

You enjoy the new type of work and the team is doing well:

• This is the best outcome and, frankly, the one we hope for;
• You’re unblocked for the formal ‘promotion’ to EM. This can happen as soon as right away if the team is large enough.

You don’t enjoy the new type of work and the team is doing well:

• This is a solid outcome in the end. You tried something, gave it your best shot and found out it didn’t fit with what you wanted to do;
• The plan here is to step down from leading the team. Your manager needs to find a replacement. Depending on the situation, you may be asked to keep running the team for a little while until a new manager can be found.

You don’t enjoy the new type of work and the team is not doing well:

• It’s a clear win-win scenario to step away from managing the team. It’s not a good outcome, but it’s the one we were prepared for;
• Your manager needs to find a replacement ASAP. There’s a strong bias for not continuing the setup longer than required.

You enjoy the new type of work but the team is not doing well:

• This is a tricky case. It hasn’t happened that often as, usually folk tend not to like the stuff they’re not good at;
• We have a bias for this thing not to go on. We’ll take it case-by-case and study the whole situation though.

Assuming you fall under the first example, the team will continue to grow and you’ll grow as a manager too.

After a while, usually after six or seven direct reports, delegating the technical ownership aspects of your job to a TL is a good practice.

The next step is to handle the scaling as the team grows. The story tends to remain the same for teams with 10–12 reports. We expect you to scale.

Beyond line manager

The individual contributor to the line manager transition is a massive move. It can seem like a tremendous effort, but it’s just the start of the journey down the management career path.

In engineering, at Bolt and many other technology companies, this usually takes the following form:

• Engineering Manager (EM) — the line manager position. Around 3–8 direct reports;
• Senior Engineering Manager (SEM) — a manager of managers, or an L2 manager. You’ll be responsible for a larger group of people, own a large product scope, have manager reports, and have a team of teams. Around 3–8 direct reports and team size of 15–50;
• Director of Engineering (DoE) — either an L2 or L3 manager. You’ll be responsible for a large group of people (50+), own a complex and extensive product scope, have manager and SEM reports, and likely have multiple large subteams. You’re also increasingly responsible for the external presence of the company, recruiting efforts, etc. Around 3–8 direct reports and team size between 50–100;
• Vice President of Engineering (VPE) — currently the one person responsible for the whole of engineering.

Growth here means managing more extensive teams successfully. The EM to SEM transition is another hard one. Not as big a delta as the IC to EM one, but not negligible. And again, you could say it’s another type of job. As such, I’ve carved out a special ‘L2 Considerations’.

You’ll start as an EM of a team. You do a good job and it’s externally recognised as such. The team will increase in size beyond the ten recommended maximum scope. You’ll start breaking off smaller subteams of 2–4 people with their trainee manager. Pretty soon, you’ll have your first report, who has other reports, and your first skip-level reports. Things go well and several other teams spin off.

You’re delegating more and more to the new managers and you might even have a GTL helping you out. Some managers have big enough teams to discuss the EM transition with you and your manager.

6–12 months into your journey is the time to reflect on how things are going. Since this is still a big transition, we’re not just going on inertia and we’ll do the same kind of analysis as before at the IC to EM transition. There are four possible outcomes:

You enjoy the new work and the team is doing well:

• This is the best outcome and the one we hope for;
• You’re unblocked for the formal ‘promotion’ to SEM. This can happen as soon as ‘right away’ if the team is large enough.

You don’t enjoy the new type of work and the team is doing well:

• This is a solid outcome in the end. You tried something, gave it your best shot, and found out it didn’t fit with what you wanted to do;
• The plan is to step down from leading the larger team and focus on a smaller one. Your manager needs to find a replacement. Depending on the situation, you may be asked to keep running the team for a little while until a new manager can be found.

You don’t enjoy the new type of work and the team is not doing well:

• It’s a clear win-win scenario to step away from managing the team. It’s not a good outcome, but it’s one we’re prepared for;
• Your manager needs to find a replacement ASAP. There’s a strong bias for not continuing the setup longer than required.

You enjoy the new type of work but the team is not doing well:

• This is a tricky case. It hasn’t happened that often, as usually, folk tend not to like the stuff they’re not good at;
• We have a bias for this thing not to go on. We’ll take it case-by-case and study the whole situation though.

Assuming you fall under the first example, the team will continue to grow, and you’ll grow as a manager too.

Besides the path of naturally growing the team, there’s also the option of taking over another fully formed team when there’s some reorganisation. It happens from time to time. If you view career progression as a goal, this is essentially luck. It used to happen a bit at Bolt, and it’ll happen to a degree in the future, although less frequently as we grow, so don’t count on it.

We’re at a stage where many teams are similar-ish in scope, so managers of close teams are somewhat matched in skill. A would-be decision-maker might then choose an external and experienced SEM in such situations.

After the SEM transition, things have an inertia of their own. Being an SEM for a team of 20 people is not radically different from being an SEM for a team of 40, which is again not fundamentally different from being a DoE for a team of 60. You still need to keep up, but if there are issues, they’d have shown up somewhere on the path, not just at the DoE promotion checkmark.

These promotions are critical. You’re part of the top 5% of the organisation concerning centrality. If things do not go well, you could do much damage. The analyses that are done tend to be rather binary after a while.

• If the team is doing well, then all is good;
• If the team needs to do better, this is a big problem. Tens of engineers are affected. Complex and essential products need to be managed. Your manager will tend to act swiftly as this is a big problem for them too.

But wait, there’s more! Career Pendula…

Up is one of many career progression options. The engineer/manager pendulum highlights another way of tackling career growth by alternating between IC and EM roles. Experiences from one inform the other and you end up being an overall better engineer than if you just focused on the other side.

It doesn’t go as far as saying that experience in management is a prerequisite for the higher levels of the IC track, but at least there is a fair share of Staff+ engineers who are former managers at Bolt.

L2 Considerations

An implicit belief of most of this document is that being a manager differs from being an individual contributor, especially when comparing the common situation of line management vs being a senior software engineer.

What doesn’t get enough airtime is that being an L2 manager differs from being an L1 manager. Here, L2 manager means a manager of managers, with little to no individual contributors or notion of a team. So a manager of ten people with one subteam of three wouldn’t count, but a manager of 15 with three subteams of five would.

The most significant and evident difference is that there are more people. More people means more problems.

Then again, you’re leading a group of several teams, roughly related. Each team does its thing, but it’s harder for the group to feel like a unit. There still should be some overarching structure, but the bounds are much weaker overall.

Since the domain is more extensive, it becomes harder to grok it completely. You can keep a tab on all projects in a single team but only on the critical tasks in larger teams. You’ll be familiar with some and perhaps not even know about others.

The way to scale here is to delegate and create the structures for others to succeed. Getting involved in every tech discussion, unblocking every project, or reviewing random code or design docs is a recipe for trouble in general.

The relationship between you and your reports will change too. They will be managers of various skill levels and higher-level engineers (often acting as Group TLs for your group).

For example, your 1:1s will become more operational: there are goals to catch up on, updates to provide, context to be shared, etc. Spending the meeting talking about the latest movie or generally bonding will fade into the background.

Then you’ll need to allow for autonomy and room to grow. There’s a spectrum of sponsoring, mentoring, and coaching; you must find the sweet spot for each person or situation. Furthermore, your managers are also responsible for their slice of the problem. Hence they have a right to a sort of ownership shield to run their show as they see fit, as long as they’re meeting the expectations.

At Bolt, in particular, you’ll be more exposed to company processes, take a more active role in salary discussions, or worry about a new site being opened and the projects to staff it with, etc. In principle, you’re much more central to the organisation than before.

There’s going to be a new class of decisions you’re responsible for:

• The final word on hiring in any team;
• Salary decisions on new joiners;
• An important comment on salary increases in the compensation review;
• Some promotion decisions (Junior->Mid-level, Mid-level->Senior) and heavy involvement in others.

Finally, and perhaps most annoyingly, you’re out of the area of quick wins. An IC can ship a feature in a day and an EM can ship a project in a month. Still, as an SEM, you’re looking at multi-quarter timelines for the kind of work you’re expected to do: hiring mobile devs in a previously backend team, restructuring the way a particular team works, adopting experimental technology from Foundations (our infra group), etc.

With all of the above, there’s a lot of room for the specifics of the team and individual to factor in. Highly technical teams will require highly technical L2 managers. Folk historically involved with specific projects or technology can still contribute as L2 or above managers, whereas the same expectation wouldn’t hold for new joiners. Play it by ear and optimise for what works for you.

The good news is that the L2 to L3 and beyond transitions are much smoother — perhaps just the final transition to being an executive and entirely responsible for engineering (or so I’m told). But if you can master operating as a manager of managers, you can confidently say you have a knack for this management thing. And while folks won’t hurry to offer you those sweet FAANG SVP positions, they’ll at least recognise it’s a difference in scale and years of experience rather than substance.

Who gets to be the L2 manager

In light of the above, the next question is, who gets to be the L2 manager?

There are three critical situations to discuss:

• If we have a team that will grow such that it’ll split into coherent teams and will need an L2 structure, then the current L1 manager is the first in line and the discussion in ‘Beyond line manager’ happens. If the teams aren’t coherent enough, they may or may not stay with the same manager. It’s a case-by-case discussion;
• If we have a team that will grow such that it’ll split into coherent teams and will need an L2 structure, but the current L1 manager doesn’t want or cannot handle the extra responsibility, then we’ll look for a company-wide or external hire (at least with a 99% probability);
• If we have several existing and established teams that we want to group for coherence reasons, then we have a whole other discussion:
• If there is one clear leader in the group, close to L2 management or already at that level, then that’s a natural choice. This is rather like moving some teams under a new manager;
• If there is no clear leader in the group, then we have all the below discussions.

Regarding where we source the manager from, there is a priority list. In higher to lower priority, we have:

From within the team:

• Pros — knows the product, knows the systems, knows the team;
• Cons — inexperienced L2 manager, power-dynamics shift, can lead to the Trojan war.

From within the company, but already SEM or clearly on the path to becoming one:

• Pros — knows the people, knows the way we work at Bolt;
• Cons — doesn’t know the product or systems.

From outside the company, but already SEM with several years of experience:

• Pros — experienced, brings a fresh perspective, solves a political situation neutrally, etc.;
• Cons — doesn’t know the company, the product, or the team, hard to find.

As you can see, the more we know of a person as a member of Bolt, the more we’re OK with offering space for them to grow into the manager role. Conversely, folks brought in from the outside need to have demonstrated experience.

Some things you noticed as being funky really are!

You’ve probably noticed some funky things if you’ve been in the EM role for a while. I’m here to confirm that they’re indeed funky. In no particular order then:

You aren’t necessarily the best-paid person on the team. The salary band structure at Bolt and many other companies place EM at the SSWE level. This means that if you have staff or above ICs reporting to you, they will have higher total compensation.

But even within the SSWEs and equivalent in the group, there might be folks earning more, if perhaps they have high performance, while you only have solid performance — or if some other sources of ‘noise’ rear their head, e.g. better negotiation skills, more leverage at negotiations, various compensation debt situations, etc.

Career progression is linked to some things you can’t control — things such as the size of the team. Successful execution, as defined above, with a team of a specific size is the main criterion for the promotion. This is not a simple thing, of course. But team size is outside your control. It depends on your project and on the capability of you and your PM to convince leadership that the team should grow.

After that, there are the natural limitations of developing a team. Or market forces or world events halting hiring. So you might find yourself ready for, and capable of, taking on a more significant challenge, but the challenge doesn’t appear.

Indeed some companies have more finely grained management levels. And we’ll for sure get there too as our company grows. But, at the end of the day, there’s only so much you can do as an L1 or L2 manager.

In general, career progression means running bigger and bigger organisations — or at least being closer to the executive level and ‘calling more of the shots’. There’s no longer any straightforward solution for folks who can’t or won’t run bigger organisations. But managing bigger teams is different from the line management folk start with. And these bigger teams are rarer. There are N/10 EM positions. But only N/50 L2 EM positions and so on. Furthermore, there aren’t many companies needing L2 managers (for real) or L3 managers, etc. — power laws all the way!

There’s no standard middle path either. As seen above, you can go all-in on technical growth or organisation growth, but not both at most organisations. Perhaps at infrastructure groups, or at large companies, it’s more common to see Staff+ engineers with reports. But overall, it’s not a common occurrence.

You will become distant from the technical aspects. Sure, you might not notice it in your first year or your third year. But you’ll see it when the industry starts to move, especially when you get deep enough into the rabbit hole that you don’t touch code at all at work. This occurs somewhere on the path to L2 management. If you end up not liking the career path, you might have difficulty returning to IC work.

It’s tempting to jump before you’re an experienced engineer if given a chance — especially for folk who see management as a promotion; it opens you up to problems should you choose to go back.

Extra skills

There are some common extra skills managers need to pay attention to. I’d be remiss if I didn’t mention them here.

These are:

• Public speaking — if ever there was a ‘career cheat code’, this is it. Even being merely decent at this offers many advantages;
• Presenting — a particular type of ‘public speaking’ common in corporations. Backed by a slide show, you’re out to inform, convince, or justify. Presenting to executives deserves a special shout-out here as a nifty subskill;
• Writing — as we transition from an oral and Slack-based communication culture to a written one, being able to write well is another superpower. Being able to write concisely is a holy grail few achieve;
• Influence without power — even when you have the power, you don’t want to use it — and in most situations, as a manager, you won’t have power. Being persuasive, seeing the other person’s point of view, and negotiating are, however, important skills to master;
• Candid communication — challenging discussions don’t come easily. Even when we commit to having them, they tend to go sideways. Knowing how to have high-stakes conversations with folk is another good superpower to have;
• Giving feedback — giving good feedback is an art: both the delivery and the content are hard to get right. But it’s your number one tool for improving your team, the group and yourself.

Conclusion

There you have it: 10000(ish!) words on management, barely scratching the surface. I hope by this point, you have a better overview of the job than at the start. The reading list is an excellent place to dig more deeply if you want to learn more.

If what you’ve heard about management sounds like your cup of tea — whether as a manager or as an individual contributor being subjected to the said manager — head to our careers page and check out our openings. We’re hiring!