We’ve considered what we value as an engineering manager (or leader). How can you do performance appraisals without a concrete framework for evaluation? How do you evaluate those wishy-washy soft skills that are so clearly not objective? And does being a good manager mean that you will perform well?
Today, I’ll discuss engineering management. What does it mean to be a manager? We’ll examine some strategies for your growth. How might your managers be evaluating you?
What is a (Software) Engineering Manager?
Being a middle manager often referred to as a Software Engineering Manager or Software Development Manager, is hard! You must balance soft skills with technical skills and manage expectations up, down, left, and right. You will likely be told what you need to achieve and maybe even how you need to achieve it (depending on your manager’s style).
When I think of a software engineering manager, I think of someone who glues the team together in whatever way they need. That means if your team needs a strong product manager because you’re a platform team without one, it’s your new job. If your team needs a strong project manager to ensure you hit cross-squad delivery targets, that’s your job. If your team needs a strong technical architect to ensure you build the right thing, you guessed it – you.
This role changes every company as different expectations are placed on you. It will even change every team as your manager has different expectations about what a manager should do. Overall, it’s about the people and ensuring you create high-performing teams to get the most out of arguably the most expensive function in the company.
Technical Management
Since the great fallout of tech and the removal of zero-percent interest rates, we’ve seen a comeback of managers needing to be technical. We’ve seen this because we need leaders who know when engineers are pulling a fast one and dragging out their work (coasting) or working multiple jobs. Knowing what kind of output and outcomes are expected from each level of seniority in your team is important. How can you measure that if you’ve never been technical?
By remaining technical, I don’t think you should be coding (unless you’re more like a team lead with three to four people reporting to you). Technical management means you remain as close to the engineers as possible – their source of truth – the code. You should be active in code reviews, deployments, on-call, technical assessments, and architecture. It doesn’t mean producing non-blocking/low-impact code that keeps you just technical enough.
Technical managers should know the details about the chosen technology and architecture and the trade-offs the team has made over time. You’ll build up a range of technical debt that will increase the maintenance cost and decrease your speed. Technical managers should be able to justify technical decisions to all types of stakeholders. Think about the complex system you’re building today (either monolith or micro-service-based) and how all the parts work together. What decisions do you make to build upon relational databases vs. document databases? How do you decide to build or buy? What made this architecture event-driven? As you get more scope and responsibility as a manager you’ll start thinking about the systems and less about the services.
People Management
Honestly, this is the most important aspect of the job. The relationships you build will help determine how your team’s impact and delivery are measured. You’ll need to learn what makes each person tick and adapt your management mental model to them. There are some theories on this below – situational leadership and task-relevant maturity to guide you in the right direction.
Let’s understand that software engineers are highly skilled people. They leverage their creative and logical thinking to build software that powers the world. Understanding that they are people and not just resources to be moved around will help you be an empathetic leader. Having empathy in this line of profession will help build up psychological safety.
Does this mean you need to know everything about the person you are managing? No. But you should have the trust and relationship built up that if they screw something up (and they will), they will come to you. If you don’t have a relationship – they’ll likely try to hide or point the blame elsewhere when things go wrong.
So how do you build up trust? One of the best and (most proven) ways is by having one-on-ones (one-to-ones, 1:1s) with your team. A meeting with each person on your team separately. Ideally, this is a regular occurrence.
Balancing Act – It’s a Fine Line
Balancing technical and people management is a tricky lose-lose situation if you walk the tightrope the wrong way. One false move and you’re likely to end up going down a rabbit hole and not doing what you want. You’ll likely swing both ways as a manager at some point. You might get feedback one day about being more hands-on and technical or you’ll get feedback about retention and growing your team.
Let’s take for example someone who remains too technical and spends most of their time in the weeds and less time people managing. You’re likely to find that their team may be the most technically proficient, but they struggle with impact and growth as their manager is taking all of it.
The other side of the coin is where you focus too much on people and not enough on the technical side. You may see that this manager has no idea what they’re talking about when they present to their peers/managers. They will misrepresent the team, often leading to being seen as incompetent.
What is “Hands-on?”
You might hear you should still be “hands-on” as a manager. Let’s dig deeper into what that might look like in real life. Firstly, as explained earlier technical management is important now, we need to dig deeper into what is hands-on as a manager.
Being hands-on technically means that you are in the trenches with your engineers. You’re not sitting on your ivory tower just telling them what to do, you’re helping and guiding them in every way possible to be the best engineer they can be. That may mean, for example, helping out like a senior engineer would by mentoring through pair programming or mob programming. You’re doing code reviews and architecture reviews thoroughly to ensure consistent quality. You’re testing the product and using it (where possible). You’re looking into your code coverage, quality health metrics (like uptime, or other SRE measures), incident management, 95 percentile response time, or alerting. There’s a lot you can do to be hands-on while not coding.
The other side of being hands-on is the people and process. How close are you to your team and how well do you understand them? How is their communication with other stakeholders/peers/cross-team? You need to look at what drives your team forward and the processes slowing you down. Sure, you adopted Agile (with a capital A) but you still follow waterfall monthly release cycles. Are there things you can experiment with like trunk-based development and feature switches? How can you deliver value to your customers faster? How is your team perceived by other leaders in the organization? Are you open and collaborative? Getting into the details here and following up will help you be hands-on.
Project Management
As a Software Engineering Manager, you’re generally responsible for your project/product/feature/etc delivery. This means that you need to be organized! I’ve noticed that some people love project management and others hate it. Project management can be a lightweight framework whereby you have a simple sheet of what your team is working on or it can be a detailed roadmap with estimations and targets.
Most Software Engineering Managers will default to however the company works. That usually means quarterly rough plans (roadmap) of features (or epics) your team wants to achieve and weekly or bi-weekly detailed plans (sprints) of what you’re doing now (especially if you’re following some Agile framework). That’s fine as you mostly need to be tactical (short-term thinking) as a Software Engineering Manager.
If you start to run more complex or multi-quarter projects you’ll need to be better prepared. These roadmaps can go off track very quickly and they’ll need to be adjusted with stakeholder feedback. You’ll need better tracking with clear expectations for each team/person (potentially a Gantt chart). You’ll likely want to follow frameworks like RACI to ensure you align with the right people.
Lastly, understand about risks. What could go wrong? How much of a risk appetite are you/your stakeholders willing to take on? What I mean by this is you need to be able to communicate what trade-offs
Stakeholder Management
Managers do a lot. Stakeholder management is just as important as delivery. Knowing when and how to deliver good/bad news is a far better skill than your hard skills (for management). That means you need to have a good EQ (emotional intelligence). You’ll need to understand the story and emotions behind requests/feedback.
If you’re managing upwards, having a good relationship with your manager is the best place to start. Someone who knows you well will have a better time taking bad news than a stranger. Ensure you understand how and when they like to be told/escalated to and do it. If I tell one of my reports to involve me in an incident as soon as it happens, I mean it. Don’t wait until the incident is over or I find out from someone else. There could be stakeholder management that I need to do as well.
The same goes for your peers across functions. A key to healthy stakeholder management is having a good working relationship. You need to understand why a feature or date might be important to them. i.e. a sales guy sold a feature not ready to a client and suddenly you have a hard deadline or the deal falls through. Ensure you know what they would like to know and when they would like to know it (the how will likely be standard across your company).
Influence vs. Authority
Imagine there are two leaders. One is a Staff Engineer and the other is a Director of Engineering. One of them shows you the best practice and gives you a convincing story of why their direction is the right way forward. They have a history of accomplishments in the company and many people trust their judgement. The other tells you what to do.
You’ll always have authority over those who report to you. No matter how close you get to them, they’ll always know you can fire them. What you need to build is the influence across the organization. How you build your influence depends on what you want to be known for. Want to be known as a problem solver? Fine. Start listening and helping others at every opportunity you have. Want to be known as someone who delivers? Deliver. But it doesn’t stop there, you need to know how to promote yourself (market yourself).
One of those ways is building a network of peers (other managers) in your organization. You want to get to know them and their problems and help them without asking for anything in return (apart from their time). By meeting with other engineering managers, you will quickly gain insights into how the organization works and who are the people with influence.
Ideal Number of Reports
When we look at the ideal number of people reporting to you there is no single number that will satisfy each company. You can have a company whereby you meet your manager twice a year for your performance evaluations and they have fifty reports. Or you can have companies where you manage only three people.
But let’s look at the complexity that goes up the more people that you directly manage. Imagine you are managing 3 people (so 4 people in the team). Each person needs to communicate with 3 other people. We only look at one direction (not two directions of communication), so the formula looks like:
LoC = (n * (n - 1)) / 2Where n is the number of people. Using this formula we can see how the complexity and lines of communication increase. For 4 people, that’s 6 lines. For 5 people, that’s 10 lines. For 6 people, that’s 15 etc. The more people you add, the more complex the relationship problem becomes.
In a “two pizza” solution offered (by Amazon), team size more specifically should be roughly the amount of people who two pizzas can feed. This amounts to between 6-8 people. I find this to be a good-sized team that’s not too large or too small. You can have some more T-shaped engineers (that is, engineers specialised in one stack but can do multiple stacks).
Psychological Safety
According to Project Aristotle by Google, psychological Safety is the most important factor in having effective teams. Everyone feels safe taking risks in front of the rest of the team. Digging deeper means they think there won’t be (m)any negative punishment/embarrassment for making a mistake.
So how can you improve the psychological safety of your team? There are several ways you can do this according to Google. The first is that you demonstrate engagement. Be present and curious, maintain eye contact and practice active listening. Also, how’s your body language? Do you have a “resting bitch face”?
The second way to improve your team’s psychological safety is by showing understanding. That means you summarize what someone said in your own words to reaffirm understanding. Avoid blame and look for solutions. Try to see how the person ended up there, and understand their thought chain.
The next way to improve psychological safety is with inclusiveness. You do this with your 1:1s and weekly team sessions. You can share how you work and encourage others to share how they want to work/be approached. Lastly, be open with your team and encourage contributions and approachability.
Ensure everyone is heard and involved in decision-making to promote psychological safety. It’s the worst feeling when decisions are made over your head. Be sure to get feedback from everyone affected by a decision and don’t speak over them. Explain your decisions (ideally you’ve already created a process to document them) and acknowledge everyone’s contribution.
Lastly, have strong opinions, that are weakly held. You show confidence and conviction but are willing to change your mind with new insights or data. You are a great facilitator and ensure team discussions are cordial. Be prepared to be challenged and encourage it. Push your team further and allow them to take risks and fail.
Task Management Maturity
Each person is different and you need to adapt your management style to each person. Let’s take the Task Management Maturity Model for example. For people who have high competency you only need to set the direction and off they run. For people who have low competency, you need to micromanage and tell them how.
Let’s look into this in more detail. You need to be hands-on when someone has low Task Management Maturity for whatever skill they want to practice. That means getting into the details and telling them what, when, and how they should do it. There’s almost no room for interpretation as it’s highly structured instructions and simple tasks. These will likely be your graduate software engineers or even engineers moving from one stack to a new stack (i.e. app engineering doing infrastructure work for the first time). Your team already likely does this when you break down tasks. The most senior engineers will be helping to create the smallest and simplest tasks for new engineers to do their best work.
When we see them start to mature, you can get out of the weeds. You’ll likely be working with them to set the objectives and goals (they probably can’t come up with these on their own yet). You’ll help monitor the progress and support and coach them through two-way conversations. These are your intermediate engineers who can do tasks and stories on their own but need to be told what stories and tasks to do. You’ll support and grow them with your 1:1s.
Finally, the highest level of Task Management Maturity is when they are an expert. You’ll only want to set the results you expect but won’t tell them how, what, or when to do it. These are your principal engineers (or even engineering managers). As a manager, you should be less involved but still there to support and grow them.
First Team
You’re not alone as an engineering manager and your “team” has changed. One concept you should try to grasp as an engineering leader is that suddenly you feel like you’re a leader of a team but you don’t have a “team.” But, there’s this concept called first team, whereby your team is the other engineering managers under your manager (your peers). This first team is where you can bounce ideas off and grow together. Ideally, you’re all working together on the same problem and can work together to come up with solutions.
Take an example in my case, I have a Retail Engineering tribe that has a focus on online to offline solutions for our retail businesses. My managers can work together to come up with larger roadmaps and make informed decisions on our shared legacy as well as our future stack. We’re also able to share our people around when certain projects are deprioritized over others. The engineering managers work together as a team, their first team.
Growth as a Leader
As we see more and more people stay in their current positions and companies kill the middle management layer (that includes you frontline Engineering Managers), we will see far less headcount growth as leaders.
What we will start to see are more specialized managers with broader (impactful) or deeper scopes. These managers will have strong teams but not larger teams. They will be able to do more with less and be highly technically competent. Their projects will impact multiple teams/products and will require excellent project management and communication.
If you’re growing by increasing your headcount, you’ll find it harder to continue this growth forever – especially when you start to reach more strategic levels of management. Usually, this growth requires luck (the right place and right time), as well as competence (you’re doing your job well). Going from managing no one to managing a team is hard (need a different skillset – management). Going from managing a team to managing multiple managers is hard (need a different skillset – managing by influence). Going from managing multiple managers to… managing multiple managers is easy (no new skills).
To stop yourself from getting stuck in a position, consider talking to your manager. What can you take on from them that you’re not already doing?
Evaluation Strategies of Managers
So, how do you evaluate how an engineering manager has performed given the breadth of their role? And what does make a good manager? Let’s look at some strategies to help you see how we can evaluate managers.
Firstly, hopefully, your manager knows what your team has been working on and how the projects are going. Delivery as a manager will be one of the key pieces of evidence for your performance review. A manager will look at how well your team delivered versus what you committed to. There are multiple ways of looking at how teams commit – but one of the strategies we use is OKRs.
Secondly, get some 360 feedback. 360 feedback is where you look not just from the manager’s perspective (from up looking down) but also left and right (PM, Designer, Business, other EMs), and downwards (the manager’s reports). All this qualitative feedback will give insights and evidence about the manager’s performance.
Thirdly, visibility. How visible is the impact of the team? Did they manage to deploy something that affected the lives of thousands of customers? Did they help reduce the build time of tens/hundreds of engineers? Did they decrease the contact rate of customer service reps? The more visible the impact of the team, the easier it is to justify specific ratings. That’s not to say teams working on not-so-impactful work will be rated worse, it’s just harder to justify higher ratings/promotions if the impact is not there (hint: projects matter).
From the above, you can see that evaluation of management comes down to qualitative feedback and judgement of your manager. Companies may use some quantitative measures (some even weaponize SRE practices/developer productivity) but in the end, how you demonstrate leadership and potential matters more.
The Peter Principle
The Peter Principle is the simple idea that if you do well at your job, you will be promoted. You will continue to be promoted until you can no longer do your job well. This is especially dangerous for software engineers going into management because the “promotion” to management is a misstep and suddenly you’re overwhelmed with people management rather than technology management.
This is equally dangerous if there’s no way for you to return to where you were before. Imagine you’re “promoted” to management but you hate it/are not very good at it. Pretty soon you’ll find yourself on the chopping block.
What you also should watch out for is imposter syndrome. Suddenly, you’re a manager with no clue how to do the role. You just stumble along based on articles/videos/training you’ve done. You feel like you’re faking it and you’re not a real manager. Get real feedback from your peers/manager/directs to help give you confidence you’re doing your job.
Final Words
This is not a comprehensive look at everything a Software Engineering Manager/Software Development Manager/Technical Team Lead does. I wanted to give some insights into how you can begin your journey and what the role might look like today. Remember, you are a human (hopefully) and managing humans – that is the most important thing to get the most out of your high-performing team. You’ll have highs and lows during this career path and your team will change. Stay technical but allow yourself and your team room to grow.
Leave a Reply