The job of a manager

The following is a repost of an internal training I did for managers in my team at Bolt. We are new to the job, and I saw many common confusion points pop up. I thought it worthwhile to lay down more concretely the expectations of Bolt’s Engineering Managers. It turns out the resulting document has broader applicability. So, after much procrastination, I’m putting it on the blog for more folk to enjoy.

Introduction

Being a manager is … different. I’ve collected a bunch of my thoughts on the topic. This, then, is a small effort at accomplishing an overarching framework. Still, overall, the document is guided by what I saw as points of confusion in my many chats with folks within the organisation. Some topics apply to the whole profession of management, others to engineering management in particular. Still, others are specific to Bolt.

The document is far from comprehensive. See our recommended reading list for a glimpse into how deep the rabbit hole goes.

Why are managers needed?

There’s no need for managers in the world of perfectly spherical humans in a void. A single individual can do every action at blazing speed and with maximum competency. The CEOs could run the show alone and have time for a hobby or ten.

In the real world of imperfect, slow and distractible squishy humans, folk need to work together to achieve anything meaningful. They form organisations that can do things above and beyond what any one member could do. But working together takes effort. There’s planning to do, tasks to be assigned and processes to establish. There is a coordination cost to pay. The manager is the name of the person doing these activities and making sure the organisation functions.

A natural way to tackle many problems is to break them down into subproblems. These can be further broken down until you reach a point where the problems are solvable by a regular human. The structure of the problem thus tends to be recursive and hierarchical. It’s also natural to structure the organisation to match the form of the problem.

Thus organisations tend to be recursive and hierarchical: one person at the top — the CEO — is responsible for solving the whole situation. They have several reports responsible for solving particular subparts of the problem. And so on, until you get to individual contributors who have no reports and handle relatively minor work units. The managers form, in any case, a hierarchical structure of reports and own various bits of the whole problem.

The above is, of course, a significant simplification. And it might work for a 19th-century factory but doesn’t apply as easily to 21st-century technology companies.

In technology companies, problems take the form of product domains and are solved by engineering hierarchies. But the managers involved in the process are also responsible to a degree for defining the problem themselves. They’re also leaders. As such, they play dual roles as folk who identify issues, offer solutions and set vision and strategy. But also as folk who execute the operational side of planning, scheduling, staffing, team development, etc.

To add to the situation’s complexity, product domains have many facets and specialisation thus occurs. A problem has several leaders, all focused on particular aspects; product management, engineering, design, research, etc. As the Engineering Manager (EM), you’ll usually be the team manager, having several reports. You’ll work closely with an individual contributor, product manager or designer, or several thereof. You and the Product Manager (PM) will share many responsibilities, but people management will fall on you in particular.

The key thing to remember is that your job is to keep the product domain working. This means delivery through the team — and also successful partnerships with your product domain owners, as well as successfully working with the rest of the organisation. Managers are only successful on their own.Put bluntly, it’s hard to speak of a manager’s performance. Instead, it’s the team’s performance. The manager succeeds if their team and product domain succeeds. They fail if their team fails and they fail if their product domain fails.

The view presented here is the ‘modern approach to engineering management’. It comes from places such as the FAANGs and, further down in history, from luminaries in Silicon Valley. It’s the approach that high-performing organisations take. It emphasises people over processes. It assumes you’re working with a highly skilled and highly scarce individual contributor — the engineer.

It’s very much the ‘Theory Y’ of management. It’s people-oriented rather than outcome-oriented. It does require the EM to stay technical and be an actual engineer.

There are other ways of going about things. Many organisations operate differently. But this document won’t go into that level of detail.

What does a manager do?

Again, in broad terms, a manager is the owner of some part of the organisation and, therefore, some part of the problem that the organisation is solving. This ownership has management and leadership facets. The management one is about building teams, ensuring delivery and quality, providing control, helping with planning, scheduling work, etc. In comparison, leadership is about setting the vision, establishing the strategy, defining the problem, etc.

The above translates directly into the day-to-day and quarter-to-quarter activities expected of you. I’ll go over them in the interest of padding this document further and eventually getting a book deal.

Vision, strategy, planning

As a manager, you’re responsible for the vision and strategy of your team. You’re usually not solely responsible.

You’ll have a PM working alongside you to form the team’s leadership core. Many teams will prioritise setting the vision, establishing the strategy, defining KPIs, and planning and prioritising the work. This is natural and in line with our organisation’s design. But you shouldn’t abdicate responsibility here: you’re not a ‘feature factory’. The rule of thumb is a 70%-30% ownership split.

