Pablo García Ruiz logo
Back to blog
2 min read

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.

What research optimises for versus what consulting optimises for Two columns side by side. Research optimises for being thorough on your own timeline: months on one idea, rewriting the same experiment repeatedly, nobody blocked but yourself, and a bar of whether the result is true and new. Consulting optimises for being useful on someone else's timeline: a team, a client, a scope and a schedule, integrating cleanly and shipping on time, with people waiting on you, and a bar of whether it works for them. An arrow between the columns marks the adjustment from one to the other, labelled as a different set of muscles rather than an upgrade in either direction. Depth, or someone else's scheduleEight months of learning which muscles the other one uses Researchthorough, on my own timeline months on one idea rewrite the same experiment five times nobody blocked but yourself the bar is: is it true and is it new Consultinguseful, on someone else's a team, a client, a scope, a schedule integrate cleanly, ship on time people are waiting on you the bar is: does it work for them the adjustment “Not worse, just a different set of muscles than the ones four years of a thesis had built up.”
Two different sets of muscles, drawn as a trade-off rather than a scorecard.

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.