Annie Vella’s path to engineering management was shaped by a deep love of technical problem-solving, years of deliberate skill-building, and a pivotal moment when an absent manager and an under-served support team created an opening she couldn’t ignore. Her story illustrates why rushing into management can be a mistake, how hands-on engineering experience becomes a lasting foundation for leadership, and why the transition is often emotional rather than purely strategic.
Early passion and education
Annie got her first computer at age six, a Commodore 64, which came with a BASIC programming manual; she was fascinated by the idea that typing instructions could make the computer draw things, treating it like an intricate puzzle.
In New Zealand, her all-girls school didn’t teach programming, only typing and basic Microsoft Word; when she asked to learn programming, she was told she’d need to go to a boys’ school, which strengthened her resolve.
She pursued computer science at university, drawn more by passion than career planning, and went deep into theory and math, which she saw as the conceptual foundation of programming.
First jobs and early career
Her first role was as a GIS (geographic information systems) consultant, where she visualized location-based data and fell in love with solving customer problems using technology.
She moved from New Zealand to Australia, then to the UK, where she worked as a contractor; the frequent changes exposed her to a wide range of experiences and technologies.
Within roughly the first five years of her career, colleagues and managers began suggesting she had the soft skills for management: rallying teams, coordinating work, and organizing execution.
She pushed back strongly because her passion was deeply technical, especially debugging; in the .NET world, she became skilled at analyzing memory dumps from IIS servers and took pride in that expertise.
At the time, management was seen as the only promotion path beyond senior engineer, and it meant becoming less technical and more focused on people and delivery, which she resisted.
The turning point, ten years in
While working at a company in the Netherlands about ten years into her career, her manager became largely absent because the company was being sold.
The six-person backend team had periods of low work and little direction; some team members were idle, and errors were going uninvestigated.
Annie noticed a recurring error happening around 2:30 a.m. each night and asked teammates to look into it, which they did without pushback.
She also connected with someone on the support team who was struggling with inadequate back-office tools; the support staff couldn’t efficiently look up orders or resolve customer issues.
She made small but high-impact fixes, like adding a database index to speed up order searches, which dramatically improved the support team’s ability to help customers.
Accepting the role
Her manager, a former senior engineer who still identified with the technical side, was moving to a new project and encouraged Annie to formally take the team lead role, noting she had already been doing the work informally.
She struggled emotionally with the decision, fearing it meant she would stop coding forever and lose her technical identity.
She ultimately accepted because she realized she had already been performing the role, the team was small enough that she could still do code reviews and participate in architectural discussions, and the position would give her official influence over priorities, such as dedicating roadmap time to improving support tools.
She reframed the move as an opportunity for greater impact rather than a departure from engineering.
Why she was hesitant
Her hesitation came from seeing previous managers as non-technical; they had been engineers but moved away from the craft, and she feared the same would happen to her.
She worried that if she stopped coding day-to-day, she would forget her skills and be exposed as “not technical enough.”
Years later, she feels her abstract and systems-level thinking has grown stronger, even if her ability to spin up a new application from scratch has faded.
She emphasizes that the hands-on experience she accumulated over a decade became part of her intuition, helping her recognize bottlenecks, understand trade-offs, and know which solutions fit which contexts.
Advice on not rushing into management
Annie strongly advises against taking the first management opportunity early in one’s career.
She believes engineers should reach a senior level, gain confidence across multiple domains, languages, and problem areas, and develop deep technical intuition before considering management.
This depth allows future managers to mentor engineers effectively up to the senior level and to contribute meaningfully in technical discussions even in unfamiliar areas.
She notes that she once dipped back into coding after stepping into management, reinforcing that the boundary is not always permanent, but the foundational experience is what matters most.
Parallels with the host’s own journey
The host, Gary, draws parallels between Annie’s path and his own: both transitions happened because there was a genuine need and an opening at their workplace, not because they actively sought the title.
Both started doing the management work informally before making it official through a conversation with their manager.
Both believe that becoming a strong engineer first, with broad and deep experience, is essential preparation for being an effective engineering manager.
Where Annie is now
Annie has become a highly regarded engineering manager, known for helping her teams grow quickly and inspiring those she leads.
She currently leads a large organization of roughly 50 to 100 people, demonstrating that her delayed but deliberate transition into management did not limit her career trajectory.