Conversely, if things go wrong from this angle, it will fall back on you. Of course, there are many aspects here:

You’re succeeding if you manage to create a vision that’s compelling within and outside the organisation. Or in the end, if the organisation actually gives you the resources (budgets, engineers, time, etc.) you say you need!

Conversely, you’re failing if you wait for a top-down vision/strategy/plan from the higher-ups, if you consider yourself just the feature factory, or if your team, other teams or the organisation don’t buy it, or if there’s no clear path to company success via team success.

Building the team

The team is the means through which you do your work in the end. Having a good team is how you do good work. The coarse-grained thing you need to do here is the classic ‘hire/promote/fire’ decision.

‘Hire’ is about whom you accept into the team. Only some people who pass the hiring bar make sense to your team.

There’s the whole discussion here of structuring your team, which means ensuring you have the right skills to deliver on your goals. But an orthogonal thing to consider is how a potential new joiner will interact with the other folks in the team:

• Are they similar to the team regarding work ethic, level of care about the product, the same approach to technology, etc.?
• Are they different to the team in a way that enriches the team’s perspective — life experience, ethnicity, etc.?

‘Promote’ is about to whom in the team you give extra responsibilities. You must consider both the formal career ladder and the informal Team Leader (TL) / Group Team Leader (GTL) roles. This ties into the structuring of the team discussion and extends to the values part. Values are those things people get rewarded for doing in the end and the distribution of the limited resources you have at your disposal.

‘Fire’ is about whom you decide to let go from the team. There’s the traditional meaning of letting go of bad performers, but it can also mean letting go of strong performers who cannot achieve their career aspirations in your team. Of course, they might want to leave the team, too. It can also mean letting go of folk who aren’t living up to their potential. This is a subtle and tricky point and ties in with issues of team structuring, compensation, compensation debt, etc.

As a baseline behaviour, you must provide a safe space with psychological safety, structure and a shield from the storms outside the team’s perimeter.

You’re succeeding here if you manage to build a team to support your delivery goals, it has a low attrition rate, people are generally happy, etc. Conversely, you’re failing if you don’t manage to do this, the team is underpowered for their delivery goals (or the team is overpowered for their delivery goals), there’s a higher attrition rate, the employee engagement survey scores are bad and not improving, or they’re good but falling.

Growing the team

The hire/promote/fire discussion is big and shiny. It’s easy to consider it the primary concern of building the team. But in fact, taking care of the growth and development of the folk you have is equally, if not more, important. This is fine-grained work in this way. You need to do it continuously. But while hiring has explicit budget constraints, upskilling your folk suffers no such limitation.

The organisation mandates that you do several things here as a baseline. These are regular 1:1s and periodic performance reviews. I won’t go into more detail here, as other materials have covered these topics well.

Things like delegating some of your tasks to a TL, or creating particular roles for folks with special skills (DB owner, Spark expert, etc.), are also ways to grow your team here.

You succeed here if you manage to build a team that isn’t static. Folk feel they’re growing and stretching themselves, and there’s a vital part of doing more with less. Conversely, you’re failing if you don’t manage this; folk feel like they’re not growing, you’re not using their full potential, etc.

Acting as coach and trainer

When your reports have particularly tricky roles, such as people manager, tech lead, group tech lead, etc., you should consider on-the-job training as part of your duties.

This can come from recommending particular books or courses the report should take.

But it should also come in the form of specific training sessions carried out by you or periods of high feedback on their work.

You’re often one or two steps ahead of them in the career journey. So it’s likely their current mental state is fresh for you and many of these skills aren’t yet ‘muscle memory’. Hence you’re in an excellent position to teach.

Teaching and being more involved in their handling of issues are often learning opportunities for you, too. The student teaches the master.

Getting people up to speed

From time to time, we take product engineering candidates from non-traditional backgrounds. We’ve hired developers from Windows desktop, iOS, Android, embedded, etc., as ‘backend devs’. This type of work and the technical and organisational infrastructure have allowed us to do these things.

It’s important to understand that these are gambles on the person successfully transitioning to a backend role. It’s up to you and them together to make this thing a success. Because it is not a given; the candidate needs to expend some effort getting themselves up to speed with the patterns, processes, approaches, technologies, and broad ‘ways of working’ in backend and full-stack development. They need to do this in about one or two calendar quarters.

