Pablo García Ruiz logo
Back to blog

What I Can Say About My Time at ALTEN & Airbus

A short stint as a software consultant on Airbus Defence & Space projects, and what switching from academic research to industry consulting actually felt like.

CareerSoftware EngineeringDefense

Right after finishing my Ph.D. in 2025, I spent about eight months, from May to December 2025, as a Software Consultant with ALTEN Spain, on-site in Madrid, working on defense projects for Airbus Defence & Space. It was also my first real dive into the defense sector.

I’ll say upfront: this is going to be a vaguer post than the others. Defense work comes with confidentiality by default, so I can’t walk through specific systems or deliverables the way I can with a published paper. What I can talk about is the shape of the experience: going from four years of academic research straight into a multidisciplinary engineering team building Python-based software for an industry client.

Research brain vs. consulting brain

Academic research rewards depth: you can spend months on one idea, rewrite the same experiment five times, and nobody’s blocked waiting on you but yourself. Consulting flips that. There’s a team, a client, a scope, and a schedule that doesn’t particularly care whether your solution is the theoretically prettiest one: it cares whether it works, integrates cleanly, and ships on time.

That was the biggest adjustment: learning to be useful on someone else’s timeline instead of thorough on my own. Not worse, just a different set of muscles than the ones four years of a thesis had built up.

Focus areas

Software ConsultingSystems EngineeringRequirements EngineeringDefense & Aerospace

Tech stack

Nothing exotic: Python for the software itself, Git for everything else:

PythonGit

What stuck with me

Working inside a larger, multidisciplinary team, instead of mostly solo research plus two advisors, was the part I got the most out of. Aerospace and defense software has its own conventions, its own bar for reliability, and its own way of talking about requirements that took some getting used to coming from a research background.

Where it didn’t quite match me was the consultant model itself: the role sat on the client’s team without being fully part of it, and day to day that meant more consulting, staffing a client’s roadmap, than actually developing a product of my own. I wanted to be building the thing, not sitting adjacent to it. It was a short chapter, but a useful one: it’s a lot of what pointed me toward the vision engineering role I’m in now, where the work is closer to the product itself.