Do you recall the Mad Hatter’s tea party in Alice in Wonderland?
There was:
- Chaos everywhere
- People switching seats
- The March Hare talking about one topic
- And the Mad Hatter about another
No one seems to follow the conversation, and no one can answer the riddles.
If it hasn’t already, engineering management can feel like this!
The work is:
- Unpredictable
- Often non-linear
- And every time you think you’ve got things figured out, something else unexpected happens
Like the Mad Hatter’s conversation, you’ll constantly find yourself jumping from topic to topic. One minute, you’re mediating a team conflict, the next, you're helping an engineer with a technical issue, and before you know it, you're meeting with stakeholders.
The key to surviving this chaos is learning to juggle the many “hats” of the engineering manager (EM) role, just like managing the madness of the tea party.
With this in mind, here are some of the hats you’ll be wearing and how to handle them.
Hat 1 - The counselor
At some point, everybody feels:
- Overwhelmed
- Demotivated
- Discouraged
- Frustrated
- Or disappointed
I’m sure you have as well – it’s happened to me many times.
As the EM, your team members will deal with these emotions from time to time, and they’ll need your help getting through them successfully.
This is a key part of your job.
And it will look different from team to team and person to person. But there is one constant: everyone will require this kind of support eventually. Recognizing how and when is something you’ll have to learn with time and practice.
But balancing this support with performance standards can be tough. As an EM, you need to provide emotional support while also making sure the expectations are met. It’s certainly complex to navigate, but it can be done with understanding and empathy.
Providing emotional support
I’m not talking about just offering support for major life crises – it’s also crucial on a day-to-day basis. For many, separating our personal lives from our work ones is hard because we carry ourselves with us wherever we go, including our:
- Behaviors
- Attitudes
- Beliefs
- And so on
Take, for example, a perfectionist. This trait doesn’t just show up in their personal life – it’s a part of who they are, so they’ll carry it into their work life, too.
An engineer like this will be a great member of your team. But they will also struggle when they can’t make a task they’re working on perfect.
The closer they get to the deadline, the worse their struggle becomes. This quickly spirals into them feeling like:
- Everything is going wrong
- The processes aren’t working
- They are useless
- And you’re going to fire them
Of course, none of this is true. What is true, though, is that they need some emotional support.
In this situation, you’ll want to:
- Talk to them
- Reassure them
- And help them gain some perspective
Perhaps suggest they get some rest or encourage them to take some time off and have a vacation. Importantly, reassure them that nobody is going to fire them and that it’s okay not to be perfect.
Hat 2 - The hiring manager
As you may know, somebody else does the initial recruiting or head-hunting. However, you, as the EM, help interview those candidates. And asking generic questions won’t give you the information you need, so everyone has their own unique methods.
For example, some people set tests for engineers to complete. We approach it a little differently. Specifically, we ask to see their code prior to the interview or view GitHub for their previous work. This let us see:
- When they did the work
- How much time they spent on it
- Their thought process behind the code
- And if it was copied
But, for me, evaluating hard skills like coding is much easier.
The real challenge is determining a candidate's soft skills and personality. This is the tricky – but essential – factor. Interviews are your chance to understand who they are and see if they will fit with your team.
Learn to read between the lines
You are an interrogator of sorts.
It’s natural that in an interview setting, the interviewee is going to do their best to tell you everything you want to hear. After all, they are trying to sell themselves. Your job is to find any discrepancies in what they say.
For example, let’s say you’re interviewing an architect, and you say your company is 100% remote. The candidate replies, “That’s great. That’s exactly what I’m looking for.”
Then, later in the interview, you ask them why they left their previous job. They say, “Well, I like to go to the office, and I never got to actually see my colleagues there.”
Here, you can see the discrepancy in what they’re telling you. They claim to be excited about remote work, but in reality, in-office work is important to them. This doesn’t necessarily make them a bad person, but it highlights one way they’re not aligned with your company’s culture, which may cause you trouble in the future.
But this is just one area. You need to assess a candidate in many, such as seeing how they:
- Fit with existing team dynamics
- Will handle resource limitations and time constraints
- And so on
Hat 3 - The negotiator
As much as you’d probably prefer to avoid this, negotiating conflicts between team members is – or will be – very much part of your job.
The best approach to conflict resolution is to start by listening to the two sides:
- Separately
- Without judgment, bias, or emotion
- And with acknowledgment of their viewpoints
This structure gives them space to express their thoughts without interruption.
You want them to vent, but you also want each party to accept their role in the conflict. If they can accept that they did something wrong or contributed to it in some way, it will be much easier to resolve the situation smoothly. If they don’t admit any responsibility, you have a harder task on your hands.
Also, you’ll want to focus on reaching a resolution rather than finding an absolute victory for one side. Oftentimes, the key to this is finding something you can offer them to save face.
Finally, bring them together in the same meeting and have them apologize to one another. Most of the time, these steps together resolve the conflict.
And remember, you’re not looking for a “winner.” Your goal is to find a win-win solution, where the two people can work together again, and there are no hard feelings.
Hat 4 - The technical expert
This is the hat you’re probably most comfortable with. After all, this is your foundation and passion.
And because you have a deep technical understanding, you’re able to easily build:
- Rapport
- Trust
- And credibility with your team of engineers
It also allows you to seamlessly work with various technical teams. Although you may not have actual experience in the different fields, you understand them and their processes.
And, with your own team, you’ll be able to:
- Comprehend their problems, challenges, and scopes of work
- Relate to their concerns
- Make them feel seen
- And help them find solutions
But you also won’t want to take this hat off. In fact, this is the one most new EMs struggle with until they accept they’re no longer doing any technical work.
You can still maintain your technical expertise, but it’ll be through your team instead of alongside them. Instead of coding yourself, you’ll be learning from your ICs’ ideas, progress, and problems. They will keep you relevant, which will help you manage them and their needs better.
Hat 5 - The interpreter
You’re going to participate in meetings with many individuals and groups, many of whom do not have a technical background. You’ll quickly discover that a significant portion of your responsibility is finding ways to communicate with them.
When EMs first start in the role, they often think their role is advocating for the technical team. As the bridge between the business and the technical worlds, they assume they are on the technical side in a discussion. But in reality, the opposite is true: they are advocates of the business side.
This is a hard shift to make, but in order to advocate for the business side and be a good EM, you need to let go of your engineer mindset. That means forgetting the idea of perfect solutions or blaming managers and stakeholders for problems or decisions you don’t agree with.
Instead, you must learn how the business actually operates:
- Why these decisions are made
- Where the money comes from
- And what the business goals are
In short, you need to become aware of the bigger picture.
And whether you’re explaining the business strategy to the engineers or the technical details to the stakeholders, learning to talk to people in their language is the key to successfully conveying information.
For example, an AI engineer will enjoy talking about:
- RAG
- Foundational LLMs
- And agentic systems because that’s what they are really interested in
But non-technical players will say, “Hey, I don’t know what LLMs are. I’m not interested in that!”
What they want to know is how any of this will affect the product timeline or the bottom line. So, in this case, you would switch languages accordingly.
The short version: master the many roles
One of the most surprising things about being an EM is the number of hats you’ll wear and how often you’ll have to switch between them. Some of these hats include:
- The counselor: support your team when they get frustrated, distraught, or overwhelmed
- The hiring manager: use specific strategies to really learn about your candidates and their work and to look for any discrepancies in what they say
- The negotiator: work with people in conflict to help them come to an understanding so they can work together effectively again
- The technical expert: learn through your team to continue improving your technical skills, and put them to use by relating to their concerns and using what you know to solve them
- The interpreter: translate technical language into non-technical language and vice versa to help everyone see the big picture and move it forward
It will feel like you need to be an expert on everything at all times, and you’re often expected to do contradictory things. For example, you'll provide emotional support to someone who you may fire later, or you have to be technical and track all the industry trends while not doing any hands-on work.
But everything is part of the process. Do what you can, and don’t let results keep you down. Adapt to what’s in front of you and keep everything running smoothly, even when the situation seems out of control.
Soon, you’ll be switching between these metaphorical hats (and more) as easily as you would physical ones.
Want more tips on leading effective software engineering teams?
Join my newsletter if you’ve found this content useful
Originally published on Medium.com
Content in this blog post by Alex Ponomarev is licensed under CC BY 4.0.