It’s also your job, as the manager, to make sure that they understand this and that they have some practical learning and development plan in place to do so. It’s the idea that they’re proactive on this, not just coast along at the speed of regular project delivery.

A failure scenario is having a person with 2+ years of experience in the company which you must treat differently from your other mid-levels or seniors because of their skills gap.

This, of course, doesn’t apply if you’re hiring somebody for a particular skill set and don’t expect general contributions.

Partner with their PM and other team leadership

As mentioned above, the notion of teams (groups of people that solve problems together) and the notion of hierarchy could be more cohesive. Folk across different management lines will form a team, and you’ll partner with a PM (and possibly others) to lead the team.

Naturally, this must be an excellent and productive partnership. A house divided against itself cannot stand. There’s a lot to be said about this relationship, but this article is already too long. I’ll let Greg take over this topic.

You’re succeeding here if you have a good relationship with your PM. Suppose I don’t hear anything about trouble. Conversely, you’re failing here if there are tensions, if one is picking up the slack for another where there’s misalignment and if it starts to influence the team negatively.

Partner with other teams

Teams don’t exist in a vacuum: there are other teams around them with whom they need to cooperate in order to solve more significant problems.

Just like folk need to work together in a team, teams need to work together. On the one hand, within the confines of their group and, on the other hand, with other random clients or partner teams. There’s the L2 management and TL hierarchy to make this work, but in the end, it requires cooperation and goodwill between the teams.

You’re succeeding here if you have a good rapport with the other teams, if they can depend on you for changes (and if you can rely on them for changes), if there’s no animosity between the teams, etc. Conversely, you’re failing if there are tensions, if there’s never bandwidth for the others’ requirements, if there’s a blame game going on in every interaction, etc.

Managing the delivery

The most managerial aspect of your job is managing the delivery. This means ensuring work gets done on time, on budget and with an acceptable level of quality.

If the vision and planning part is about establishing what needs to get done in the long and short term, and if the building and growing of the team are preparing the folk who will do the work, then this part of your job is about mapping the work to the team.

The following section is too grounded in the way Bolt works. It has some generalisation but is by no means universal.

Sequencing of work:

• After quarterly planning, there’s an unordered list of items to tackle;
• The team needs to do enough exploratory work to understand the scope of the work and the significant dependencies within and outside the team;
• It’s on you to make sure this happens, and there’s as much de-risking going on as it’s safe to do;
• You know you’re doing well when the work goes as planned. Conversely, you’re not doing a good job if there are always unforeseen issues, unaccounted complexities, or (heaven forbid!) unknown dependencies on overbooked teams.

Assigning the work to individuals:

• Work assignments happen once the job is sufficiently explored;
• You have multiple constraints to satisfy, so this is not an easy problem;
• You want to assign the work to folk such that it has the maximum chance of getting done;
• At the same time, you want to spread knowledge of the various subdomains and systems across the team;
• You also want to assign stretch goals to folk to allow them to grow in the directions they want;
• There’s also team duty, unplanned work, regular quality checks, and engineering work to be fitted in;
• You know you’re doing a good job here when folk can finish the work they set out to do. Conversely, you’re not doing an excellent job if folk are overwhelmed by assigned volumes of work (or underwhelmed by it).

Ensuring that the work is progressing:

• We don’t have a high-pressure culture, but it’s worthwhile to check and debug if the work is getting done in the way you estimated it would;
• Things like designing docs and pushing upfront the hard decisions work here, as well as periodic progress reports, daily standups, discussion of issues, helping to unblock people, encouraging multi-tasking, etc.;
• You know you’re doing a good job here if folk can continuously progress with their work. Conversely, you’re not doing well if folk are blocked, waste time on dead ends, or make too complex designs.

Verifying that the work is done:

• This is a joint PM and EM effort;
• But the team’s leadership is responsible for giving the final seal of approval to a particular roadmap item. PMs can focus on the product aspects and EMs on the engineering ones;
• You know you’re doing a good job when there is a clear definition of done, it’s respected, and there are little or no bugs or issues after calling it finished. Conversely, if there are revisions, constant bugs to fix and production fires to address, you’re not doing a good job.

This part of the work is about project management. And in some companies, it’s handled by dedicated Project Managers. Not at Bolt, though. The EM is the lead Project Manager. You can delegate some of this work to a TL or a particular person as a feature lead.

