Being an Engineering Manager

To be an engineering manager, or a software development manager is a decision you make at some moment of your career. It's not an immutable decision and I'm pretty sure that the majority of software managers from time to time, entry to senior levels, think about returning to the technical path.

That’s totally normal: you were a software engineer some time before, it's your background. Code was your first passion in the software world.

In my point of view, the motivations that made you an engineering manager are one of below:

• situation — the situation demanded someone to lead, the position was offered to you, and you accepted
• challenge — you would like to test yourself on another path
• aptitude — at some point you realised you're good at leading people, sometimes even more so than coding
• curiosity — "what does a manager do? I want to experiment"
• software rockstar — you're very good coding, so probably you will be good at managing too (probably someone thought so)
• career progression — the only way to "make progress" in your career in terms of visibility and compensation would be taking a managerial position

In the list above, there are two motivations that you must avoid when you choose to change from a software engineer to an engineering manager.

Software Rockstar

Here's the scenario: you're very good at coding, have a great ability to discover corner cases, you're the master of distributed systems architecture. You have amazing knowledge about software infrastructure and OS and are always up to date with the latest fancy technologies, plus you know about how to apply them in context. Theoretically, now you have the requirements to be a good engineering manager. Right?

Not true. You also need to think about the below aspects as your primary goals:

• communicate technical problems and solutions in a business manner
• identify what is not working in the team's development process and suggest new approaches
• don't look only at the short term, but mainly for the long term; know the vision for your team and align with them
• valuate more develop people than develop code.

There is a principle called Peter's principle that says:

"People in a hierarchy tend to rise to their “level of incompetence”: an employee is promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another."

Having said that, be conscious when giving a manager role to an amazing engineer just because they're good as engineer. The new role will demand other aspects, totally different with the ones he/she is already good. If they have the potential and the desire, prepare them and go ahead, otherwise it is not a good idea.

The best managers that I know were a good engineers in the past. The best engineers that I know are technical leaders: they lead their peers, not manage them.

Career Progression

If you're working for a company where the only next level for you is to become a manager, probably you're in the wrong place. The technical path and the managerial path are totally different; a vice president (VP) coexists with a distinguished engineer (or a technical fellow). They are both important, with different responsibilities. Different roles, not levels.

I'm an Engineering Manager now

Ok, you took the decision and at this moment the most important thing to know is what is expected from you in the new role.

I’ve been leading engineering teams for 10 years and along this way I could say the role of an engineering manager is based on three pillars: people, product/project, technical.

The three Pillars: people, product and technical.

People are your new priority. Different compared to coding, you can't succeed alone, you need your team. You can deliver a Jira story alone, but not a project alone.

People are different. Good managers know how to deal with this and extract the best out of each person. More than that: you know how to combine those characteristics to create a great team.

Are you putting effort into hiring, developing and keeping people? Do you prioritise 1:1s instead of doing a PoC with Rust language? Do you dedicate a time to evaluate your team, understanding their career needs and how could you boost them? Do you understand how personal life aspects impact work, and help your team to find the right balance between them? Do you recognise who is raising the bar?

Your job as a manager is to identify and focus on the superpowers of your team, not on their weaknesses. Knowing their weaknesses is important to help them make progress, but you should talk about that 20% of the time and talk about their strengths 80% of the time.

I really admire Patty McCord, she was Chief Talent Officer at Netflix and author of Powerful, and said this:

"… they (people) have rent payments, they have obligations, they are members of the society, they want to create a difference in the world. So if we start with the assumption, that everybody comes to work to do an amazing job, you would be surprised what you get."

That explains exactly why I prefer to focus on the strength rather than weakness of my team. What motivates you (and me) is what you are good at, what you do with pleasure, not the inverse.

The other important pillar is the product, or project. I prefer to use the term product, because it is something that is always improving, different from a project that has a beginning and end.

Who are your customers? What do they expect from you? What are the metrics that measure the success of the product you are accountable for? Is your project on track? You need to change the priority of something? What are the milestones? What are the bets for this quarter? How to communicate the progress?

These are questions that you must know. Not only you, but also your team. As a leader, one important attribution is to set the vision, mission and values of your team. This must be a lot of hands-on work, where each one will contribute with their own vision based on the general idea that you brought to the table.

Companies like Amazon require that each team has their own tenets and this is a good way to align the vision between the team, stakeholders and customers.

As a manager, you should lead the planning of your team. If your company works with OKRs, you are the one to start and organise the discussion with your team. Remember: the mission/vision/values will be the baseline for that work, so you don't need to reinvent the wheel each quarter, just adapt based on the macro strategy and directions of your company/org/space.

Ensuring the execution is on track is another attribution expected of your work, at least in the last instance. What is the team software development process? Which agile methodology applies better to the team's context: Scrum or Kanban? Ceremonies are being done? Are the outcomes going well?

You will know your team is at a good level of maturity when those things are happening without great interventions coming from you. The team will be able to identify, for example, that the daily meeting is too long, or that planning meetings are not effective and the team needs a grooming meeting just before. They will do retrospectives even when you are on holidays and do the AIs generated as output of the retro without you having to ask.

