How I'm Planning My PhD

I work as a software engineer, and I want to do a PhD without stopping working. What I enjoy most is designing models and concepts — not only implementing them — and I want to specialize in that: publish papers and books, become a reference, and still keep a foot in the market so I can see theory turn into practice. This note is the map I'm using to get there. It is not the thesis; it is how I plan to arrive at one.

I already have an uncommon combination going for me: a degree in *Aerospace Engineering*, a master's in AI applied to Systematic Literature Reviews, real experience as a software engineer, and a genuine interest in architecture, distributed systems, and formal methods. The challenge is not just "how to do a PhD while working" — it is how to build a career that holds three roles at once: engineer, researcher, and author.

The strategy: three roles that feed each other

Instead of one career, I think of three lines that reinforce one another. My day job is the laboratory — every company has problems nobody has published a solution for (distributed workflows, applied AI, fault tolerance, observability, async processing, platform engineering). Those become research questions. A question becomes a contribution; a contribution becomes a paper, a talk, a chapter, a course, a framework.

This is the whole bet: never choose between industry and academia. Let each one pull the other forward. The market hands me real problems to investigate, and the research produces solutions that go back to the market with more impact.

Turn one idea into many artifacts

A common mistake is to research for four years and publish only at the end. I want to do the opposite — publish early and continuously, so reputation is built *before* the defense. The lever is reuse: a single project becomes many things.

All of it lands in a permanent personal project that grows for decades — github.com/matheusmota with articles, models, benchmarks, RFCs, research, examples, and books.

Think in layers of abstraction, not "areas"

The single most useful reframing came from asking not *"which area do I like?"* but \*"which layer of abstraction should my contribution live in?"\*. Tools change in a few years; problems last for decades. If I want to write books and be a reference, my durable contribution has to sit in the middle and lower layers.

The same principle applies to the *theme itself*: research a fundamental problem, never a tool. The tool is a moving target; the problem is the constant.

The aerospace domain enters as the validation case, not as the contribution. ITA values rigor, modeling, and validation on real systems, so a target statement looks like: \*"a formal model for resilient coordination of autonomous distributed systems, validated on satellite constellations."\* The problem reads as aerospace, but the science leaks into drones, robotics, defense, IoT, and cloud.

The target program — ITA PG-CTE

I'm applying to the PG-CTE program (*Pós-Graduação em Ciências e Tecnologias Espaciais*), a partnership between ITA, IEAv, and IAE. It's a four-year doctorate: coursework, papers, and a thesis. My bet for the concentration area is CTE-E — Aerospace Systems, Tests and Launches, which includes Systems Engineering, Applied Computing, Reliability, and Certification — exactly the software ↔ critical-systems bridge I want.

Before I can start, here's what I need to do.

First, pass the entrance process. Start at the ITA selection process page and pick a program from the PG-CTE listing.

Then submit the application form with:

• Personal information
• A copy of my Aerospace Engineering degree
• A copy of my academic transcript
• A copy of my master's degree in Computer Science
• My Lattes curriculum vitae
• An English proficiency certificate (TOEFL, IELTS, TOEIC, or equivalent)
• A preliminary research proposal — using the official ITA template

And pass the mathematics exam:

• 16 questions
• 1 hour 30 minutes
• Statements in English, taken online

A few things I still need to confirm on the current call for applications: the exact dates, which CTE-E advisors are open to an AI + critical-systems line, the required format of the pre-proposal, and the rules for a doctorate while employed. I don't have a research proposal yet — but I will soon, and the rest of this note is how I'm converging on one.

What the research has to satisfy

Before evaluating any specific theme, I wrote down what the research must do to serve the career I actually want:

• A contribution at layer N2/N3 (a model, a method, an architecture) — not a framework.

Only that becomes a book and a long-term reference.

• A bridge to my day job — the job generates the problems and validates the solutions.

The goal: *"the techniques I published are running in production."*

• A critical domain (aerospace/satellites) as validation, but a generalizable

contribution, so I'm not locked into one sector.

• Rigor: modeling plus empirical validation — the standard ITA and good venues expect.
• Ten years of publications and follow-ups — it can't "end" at the defense.
• An open-source artifact (model, benchmark, or tool) that feeds the permanent repository.
• Room for a reference book.

Five criteria to filter a theme

Whenever I have a candidate idea, I run it through five questions. If it fails several, I drop it.

The last question is the most important — the more general the answer, the better. What I avoid are hyper-specific themes like \*"an algorithm for the flap of one particular aircraft."\* Excellent research, but almost impossible to reuse afterward.

Research directions I'm exploring

Over many conversations, a pattern emerged: I'm less interested in inventing a new optimization algorithm than in how to design complex, autonomous, reliable systems for critical operations — with space as the demanding application domain. The identity I'm circling is *software-defined space systems*: treat a space mission as a distributed, programmable, reconfigurable platform. These are still leads, not the theme — starting points for a literature review and conversations with my advisor.

I go through every candidate direction in detail — three waves of exploration, from orbit optimization to lunar infrastructure to distributed systems — in a companion note: PhD research themes.

The through-line is the one I keep coming back to: coordination under failure and verifiable autonomy. A satellite constellation, a lunar communication and navigation network, or a mission with rovers, drones, and orbital stations is really a distributed cluster operating under high latency, frequent disconnections, and scarce resources. That is software engineering applied to space — and it transfers directly to industrial networks, autonomous vehicles, robotics, and any critical system on Earth. NASA's push toward a permanent lunar presence, like the Moon-base science awards, is exactly the kind of setting where resilient, autonomous systems are not optional.

From "no theme yet" to the defense

I'm treating the PhD as cycles, not a single sprint. Each phase has one concrete output, and I publish along the way so reputation compounds before I defend.

Habits and pillars

None of this survives contact with a full-time job unless the cadence is deliberate:

• Every month: one technical article or post
• Every semester: one talk
• Every year: one scientific paper
• Every two to three years: one book

And when time is scarce — which it will be — I protect exactly four pillars and learn to say no to the rest: work, PhD, writing, health.

Next steps

Concrete and checkable, for the coming weeks:

1. Pick two or three leads and run each through the five criteria
2. Do a mini systematic review of the open gaps for each lead
3. List real problems from my job that connect to those leads
4. Map ITA advisors and lines aligned with the leads
5. Meet my advisor with the filtered leads
6. Create the permanent repository with the structure above
7. Draft the proposal for the strongest candidate
8. Read the current PG-CTE call — dates, documents, and stages
9. Arrange an English proficiency certificate
10. Review basic math for the exam (16 questions, English, 1h30, online)
11. Confirm the CTE-E area and a compatible advisor

This is a living document. I'll update it as the search for the theme converges.