After many years of managing and leading teams, I’ve split my perspectives into three areas that allow me to excel and improve in my role. Each one of the areas requires different skills and mindsets. The first perspective relates to the team. The second one relates to outside the team, while the third one relates to your superiors. In this post, I want to share how I think these perspectives can help a Senior Engineer, Team Lead, or Engineering Manager grow and become successful.
For the first perspective — your team, the experience is the foundation on which you must build, and one important brick on top of this foundation is people skills. You can easily get more technical skills and knowledge, but that won’t help you much without knowing how to work with people. And that’s where coaching becomes crucial to you and your team’s development.
For the second perspective, outside the team, that’s when technical knowledge becomes important. Technical knowledge differs from technical skills because you don’t need to execute, but your team needs to. And that execution is part of a bigger context (other teams, other departments, etc.). For example, if you are managing a Back-end development team, your team will most likely collaborate with Frontend or Infrastructure teams. The way you and the other teams’ managers communicate and work together directly influences your team’s success. Effective communication is based on a thorough understanding of technologies, standards, and best practices. You and the other teams’ managers need to choose the right standards, establish processes, and spread knowledge.
The last perspective comes from how you manage your superiors and their expectations. The most important things you need to know is how your manager will measure your success and the results others expect to see from your actions. Not only do you need to know that, but you must be able to showcase the actions and steps you took for bringing those results.
In the following paragraphs, I will go through each of these perspectives and explain why it’s important to develop a certain area and where to start.
Your team
Coaching
When you become a leader or a manager, you need to coach one of the most important skills you need to have. It might sound simple and easy, but coaching is more than a simple skill: it’s a combination of sub-skills built on top of existing technical experience and knowledge. The difference is that you are not actively using your experience and knowledge, but you are using it more passively — to guide. You are not there to do the work and write beautiful, solid code, but you are there to make your team’s code beautiful and solid. So, how do you do that? How do you develop the coaching skill that enables your team to achieve its full potential? It’s straightforward to start after breaking down the “coaching” skill into sub-areas. I will focus only on three in this post: communication skills, empathy, and values.
Communication skills
Before developing any coaching sub-skills, develop communication skills first. You can’t ask the right questions, provide guidance, or inspire values unless you listen to your people first and then communicate effectively. Before taking any actions, a leader must listen to the team, understand what people mean, what they are trying to communicate, and only after discerning the situation should they take action (if actually needed). You can be the most knowledgeable developer, with a champion’s belt full of certifications and 15 years of experience. If you don’t communicate well with your people, you won’t be able to guide them.
For example, many senior developers don’t know how to listen to others. They often jump to conclusions very quickly, without letting the other person finish a full sentence. They then start sharing their experience, how they approached a similar situation in the past, and how they successfully managed it. Then they start talking about another situation which is not so similar, but it’s something that they were also successful at. And then, they start explaining how they would approach things in the future. The conversation turns into a monologue, and while the senior developer is right about the things he or she is saying, those things are not relevant in the current situation. The whole thing becomes a waste of time for all parties involved in the conversation. Why? Because that senior developer didn’t try to understand the situation and get all the facts straight. No situation is similar to another, and different people experience things differently. As a leader, you won’t help anybody unless you fully understand the situations and the “why”s behind them.
How to win friends and influence people — by Dale Carnegie. In my opinion, it’s the best book for developing people’s skills and to learn how to communicate with others. After reading this book, I would recommend going straight to Udemy and picking-up a coaching or communication skills course. Choose something light that’s less than 10 hours, and it matches your area of interest. After taking a course, ask a friend or colleague to help you practice what you learn. I would say that without active practice, reading books and taking courses is not that effective.
Empathy — Facts, Beliefs, and Feelings
Engineers are emotional beings, and it’s challenging for them to empathize with our brains’ physiology. You can’t be analytical and empathic at the same time. That means they have a hard time understanding other people’s emotions, but also theirs. And that’s normal. It’s been proved that analytical thinking represses empathy and vice-versa because of our brain’s physiology. That’s why it’s common for engineers to lose track of their emotions and let them run loose.
As a leader, it’s your role to understand your team’s emotions and help them manage these emotions properly. Did the customer slice the project’s deadline in half? Your team is angry, sweating, and raging? Should you do the same? Absolutely not! As a leader, you need to be calm, come up with solutions while calming your team, and ensure that things are under control. Even if they are not! Does your team still believe that the deadline is unachievable? Is that a fact or a belief that they have? Unhealthy beliefs about customers, technologies, or methodologies prevent teams from achieving their full potential. As a leader, it’s your role to separate facts from beliefs and feelings. Then slowly eliminate unhealthy beliefs and feelings by projecting positive outlooks and relying only on relevant facts.
Inspiring values
The easiest way to judge a leader’s impact and performance is to see how the team behaves when their leader is not present. When the team has the same behavior, the team is autonomous and can achieve success independently regardless of who is around. A leader can inspire his team with the help of values. That’s good when the company has clear values and it’s projecting them. A leader can easily make references to those values, show situations that rely on them, and reward behavior that strengthens those values. Alternatively, when the company doesn’t have clear values or the existing values are not strongly projected, managers can inspire their own values.
Once the team picks up values and principles, it becomes intuitive for them to use them in conflicting situations, difficult projects, or deciding quickly. Thus, as a manager, you can be completely removed from the team, and the team will continue to be successful.
Inspire values in training events, feedback sessions, standups — basically every time you have the chance. Give a shoutout to someone who just took the right action and explain its relation to the values. Ask your team to come up with examples of how they use the values. Take the time to explain your actions, the reasoning behind them, and the values behind them. The more you emphasize values, the easier it becomes for the team to pick them up.
When it comes to your team, many other areas require focus, such as mentoring, skill assessment, bringing new people to the team, performance assessment, and career growth. I believe, though, that it’s important to master coaching before mastering the others. I will cover the rest in a future post.
Integrating your team
When looking outside your team, there are two big areas of focus: working with other software development teams and providing value to the business.
Standards
While standards are important to the team’s output, the software’s quality, and the team’s growth, standards become really important when collaborating with other teams. Take, for example, the way backend and frontend integrate. Usually, this is done using APIs that have standards. Imagine for a moment that these standards didn’t exist, that the way APIs are built is not clearly defined, and instead of using REST, GraphQL, or other standards, everybody integrates with whatever they feel is right. While that might sound a little too extreme, imagine a different situation in which the standard is in place, but nobody respects it, and shortcuts are used to achieve business objectives. It’s only a matter of time before the code becomes unmaintainable, features take twice the time to get implemented, and there is a constant state of conflict between teams. This will put you, as a manager, in a position of conflict mediator, working with demoralized people, or it might lead to the creation of a new standard of communication between APIs — a.k.a reinventing the wheel. To prevent this, it’s a must to hold teams accountable to high-quality standards. The first step is to decide, either you as a manager do it (if you manage several teams) or agree on it with other managers. After that, communicate it to all the teams and start showing them how it’s done.
Technologies
The technical stack or the technologies used represent the second area where you need to focus outside the team. It’s all about how you bring success to the business. Your company owns the mission — the why. Product owners manage the what — the products built for the customers. Your team owns the how — how the products achieve the company’s mission and how they are built.
Every technology has it’s advantages and disadvantages, and there’s always more than one road to get to the destination. Before choosing a technology, you need to understand what the business wants and how the advantages and disadvantages play out in the future. You want to look at horizons that span several months or years. For example: Is your company going to grow horizontally or vertically? If it’s horizontal, then maybe you want to bring in technologies that support the development of features and increase the rate at which new features are developed. If your company wants to grow vertically, you may need to scale up, remove performance bottlenecks, extend into new geographic areas, etc.
After you get the business direction right and you are aligned with your peers, it becomes easier to choose the right technology. You can do that by syncing with your manager or with your other fellow managers. You can also research on your own, explore current technologies and how they compare to other ones. Or you might look at how others in the industry are doing things. There is no definitive answer, but a clear principle: do it constantly, align with your peers on what you and they find out, and ensure it covers the business needs.
Managing your boss
Knowing what to expect from your boss and what your boss expects from you is, in my opinion, one of the most challenging perspectives. There are three levels by which your boss measures your performance, and you will find yourself at least once in each of these levels when your performance is evaluated.
Team success
This is probably the most important level where you want to be. You always want to be evaluated based on your team’s success. If your team is successful, then you are successful as well. It’s the most effective way of measuring your performance. If your team is not successful, you need to figure out how to get there: define what success means (meeting deadlines, reducing support issues, etc.). Try as much as possible to identify a KPI or a way of measuring this.
Quality of management
When your team is not successful or if for some reason your performance can’t be measured by that (for example, your team is just getting started, you need to fire people, you are going through transitions, etc.), then you will most likely be assessed by the quality of your management. That means different things based on different contexts. Are you doing hiring correctly? Are you writing onboarding documentation? Are you documenting technical decisions? Being at this level doesn’t mean that you are not doing something right. It’s just a signal that you should find ways to measure your team’s success or make your team successful. It also doesn’t mean that once your team is successful, you should stop focusing on the management practice— you always need to do the right things and do things right. But it’s all about focus. You need to always focus on your people, on your teams, and prioritize their success first.
Technical knowledge
This is the level you don’t want to be, but you will find yourself there at some point. If, for some reason, your manager measures your performance only by the technical knowledge that you have, then something is not right. Again, it doesn’t mean that you should not be technical, or that you shouldn’t improve your technical knowledge, or that your technical knowledge shouldn’t matter in a performance review. It’s just that you don’t want your performance to be measured only by technical knowledge. And that is for several reasons. First of all, if you are a manager, most likely your technical skills will erode in time, and you won’t be so sharp. Secondly, you need to leverage your people’s technical knowledge, not yours. It’s crucial to prioritize developing their technical skills, improving the team, and using their skills to achieve business objectives. If you ever find yourself being evaluated just by technical skills, then something is not right. It might be the case that your lack of technical knowledge is blocking the success of your team or your manager is not very experienced. Whatever it is, you need to move yourself from that position right away. You can learn the skills, get the knowledge, become hands-on, etc., but do it quickly and efficiently and get yourself to the level where your team’s success measures your performance.
Using these perspectives helped me understand how I can improve and how to be successful in my role. There is a lot more to be said, and I’m constantly improving all these areas. While doing so, no matter the perspective, I’m using one principle: ensure that my team is successful on its own, while working with other teams and that their success is visible in the company.
The three perspectives of a software engineering manager
After many years of managing and leading teams, I’ve split my perspectives into three areas that allow me to excel and improve in my role. Each one of the areas requires different skills and mindsets. The first perspective relates to the team. The second one relates to outside the team, while the third one relates to your superiors. In this post, I want to share how I think these perspectives can help a Senior Engineer, Team Lead, or Engineering Manager grow and become successful.
For the first perspective — your team, the experience is the foundation on which you must build, and one important brick on top of this foundation is people skills. You can easily get more technical skills and knowledge, but that won’t help you much without knowing how to work with people. And that’s where coaching becomes crucial to you and your team’s development.
For the second perspective, outside the team, that’s when technical knowledge becomes important. Technical knowledge differs from technical skills because you don’t need to execute, but your team needs to. And that execution is part of a bigger context (other teams, other departments, etc.). For example, if you are managing a Back-end development team, your team will most likely collaborate with Frontend or Infrastructure teams. The way you and the other teams’ managers communicate and work together directly influences your team’s success. Effective communication is based on a thorough understanding of technologies, standards, and best practices. You and the other teams’ managers need to choose the right standards, establish processes, and spread knowledge.
The last perspective comes from how you manage your superiors and their expectations. The most important things you need to know is how your manager will measure your success and the results others expect to see from your actions. Not only do you need to know that, but you must be able to showcase the actions and steps you took for bringing those results.
In the following paragraphs, I will go through each of these perspectives and explain why it’s important to develop a certain area and where to start.
Your team
Coaching
When you become a leader or a manager, you need to coach one of the most important skills you need to have. It might sound simple and easy, but coaching is more than a simple skill: it’s a combination of sub-skills built on top of existing technical experience and knowledge. The difference is that you are not actively using your experience and knowledge, but you are using it more passively — to guide. You are not there to do the work and write beautiful, solid code, but you are there to make your team’s code beautiful and solid. So, how do you do that? How do you develop the coaching skill that enables your team to achieve its full potential?
It’s straightforward to start after breaking down the “coaching” skill into sub-areas. I will focus only on three in this post: communication skills, empathy, and values.
Communication skills
Before developing any coaching sub-skills, develop communication skills first. You can’t ask the right questions, provide guidance, or inspire values unless you listen to your people first and then communicate effectively. Before taking any actions, a leader must listen to the team, understand what people mean, what they are trying to communicate, and only after discerning the situation should they take action (if actually needed). You can be the most knowledgeable developer, with a champion’s belt full of certifications and 15 years of experience. If you don’t communicate well with your people, you won’t be able to guide them.
For example, many senior developers don’t know how to listen to others. They often jump to conclusions very quickly, without letting the other person finish a full sentence. They then start sharing their experience, how they approached a similar situation in the past, and how they successfully managed it. Then they start talking about another situation which is not so similar, but it’s something that they were also successful at. And then, they start explaining how they would approach things in the future. The conversation turns into a monologue, and while the senior developer is right about the things he or she is saying, those things are not relevant in the current situation. The whole thing becomes a waste of time for all parties involved in the conversation. Why? Because that senior developer didn’t try to understand the situation and get all the facts straight. No situation is similar to another, and different people experience things differently. As a leader, you won’t help anybody unless you fully understand the situations and the “why”s behind them.
How to win friends and influence people — by Dale Carnegie. In my opinion, it’s the best book for developing people’s skills and to learn how to communicate with others. After reading this book, I would recommend going straight to Udemy and picking-up a coaching or communication skills course. Choose something light that’s less than 10 hours, and it matches your area of interest. After taking a course, ask a friend or colleague to help you practice what you learn. I would say that without active practice, reading books and taking courses is not that effective.
Empathy — Facts, Beliefs, and Feelings
Engineers are emotional beings, and it’s challenging for them to empathize with our brains’ physiology. You can’t be analytical and empathic at the same time. That means they have a hard time understanding other people’s emotions, but also theirs. And that’s normal. It’s been proved that analytical thinking represses empathy and vice-versa because of our brain’s physiology. That’s why it’s common for engineers to lose track of their emotions and let them run loose.
As a leader, it’s your role to understand your team’s emotions and help them manage these emotions properly. Did the customer slice the project’s deadline in half? Your team is angry, sweating, and raging? Should you do the same? Absolutely not! As a leader, you need to be calm, come up with solutions while calming your team, and ensure that things are under control. Even if they are not! Does your team still believe that the deadline is unachievable? Is that a fact or a belief that they have? Unhealthy beliefs about customers, technologies, or methodologies prevent teams from achieving their full potential. As a leader, it’s your role to separate facts from beliefs and feelings. Then slowly eliminate unhealthy beliefs and feelings by projecting positive outlooks and relying only on relevant facts.
Inspiring values
The easiest way to judge a leader’s impact and performance is to see how the team behaves when their leader is not present. When the team has the same behavior, the team is autonomous and can achieve success independently regardless of who is around. A leader can inspire his team with the help of values. That’s good when the company has clear values and it’s projecting them. A leader can easily make references to those values, show situations that rely on them, and reward behavior that strengthens those values. Alternatively, when the company doesn’t have clear values or the existing values are not strongly projected, managers can inspire their own values.
Once the team picks up values and principles, it becomes intuitive for them to use them in conflicting situations, difficult projects, or deciding quickly. Thus, as a manager, you can be completely removed from the team, and the team will continue to be successful.
Inspire values in training events, feedback sessions, standups — basically every time you have the chance. Give a shoutout to someone who just took the right action and explain its relation to the values. Ask your team to come up with examples of how they use the values. Take the time to explain your actions, the reasoning behind them, and the values behind them. The more you emphasize values, the easier it becomes for the team to pick them up.
When it comes to your team, many other areas require focus, such as mentoring, skill assessment, bringing new people to the team, performance assessment, and career growth. I believe, though, that it’s important to master coaching before mastering the others. I will cover the rest in a future post.
Integrating your team
When looking outside your team, there are two big areas of focus: working with other software development teams and providing value to the business.
Standards
While standards are important to the team’s output, the software’s quality, and the team’s growth, standards become really important when collaborating with other teams. Take, for example, the way backend and frontend integrate. Usually, this is done using APIs that have standards. Imagine for a moment that these standards didn’t exist, that the way APIs are built is not clearly defined, and instead of using REST, GraphQL, or other standards, everybody integrates with whatever they feel is right. While that might sound a little too extreme, imagine a different situation in which the standard is in place, but nobody respects it, and shortcuts are used to achieve business objectives. It’s only a matter of time before the code becomes unmaintainable, features take twice the time to get implemented, and there is a constant state of conflict between teams. This will put you, as a manager, in a position of conflict mediator, working with demoralized people, or it might lead to the creation of a new standard of communication between APIs — a.k.a reinventing the wheel. To prevent this, it’s a must to hold teams accountable to high-quality standards. The first step is to decide, either you as a manager do it (if you manage several teams) or agree on it with other managers. After that, communicate it to all the teams and start showing them how it’s done.
Technologies
The technical stack or the technologies used represent the second area where you need to focus outside the team. It’s all about how you bring success to the business. Your company owns the mission — the why. Product owners manage the what — the products built for the customers. Your team owns the how — how the products achieve the company’s mission and how they are built.
Every technology has it’s advantages and disadvantages, and there’s always more than one road to get to the destination. Before choosing a technology, you need to understand what the business wants and how the advantages and disadvantages play out in the future. You want to look at horizons that span several months or years. For example: Is your company going to grow horizontally or vertically? If it’s horizontal, then maybe you want to bring in technologies that support the development of features and increase the rate at which new features are developed. If your company wants to grow vertically, you may need to scale up, remove performance bottlenecks, extend into new geographic areas, etc.
After you get the business direction right and you are aligned with your peers, it becomes easier to choose the right technology. You can do that by syncing with your manager or with your other fellow managers. You can also research on your own, explore current technologies and how they compare to other ones. Or you might look at how others in the industry are doing things. There is no definitive answer, but a clear principle: do it constantly, align with your peers on what you and they find out, and ensure it covers the business needs.
Managing your boss
Knowing what to expect from your boss and what your boss expects from you is, in my opinion, one of the most challenging perspectives. There are three levels by which your boss measures your performance, and you will find yourself at least once in each of these levels when your performance is evaluated.
Team success
This is probably the most important level where you want to be. You always want to be evaluated based on your team’s success. If your team is successful, then you are successful as well. It’s the most effective way of measuring your performance. If your team is not successful, you need to figure out how to get there: define what success means (meeting deadlines, reducing support issues, etc.). Try as much as possible to identify a KPI or a way of measuring this.
Quality of management
When your team is not successful or if for some reason your performance can’t be measured by that (for example, your team is just getting started, you need to fire people, you are going through transitions, etc.), then you will most likely be assessed by the quality of your management. That means different things based on different contexts. Are you doing hiring correctly? Are you writing onboarding documentation? Are you documenting technical decisions? Being at this level doesn’t mean that you are not doing something right. It’s just a signal that you should find ways to measure your team’s success or make your team successful. It also doesn’t mean that once your team is successful, you should stop focusing on the management practice— you always need to do the right things and do things right. But it’s all about focus. You need to always focus on your people, on your teams, and prioritize their success first.
Technical knowledge
This is the level you don’t want to be, but you will find yourself there at some point. If, for some reason, your manager measures your performance only by the technical knowledge that you have, then something is not right. Again, it doesn’t mean that you should not be technical, or that you shouldn’t improve your technical knowledge, or that your technical knowledge shouldn’t matter in a performance review. It’s just that you don’t want your performance to be measured only by technical knowledge. And that is for several reasons. First of all, if you are a manager, most likely your technical skills will erode in time, and you won’t be so sharp. Secondly, you need to leverage your people’s technical knowledge, not yours. It’s crucial to prioritize developing their technical skills, improving the team, and using their skills to achieve business objectives. If you ever find yourself being evaluated just by technical skills, then something is not right. It might be the case that your lack of technical knowledge is blocking the success of your team or your manager is not very experienced. Whatever it is, you need to move yourself from that position right away. You can learn the skills, get the knowledge, become hands-on, etc., but do it quickly and efficiently and get yourself to the level where your team’s success measures your performance.
Using these perspectives helped me understand how I can improve and how to be successful in my role. There is a lot more to be said, and I’m constantly improving all these areas. While doing so, no matter the perspective, I’m using one principle: ensure that my team is successful on its own, while working with other teams and that their success is visible in the company.
Archives
Categories
Archives
Recent Post
Using decision trees to map out Architectural decisions
February 23, 2024Moving Beyond Code: From Software Engineer to Architect
June 23, 2023The three perspectives of a software engineering manager
June 4, 2021Categories
Meta
Calendar