You’re succeeding here if you’re delivering the roadmap items you said you’d deliver in the time you said you would, with the resources you said you’d spend and at the quality level you said you’d achieve. You’re failing here if you’re consistently not doing this — work falls behind, doesn’t get done, gets done in a buggy or too complex way, or needs to get redone after MVPs, etc.

Technological ownership

Most engineering teams build and operate systems. These are the collection of programs which make Bolt happen.

Building these systems needs to have a generally high degree of quality. Their operation must occur such that outages or other unexpected business-impacting events are rare. High quality here usually means maintainable and easy-to-extend systems. As a litmus test, if ‘Feature A’ takes you one month to implement in one year, it should take you one month (or less) in the next year. Similarly, doubling the team size should double the size of the output of that team.

High operability here means building robust and resilient systems. Uptime, SLA violations, incidents frequency, the impact of incidents, data loss, security incidents, etc., measure this.

There are several key activities you’re the driver of:

• The engineering roadmap items: these are team-specific efforts meant to increase the quality of the code in our systems;
• The migrations to various new technologies: these are organisation-driven efforts meant to increase the global stance of the company;
• The improvement of the operational stance of the team: these are team and organisation efforts around alerting, chaos testing, error cleanup, adding metrics, etc.

You’re succeeding here if you’re building resilient and maintainable systems. You’re failing here if your systems are buggy, hard to operate, constantly crashing, hard to extend, and new projects tend always to be delayed.

Externals management

Some teams rely on a particular vendor to do their job, whereas others engage an external community like the contributors of an OSS project. All of these and more are team-level interactions that need to be managed. It falls to the leadership of the team, and many times to the engineering manager, to ensure they get done.

Participation in the company’s processes

The organisation will rely on you more than on others for the execution of the various processes keeping it in line. They’re non-negotiable most of the time, so you’ll be involved regardless. Two are essential, and I’ll mention them here.

Interviews are how we check candidates before accepting them into the organisation. You’ll have a mandatory role as a ‘hiring manager’ (i.e. filling out the ‘hire’ from the ‘Building the team’ section). But you’ll often be a coding, system design, or EM interviewer. Participation in the interview process should be table-stakes behaviour, even though it’s formally optional at Bolt.

One formal power you have as a manager is that you work with salaries — both your team’s salaries and the overall salary process. But the main rule here is that you want compensation to follow performance.

First, in the gross sense — folk with higher output should get promoted, which should get higher performance. Then in the finer sense — within a band, folk should have performance proportional to pay and in the sense that you first need to prove performance, then adjust pay accordingly. Your role as a manager is to ensure performance makes sense and is correlated with pay in your team.

Everything else

Let’s come back to the point about ownership: in the abstract, you should do everything to ensure your organisation succeeds. Here are some things other managers and I at Bolt have done that we didn’t sign up for:

• Organising team events;
• Office improvements;
• Figuring out CO2 leaks in the parking lot;
• Console folk through illnesses;
• Walk through family problems;
• Debug visa issues;
• Help out with salaries payments;
• Work on a script for our ads;
• Chaperone for visiting higher-ups;
• Sourcing candidates;
• Last-minute conference participation;
• HR work;
• Company process work;
• Dealing with wars, conflict, etc., when you have folk from both sides on the team.

A note about other companies

The above is quite common to tech companies of a particular type. But they’re not the only way to roll. Agencies/consultancies and, by extension, outsourcing companies will have a slightly different model. There, the people aspect is separate from the product and technical ownership aspect. As such, a single manager might have 20–30 direct reports for whom they think about career growth, coaching, etc.

Teams are formed from these and other reporting lines to work on various projects. The PM or product owner usually owns the product vision and the technical ownership aspects.

A final word about the power

As a manager, you have power. Specifically, you have power derived from the hierarchical nature of the organisation. And those at the top of the hierarchy have more control than those at the bottom. The CEO has the most power, and they can (usually) do anything.

But to be honest, visibly using power is an anti-pattern. It should be the last tool at your disposal. Ordering someone to do something represents both a failure of yours to convince the other through reasoned argument that the course of action is the right one, a failure of the other to be flexible and open to your point of view and a failure of the organisation to empower you to make this point across.

I hope you feel this intuitively too, but if needed, there’s a lot of literature you can study.

This is the end of Part 1. In Part 2, I share more about who gets to be a manager and how your career can evolve.