Finally, the last of the three pillars: technical. I bet this one will be the easiest for you, because in essence you are an engineer.

You must remember that software solutions are not your primary function. You have senior engineers in your team and they are responsible for designing the technical solution. You should use your experience and make the right questions to ensure that the software is scalable, reliable, resilient, secure and efficient in terms of cost.

Also, you could recommend alternatives based on your background and knowledge in some subjects, but it is important to discuss with your team your suggestions. After all, they will be the ones doing the maintenance and operating the software on a daily basis.

Quality is another important side of your software. Which metrics are important to monitor? Latency, error rate, crash-free, resource consumption (cpu, ram, disk, network)? Which business metric? Business metrics have a strong relationship with technical metrics, once you have a real issue the business metrics will be the first to be impacted. Create alarms to monitor the system to keep your team informed near real time about operational issues.

What are the tools and dashboards that must be created to help the team to operate their software? How does your team react when an incident happens? What are the channels they use to discover an incident and communicate to each other? Create a process about how to mitigate an incident and have metrics, like MTTR and MTTA, to measure the process effectiveness. Create a ceremony to not only plan your product feature backlog, but also to improve the operational excellence. Both requirements have the same importance, same as the roles of software managers and software engineers.

Keep up to date with technologies, the more you know about the work your team does, the more tools you will have to support and contribute to the game. This is not your first priority, but is important to allocate some time in your day to read articles, do some code review, attend some tech talks, or see some technical dashboard.

When you have knowledge about technical things, naturally you create empathy with your team and they will respect you more.

Manager of Managers

As you progress to higher manager levels, the ratio of tactical to strategic thinking shifts. To be successful, you must use both types of thinking. However, it is known that the ratio slants towards tactical thinking at lower
management levels and strategic thinking at higher management levels as they have a broader scope of impact.

When you start to manage managers, it means that you should think in a more strategic way. It’s the moment to think about how to scale your work to not micromanage your teams, but just giving them the direction.

Respect the line managers of your teams, they are on the frontline and probably know more about the details than you. If you strongly disagree with them, try not to do this in front of their team. Instead, schedule an 1:1 and chat about the situation.

Your main job now is to create unity in your organisation and an environment where people feel comfortable to share between the teams that are comprised within.

Keeping conversations with the whole team regularly is important to display your vision of the situation and also because they will be comfortable when you are present in a proper situation. Try to keep regular 1:1s with key engineers, and do some with others. Your work now is more strategic than tactical, but it doesn’t mean that your primary focus changed, it’s still people.

Delegate more and more. This can be one of your thermometers: find a method to keep the things you delegated under minimum control. Don’t punish yourself too much, some plates will break.

As a result of your seniority, you are expected to be more involved in strategic decisions, such as: establishing teams structure, sharing learnings with engineer community, improving the hiring process together with HR team, making decisions on the future of a product or system architecture, having discussions with vendors to negotiate best conditions, driving communication across senior leadership, etc.

The Engineering Manager driven Company

Companies are run by people, not only by managers. Be careful about putting all the load under managers. This is not scalable and also not good for anyone: teams, company, orgs and managers.

A symptom that your company is on the engineering manager driven path is when it is suffering from what I call baby-sitting effect.

Baby-sitting effect

One thing that I realised in some companies is that managers are in charge of everything. For example: let's say a monitoring policy will change, and the manager is told to advise the team about it. In this case, the manager will be the single point of failure — once the change was not informed to the whole team. Therefore change can be slower.

An incident is open for many hours? Most companies's first reaction is to call the manager. Bad decision. You should talk with the team first; if you don't have any answer, then ok, scale up to the manager. As I said previously, the manager is the person responsible for the product/software in the last instance, but the accountability is of the whole team.

Don’t “baby sit” the company teams by delegating exclusively to the manager in charge, otherwise a team will not feel accountable for their product.

What a good Manager should do (IMHO)?

• share knowledge with your team and the community
• train and develop new managers
• anticipate potential sources of failure
• hire, keep and develop the best
• creates a development plan for ICs and more than that: help them to achieve that
• fire someone when it's needed
• receive feedback with good listening
• create goals for the team that matches with the company goals
• give constructive feedback in a straightforward manner
• identify gaps and improve team’s development process
• be a decision maker and results-oriented
• communicate technical problems and solutions in a business manner
• resolve conflicts and deal with ambiguity in many diverse scenarios
• be involved in cross-company initiatives to promote and foment the company’s culture
• be always obsessed to serve customers with high quality standards
• knows what metric are important to your product(s), follow and improve it
• has a good relationship and trust in his peers, such as product managers. Also knows the boundaries between both sides
• don’t look only for the short term, but mainly for the long term; know the vision for your team and align with them
• promote and give visibility to the team’s work
• evaluate and develop people more than code.

I’m going to finish this article with a statement of one the best authors in this subject for me: miss Charity. Below is the best definition I have heard about how is like to be an engineering manager:

You’ll go home exhausted every day and unable to articulate anything you actually did. But you did stuff.

Doing stuff, mainly when people are involved, is an amazing feeling!