Seventeen months into his time at Abnormal, Anchit Arnav manages the team responsible for outbound email security. It's a role he moved into after years as a senior engineer, and the transition taught him something that sounds simple but takes time to believe: the less you do yourself, the more you can accomplish.
The Moment That Changed the Math
A few quarters before Anchit became an engineering manager, he had an idea for a product that would address a real customer pain point. In previous roles, he would have built it himself. This time, he handed it to a teammate.
"I was surprised that I was able to drive a much larger impact than I could have done by writing it myself," he said. "It went into areas that I did not think about and it created an impact that was much higher than I had initially calculated."
That outcome reframed everything. The value he could create wasn't capped by what he personally could ship. It was multiplied by what he could enable others to ship. From that point, the move toward engineering management wasn't a career ladder decision. It was a logical conclusion.
"Stepping back from code is a place where I can create a much larger impact than always doing things myself."
What surprised him about the transition wasn't the difficulty. It was the continuity. The role felt less like a departure and more like the same job at a different altitude. "You're doing the same thing again," he said. "You are still contributing to give out the very best to our customers, just in a different capacity. You were previously doing it when you were writing code yourself. Now you're inspiring people to do it."
AI in the Driver's Seat
At most companies, the conversation about AI is still about adoption, about how to get people to use it and how to build it into existing workflows. At Abnormal, Anchit says that conversation has moved on.
"Gone are the days when an engineering manager would start something and would take AI's help to do it," he said. "Rather, in the current stack, AI will always initiate things."
His ops review process is the clearest example. When an on-call shift ends, an automated trigger fires without anyone pressing a button. It analyzes everything the on-call engineer handled across the week, from minor PR review pings to full incident responses, calculates effort, triages activity, compiles a structured document, and puts the engineer in the loop to confirm. Anchit receives a notification when it's done.
"AI initiates the flow. It makes sure it gets the right data. It makes sure that it does things end to end. And it will ask me only if my intervention is needed."
"I'm there only for exception handling," he said. The result is that his engineers aren't spending time on documentation that AI can produce. They're spending it on work that requires human judgment, which is the only work that actually needs them in the first place.
The Hardest Part Isn't Building It
Before stepping into the engineering manager role, Anchit led the development of an Email Attacks Trend Analyser, a graph-based detection system that didn't exist in any formal specification when he picked it up. There was a rough idea, a desired security outcome, and not much else.
"We only had an idea about what is the final security impact we want to bring to our customers," he said. "What kind of attacks do we want to stop? But we never had an idea about how we could do it."
Coordinating across two or three teams, running interviews to separate what people said they needed from what they actually needed, synthesizing contradictory inputs into a coherent problem statement before writing a single line of production code — that was the real work, and it was harder than anything technical that followed.
"The difficult part is not building a very difficult or complex state of the art software. The difficult part is defining the impact that we want to bring and then translating it in terms of the software that we want to build."
When stakeholders pulled in different directions, the answer wasn't to stop. It was to keep people in the room, keep making small iterative changes, and keep moving forward. "You never put down the baton," he said.
One Question That Cuts Through Everything
Thirty minutes into an architectural discussion that was going nowhere, Anchit's product architect did something he still thinks about. Instead of adding more detail to a conversation that already had too much of it, the architect reduced everything to a single question.
"What is the difference that we are making in the lives of our customers in the next three months?"
It reoriented the entire room. Questions that had resisted resolution for weeks started answering themselves, and architecture tradeoffs, scalability decisions, and redundancy choices all became easier to evaluate against that one forcing function. "Surprisingly, when you take that question and try applying it to all the decisions that you have stopped till now, it starts giving you answers for things that you were not able to decide otherwise," Anchit said.
He carries that question into how he now leads his own team, not as a productivity tool, but as a clarity tool. In a company that moves as fast as Abnormal does, clarity is what makes speed sustainable.
Building Fast, Building for Real
Velocity is the VOICE value Anchit returns to most often, and his definition goes beyond moving quickly. "In an AI-enabled world, velocity is a non-compromisable thing. Everybody can build fast, but can you build faster? Can you build faster before the requirement is gone? Can you solve a customer's pain point before it even becomes a nagging problem for them? That's what defines velocity."
Velocity without direction, though, only gets you somewhere fast. What Anchit cares about equally is whether the work actually lands. "You might be using a lot of tools, but is it creating the right impact? This is a primary differentiator between following something for the sake of doing it and following something which actually makes a difference to our customers."
What he finds most meaningful about leading at Abnormal is making that connection visible to every person on his team, regardless of their level. When an engineer understands that their work today, however small it seems in isolation, sits inside a larger outcome that reaches a real customer, their relationship to the work changes. "The moment as a leader you have made it clear to everybody in your team that in the largest journey of the customers, the smallest work that they are doing actually goes ahead and sits, they get a complete holistic idea about the impact of their work," he said.
"I think this is something which makes a huge difference around how people work, how people perceive their own work, and how they feel that they are actually making a difference to the mission of the company."
For Anchit, that is what the engineering manager role is really about: not owning the code, but making sure every person on the team can draw a straight line from what they shipped to someone they protected.
