From Academia to Industry: A Letter to My 2021 Self

In 2021, I joined Zup Innovation and became a part-time professor. Before Zup, my last full-time industry experience was right before I started my PhD, when I worked with a few Brazilian companies doing consulting work, mostly around Java-based technologies.

Back then, the tech environment was completely different. The way you applied for jobs, the onboarding process (or the absence thereof), the work environment, the benefits, the compensation, the cloud infrastructure — everything was different. AWS wasn’t really a thing yet, so it was common to deploy services in-house, and continuous integration and delivery were far from being standard practices. People were selling agile left and right, but waterfall was still alive and well. Ruby on Rails — and other frameworks that inherited its architectural and design choices — were mostly discussed in startups, while mature companies still leaned on JEE technologies. That was the scenario I left behind when I transitioned into academia full-time. Thinking and writing about it today, it feels like a lifetime ago. And it really is.

In 2021, when I signed with Zup, AWS was already the king, with dozens (hundreds?) of different services, some of them similar but still subtly different. People seemed to know when to use what, and why. AWS also had company, such as Azure and Google Cloud, though AWS remained the default choice. Java was still widely used, but other JVM-based languages, such as Kotlin, had carved out their own space. Python — which until then I had used mostly for fun — was being adopted far beyond its well-known statistics and data-science niche. JavaScript had grown into an entire ecosystem of its own. And finding a job had changed just as much: LinkedIn had become the king of career moves, and the selection process often started with someone reading what you had written there. Talent acquisition (TA) folks would find you and reach out. Then came several rounds of interviews — technical, non-technical, behavioral — until, with some luck, an offer arrived.

Nothing new here; today, people talk about tech careers all the time. But in 2021, all of this felt strange to me. There are a few things I wish I had known as a researcher before joining a tech company. This post is for my 2021 self.

• Work hard to build a good relationship with your manager. I had the privilege of working with great managers at Zup, but I know this is not always the case. A great manager can shape your career, put you on challenges where you will shine, step in when things start going sideways (and fix them before they escalate), and see you as a partner rather than just someone who reports to them. Great leadership is perhaps one of the most important things you can have in a job. Forget about all those benefits, days off, and fancy offsites. Only a great manager can give you clarity about your work and your future at the company. This is particularly important for academics, who, in their everyday life, do not really have a boss.

• Get to know AWS. As I said, AWS is the king today. But when we run academic experiments, we rarely go as far as publishing them on a cloud provider. Maybe today, with AI research, we buy (or receive) a few credits to run experiments in the cloud — but that’s not the same as deploying and operating an application there. When you deploy, you need to think about permissions, security, roles, storage, processing power, deployment strategies, and, of course, budget. Combining all these services requires knowing which ones fit your scenario and — perhaps more importantly — which ones fit your company’s compliance requirements. Take your time to get comfortable with AWS.

• Practice system design interviews. The selection process today is full of interview stages. One of the most famous is the system design interview. You will be asked to draw, on a digital whiteboard, the architecture of a system, often related to the domain of the company you are interviewing for. So, first, take the time to understand what the company actually does. Second, read about the main components of modern systems: HTTP (and its patterns), caching (providers, what to cache, when to invalidate it), databases (relational, NoSQL, how to structure them, when to shard or split), queues (and when async messaging makes sense). Think about how these pieces connect. Assume scalability is always a requirement, so practice adding nodes to your design. Think about failure modes — what is the single point of failure, and how do you recover? Default to asynchronous communication. Read a good book or two on the topic and practice by sketching a few designs on your own. Researchers usually have a solid theoretical grasp of system design, but this kind of hands-on practice requires you to understand how these tools actually work — and their trade-offs.

• Practice writing code. Here, I would tell my 2021 self to write fewer papers and write more code. The coding challenges we tackle for papers and research tools are, in my experience, on par with what people build in industry. The main difference is maintainability. In academia, it is very common to write code that exists only to support one particular publication. After the paper is out, the code is effectively dead. In industry, you rarely write code with a one-month shelf life (it happens, but it’s not the goal). The goal is to have your code used for years, which means that maintainability and testing become first-class concerns. Read about good practices, and do not skip tests — even a simple coverage metric is more than enough to get started.

• Learn to operate what you build. In academia, once you finish an experiment, you move on. In industry, once you ship, the system is yours to keep running. That means getting comfortable with observability: logs, metrics, traces, dashboards, and alerts. It means learning to debug a misbehaving service in production at 10pm, before the customer complains. It also means understanding deployment pipelines, feature flags, and rollback strategies. For a researcher, this is a mindset shift: the work is not done when the code is merged — it is done when it behaves well for real users, under real load, for a long time.

• Invest in written communication. In industry, especially in remote setups (which was my case), most of your impact flows through writing: pull request descriptions, design docs, incident postmortems, roadmap proposals. Unlike academic writing, which optimizes for rigor and completeness, industry writing optimizes for clarity and decision-making. A short, well-structured document that helps a team make a decision is worth more than a perfectly argued 20-page text that nobody reads. Learn to write for busy readers. For academics, this is both easier than it sounds (we already know how to write) and harder than it looks (we have to unlearn some of our academic habits).

• Move fast — but remember that more speed is not always the answer. A couple of years ago, I wrote about the dichotomy between rigor and value in industrial research. In the lab, time is our friend: an experiment can take six months, and if the results feel off, we rerun it. In industry, time is the scarcest resource. PoCs are expected to be short-lived — you build something small, you ship it, you see what happens, and you discard it without ceremony if it does not work. “Fail fast” is not a slogan; it is the operating model. And, very often, velocity wins the game over quality: a rough version that ships this month beats a polished one that ships next quarter, because by next quarter the problem has already moved. The AI era only sharpened this trade-off — code is now generated faster than we can review, and the pressure to keep shipping only grows. Honestly, I am still not sure what the actionable takeaway is here. I do not believe that more and more speed is always the answer. But I also know that the academic reflex to “do it right” can paralyze you in a context where “right” is a moving target. Somewhere between these two poles lives the job of anyone moving from academia to industry.

***

Five years in, I realize this letter is less about the specifics — AWS, LinkedIn, PoCs — and more about a shift in posture. The academic in me is still there: I still read papers, still run experiments, still write pieces nobody asked for (like this blog post). But the industry taught me to hold my conclusions more loosely, to ship before I feel ready, and to treat most decisions as reversible ones.