How to Thrive as an EM in the AI Era
Case study from The Multiplier Mindset: How to Move from Senior Engineer to Tech Leader in the AI Era
This week’s newsletter is sponsored by Codacy.
The average codebase relies on 10 AI models and 2 coding assistants. Most leaders can’t list what’s in theirs.
For most engineering leaders, mapping their own team's AI usage takes weeks of manual surveys, and the results are obsolete before completion. Meanwhile, compliance gaps keep widening.
With Codacy’s AI Inventory, engineering managers can oversee:
Every AI model, SDK, API key, and MCP server in the codebase, down to the file and line.
Which AI coding assistants their engineers are using and in which repos.
A real-time AI inventory built from source code alone: the foundation for EU AI Act, ISO 42001, and DORA ICT compliance work.
Thanks to Codacy for sponsoring this newsletter, let’s get back to this week’s thought!
Intro
I am currently writing a book, The Multiplier Mindset: How to Move from Senior Engineer to Tech Leader in the AI Era (check out the early release on the O’Reilly website).
The book will feature 8 case studies of successful multipliers (tech leads, engineering managers, staff engineers, and architects), looking at:
How they multiply others
What makes them successful
How they use AI
Their advice to engineers and engineering leaders to thrive in the AI era
Today, I am sharing the case study of Anton Zaides, engineering manager at HoneyBook, which will be included in the book.
Let’s introduce our guest author and get started.
Introducing Anton Zaides
Anton Zaides is an engineering manager at HoneyBook, managing a team of software engineers. Previously, he grew from being a software engineer to director of engineering at Taranis, an agri-tech startup.
Anton also writes a weekly newsletter for engineering managers, Manager.dev, sharing what nobody tells you about engineering managers.
Today, Anton is sharing with us the five areas of responsibility every engineering manager has and how he juggles them. Over to you, Anton!
The 5 areas of responsibility
As an engineering manager (EM) at Honeybook, I manage a team of seven software engineers, from mid-level to senior staff. I started this role around six months ago, taking over an existing team.
In today’s article, I’d like to share some behind-the-scenes stories from my career that I believe helped me succeed and provide my take on thriving as an EM in the AI era. Let’s start with the basics.
As an EM, I have responsibilities across five main areas:
Product building
My team and I build the company’s product. This is the main thing that we are evaluated on and is what often takes about 80% of an EM’s focus.
Team support
I have 1:1s with my team members, making sure they have clear career paths, are being challenged in their work, and are being paid fairly.
Customer support
I ensure we provide good service for our customers and other teams that depend on us. This often clashes with product building and team support. Customer support can slow down delivery, and engineers don’t usually enjoy the work.
Technical direction
This is about how we build things: the processes, the tools, and the tech debt we leave behind.
The team’s future
Where do we want to be in six months? What areas are we responsible for? This includes hiring and pushing for strtegic positioning for the team (e.g., getting important projects).
Focusing on things that the team needs most
I’ve now had three EM roles and each time, I prioritized my responsibilities differently.
A huge part of being a successful EM is adapting yourself to what your team needs, not what you enjoy or what comes naturally to you.
In my most previous EM role, my work was much more technical. I was the main coder and was very involved in the initial stages, building the technical foundation.
There was not a lot of senior talent in the company, so I stayed involved in most technical decisions throughout my tenure, even when I was the director of engineering.
My current EM role is very different.
My team consists of very strong engineers, and the codebase is in Ruby on Rails, which I wasn’t familiar with before starting the job. My comfort zone is to dive deeper and become more technically involved, but in this situation my added value would be negligible.
My time is better spent focusing on two other areas:
The engineers themselves
Even senior engineers benefit from management. Most of the team hadn’t had 1:1s in months before I arrived. There had been no engineering manager for almost a year, and because they were considered strong, they were left to fend for themselves.
My first goal was to talk with each of them individually: understand where they stood, who wanted to get promoted, who felt underpaid, and who wasn’t challenged.
Customer support
My company is B2C-ish, with many customers, and I felt the process of handling support tickets could be improved. Tickets would be open for weeks or months. Some would fall through the cracks.. They really weren’t anyone’s priority, and it’s an area engineers often don’t like dealing with.
So I took on the most annoying and became knowledgeable there. The return on my time was high: I improved response time, communication with support, and overall understanding of the issues we were seeing.
I also focus on my team’s vision, but I’m barely involved in the delivery and technical direction parts! You can’t really focus on all five areas in the time you have, and I feel this ability to understand what’s needed more right now is crucial.
I’ve only been in this role for six months. In time, I’ll be able to become more involved in those areas, but for now they are in good hands. I’m learning slowly by fixing customer tickets.
How to be a truly product-minded EM
Every amazing EM has at least a bit of a product manager (PM) inside them, and this is doubly important now. With LLM, code is no longer the bottleneck; engineers are now waiting for PMs.
With many organizations expecting engineers to take more ownership and make product decisions, there is no way to succeed in our jobs without some PM skills.
I divide being product minded into three parts.
1. Product involvement
I like product management. I listen to Lenny’s Podcast, and I’ve read Marty Cagan’s books. When we understand how PMs work, we can better influence their decisions and better support them.
The very basics of product involvement is understanding your customers’ pains. It can be done by diving deeper into the analytics, watching session recordings, or, ideally, actually talking to customers.
Most organizations are just not built in a way that encourages this, however. There are several layers between engineers and customers, and breaking through them takes some effort.
To get access to customers:
Observe existing meetings. Ask to silently join customer discovery calls run by PMs, sales, or customer service (CS). Promise not to interrupt, just listen and learn. If you have a question, send your contact a private message during the meeting.
Reach out via support. Find a user who has recently complained or a customer ticket that you fixed, and reach out to them. You’ll be surprised how receptive customers can be.
Work with CS to identify a power user. Send a short, respectful email, like: “‘I’m an engineer on the team that built X. I’d love 15 minutes to learn how we can make it better for you.” CS teams are often delighted when engineers take this initiative, because the usual mindset from engineers is “don’t waste my time with useless meetings.”
At my previous company, it took me three years to actually go visit a customer. My company flew drones over agricultural fields, analyzed the images with AI, and provided our farmer customers with insights into the problems in their fields.
Our customers were in the United States, requiring me to fly from Israel to see them in person. I was willing to do that, but the farmers were also super busy and didn’t really want to talk to engineers.
Then our CS team got me in touch with one of our customers by identifying a power user. They connected me with a customer who was really enthusiastic about one of our latest releases.
They mentioned that an in-person meeting would be more effective, as on Zoom our customer would turn his camera off and wouldn’t have a lot of patience. So I drove 10 hours from our office in Indiana to that customer in Iowa for just a 1-hour meeting. Let me tell you: It was so worth it!
I saw how he used our app in real life on an iPad. It turns out that in one of the critical flows, this customer jumps from our app to another app on his iPad to get some data and then returns to ours. That’s not something we knew. I asked about it, and he mentioned that it’s very annoying but he has gotten used to it.
There was a question I asked that he couldn’t answer, so he just called an intern into our office. It turned out that the intern is a super-enthusiastic user, who of course is never invited to Zoom calls because he is not senior enough. I got a lot of great product feedback from him.
I believe that this single meeting helped my product orientation more than a year of session recordings could.
2. Business understanding
Most EMs skip understanding how the company makes money and how their team is connected to it.
My previous team had been writing all the software for the drone pilots, who were internal users. They were a critical part of getting the images needed for our product to work, but my team didn’t directly impact revenue most of the time.
The company’s gross margin was less than 50%. This means that for every dollar our customers paid us, we got less than 50 cents. That was largely because we need to pay the drone pilots to actually go fly the drones and take images. We had a goal of increasing the margin to 60%, which my team was heavily involved in.
Of course, we didn’t want to pay the drone pilots less; they’d leave otherwise. What if we could help them fly more fields per day and we split the gains? For example, if they usually flew over 10 fields a day, we’d improve the software so that they could do 15 instead. We’d pay a bit less for each field, but they’d still make more money overall.
We built a super-small feature that helped the pilots plan their routes better, and it improved the pilots’ outcomes by 11%!
Once we released the feature and I saw how excited everyone was about the gross margin part, I started to mention it in conversations and immediately saw an impact.
For example, I had wanted for a while to improve our app’s stability, but it was never a top priority (as often happens with internal apps).
But mentioning how we’d be able to hire fewer support engineers the following year (who scaled linearly with the business) and increase our gross margin, I got a much better reception.
Once you get used to thinking in business terms, there is no way back. You start to question every part of your work, which is a great thing.
3. Extreme dogfooding
The final part of being product minded is to truly understand your product from the inside.
Two years ago, I read From Worst to First, a book about Continental Airline’s CEO, Gordon Bethune, who transformed the airline from the worst to the best. One idea stuck with me: Bethune got a commercial pilot’s license so that he could speak the same language as his pilots and understand them better.
I decided to experience firsthand how our apps were used. I got a commercial drone pilot license from the US FAA. During the preparation, I spent some time with our operations team (my main customers), and it was a great opportunity to bond. Then I worked a full day in the field as a drone pilot, doing real flights for our customers.
This really helped me understand better how our app was being used and the difficulties with it. I even discovered small things, like needing battery power for the laptops and having a hard time seeing things on the screen because of the sun.
Go extreme with dogfooding! Uber’s CPO spends a day each month driving an Uber! If he can find the time, so can you.
Build a team that doesn’t depend on you
As an engineering manager, you don’t want to be a tunnel that everything must pass through. I want my engineers to talk directly with product managers and designers. Just conversations shouldn’t be constrained by my schedule.
I want my engineers to be able to decide things on their own. They should consult me when needed but not depend on me for every decision.
For every new project, I assign an engineer as the responsible owner. I’m on the sidelines; they communicate, they share the successes, they get the recognition. That’s how you build a team that is more autonomous and less dependent on you.
Another part of building an autonomous team is giving team members exposure to the day-to-day. When engineers deal with real problems and real requests, they build context. Over time, they make better decisions and move faster because the knowledge isn’t centralized in one person.
On a previous team, too many things passed through me. So we introduced a team representative who would be responsible for day-to-day operations. Support talked to the rep, the PM talked to them, and all requests went through them.
It reduced dependency on one person, built more context across the team, and helped people make better decisions over time.
There’s also advocacy.
As a manager, you need to fight for your people for promotions, raises, and recognition. You have to advocate in smaller ways too.
Telling someone they did a great job on a project, that you appreciate how they handled a challenge is underrated. People are often surprised by that recognition, but it goes a long way.
My approach to AI adoption
AI adoption is a tricky balance. On one hand, you need to let people explore on their own and not force AI on them. On the other, you need to nudge them into trying it and give them the time and space to do so.
If people focus only on their day-to-day work, they won’t explore, and they’ll become less relevant over time.
The best ideas will come from the engineers themselves. There’s no need to force AI exploration. Just create the conditions for it and nudge them once in a while.
A good example of this is the AI hotfixer one of my engineers built. As soon as a support ticket opens, an LLM-based process scans commits and tickets from the past few months, suggests the likely cause, and surfaces similar tickets with their resolution steps.
This turned out to be super helpful. A hotfixer shift lasts a week, and you don’t always know what happened the week before. Many issues are recurring, but because each engineer is dealing with them once, the pattern is invisible.
Instead of debugging a complex issue from scratch, you can see that it also happened last week and the exact steps someone took to resolve it, sometimes saving hours.
More importantly, it changed how we handle recurring problems. When you can easily see similar issues across time, you can spot patterns and you’re much more likely to solve the root cause.
Our production load decreased by 30–40% as we worked through those root causes one by one.
This is what “give space to explore” looks like in practice. There was no mandate to improve our processes with AI. An engineer just did it because they had the time and the trust to try something.
Another critical point is that most conversation about AI in engineering focuses on the tools themselves, but I think the bigger challenge is what changes around them.
The first that changes is that development becomes cheaper, so decisions matter much more. When code is cheap to produce, the cost of building the wrong thing goes up, because you can ship bad decisions faster.
This means managers must be deeply involved in what gets built, not just how (another point for product orientation!).
The second is that implementation becomes very easy, meaning you need more rigorous planning, not less. The discipline to stop, think, and plan before touching code is harder to maintain when the friction of starting nearly disappears.
Using AI personally
I work about 90% of the time in Claude Code. The most significant change in how I work isn’t that I write code faster; it’s that I’m managing context across a complex, multiperson project.
I’m currently working on a greenfield project involving more than 10 people, who are running in parallel across different streams. One of the engineers set up a Git repository that holds all the context for the project. I was skeptical at first, but it works remarkably well.
Meeting transcripts automatically sync into the repo. The repo connects to Slack and can summarize discussions. There are markdown files organized by topic that automatically sync to Notion as we work on them. The repo becomes a living, queryable record of the project, not just our decisions but our thinking.
When I want to get up to speed on a specific part of the project, I just talk to Claude. I can ask what specific people think about a given decision, and I’ll get an accurate answer grounded in the Slack threads and meeting transcripts.
Instead of scheduling 10 conversations to understand where 10 people stand, I can ask one tool to figure it out for me in minutes.
Final advice for engineering leaders
All of this distills down to three things you need to do to be a successful EM:
Stay a part-time engineer
Even if it’s only a small part of your workweek, you need to stay active. Our whole career is changing, and to fully understand what your engineers are experiencing, you have to be part of it.
Become product oriented
You and your team must become product oriented, if you’re not already so. Understand the PM world, talk with customers, and get closer to the business.
Get to know the people you work with
Human connections matter more than ever. Create opportunities to get to know your team and your customers.
Last words
Many thanks to Anton for sharing his experience as an EM with us! Sign up for the Manager.dev newsletter to get one practical idea every week on how to be a better EM.
Liked this article? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone that would find this helpful? Make sure to 🔁 share this post.
Whenever you are ready, here is how I can help you further
Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.
Interested in sponsoring this newsletter? Check the sponsorship options here.
Take a look at the cool swag in the Engineering Leadership Store here.
Want to work with me? You can see all the options here.
Get in touch
You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.
If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.
This newsletter is funded by paid subscriptions from readers like yourself.
If you aren’t already, consider becoming a paid subscriber to receive the full experience!
You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.
 | A guest post by
|