Career transitions are hard, but academia to industry can be particularly challenging. The learning curve will be very steep (and non-linear), but here are some phases that conceptually helped me constrain what and how much to be learning at a given time.

Phase 1: Make connections

In your first 2 weeks, you will mostly be ramping up by doing onboarding modules, reading documentation, etc. Make sure to also prioritize introducing yourself to other people on your direct team, collaborating teams, and regularly stakeholders (like product managers). This should a main active goal in these first 2 weeks. The purpose is to

Let people know that you exist

Besides your hiring manager, no one will know what your relevant research expertise is and to give you projects. Practice your elevator pitch, and be prepared to deliver it in every meeting that you attend for the next 1 month.

Your second main goal is to

Learn who you can ask for help & resources in the future

For the next month and onwards, develop your gut for to evaluating how long it’ll take for you to learn something on your own. Sometimes, it’ll be faster to learn it by reading documentation by yourself. Sometimes, it’ll be faster to ask someone else for a quick rundown, as well as any meaningful context. Tip: Tell people how many days/weeks/months ago that you started. That way, they can calibrate how much to explain, especially for all the work & project acronyms that you’ll come across.

In the future, you’ll learn who is best to go to for certain knowledge and resources. At the same time, you are also introducing yourself as someone who is open to eventually sharing knowledge and resources back with them.

To have longterm business impact, you need (1) to establish your expertise in the domain you were hired for; and (2) to successfully deliver on important projects. Letting others know that you are the point of contact for these projects is the first step, so invest your time wisely by making the key connections needed for this. Eventually, your goal will morph from not only being the person to take on projects, but to help define project direction.

Phase 2: Learn how to do the bare minimum

A main strength of PhD students is our ability to learn new things. In grad school, we were given the valuable 5+ years needed to do that learning. In your new industry role, you’ll be given some amount of grace period (think 3-6 months) to learn what you need to learn:

  • Learn the tools that are needed for you to do your job & quickly shore up on any technical skills needed
  • Request access to those tools early on (e.g., AWS, internal software, AI tools like Claude Code/ChatGPT Codex/MS Copilot) — it’ll take longer than you think to get approved by the IT powers that be
  • Learn the format of deliverables that your projects will have (e.g., internal team vs. high-level leadership readout, slide deck, written document) — this will likely be brushing up on soft skills that you haven’t done in a while during job hunting

You don’t need to do complete your projects with any of the fancy bells and whistles right now. In fact, actively avoid perfectionism. Agility is more valuable at this stage of your learning and generally speaking, in industries like tech. You definitely don’t need to “disrupt” any markets right now. If you want to, that’s for much later in your career. But definitely not in the first 3-6 months of your job. Learn what is needed to develop a strong foundation to be competent.

However, an important academia vs. industry distinction is:

In industry, learn what is within your role’s scope and what is NOT

When you start to be given projects, it’ll scale up quickly into a “drinking from the fire hose” experience. Don’t say yes to learning new things unless it will directly benefit you and will benefit you longterm. It make benefit you and a requesting team short-term, but if you become the go-to person (because you learned how to do it) for completing requests that are not within your scope, you will quickly be overwhelmed. Learn it for yourself (if you want) to move projects along, but I quickly learned and was backed up by teammates to not let others outside the team know that I had that newly learned ability to complete certain things.

The number of ASAP projects will also pile up fast. A powerful question (and framework of thinking) when assessing taking on urgent requests that I was taught by a teammate is

“What can be deprioritized, delayed, or fully removed from my plate so that I can take on this request?”

This directly highlights the one-to-one relationship that prioritizing one project means deprioritizing another.

Learn the concept of ice boxing

Another (in retrospective, obvious) concept that this same teammate taught me is the idea of an “ice box” or “ice boxing” something. If a project grows “cold”—e.g., requesting team is no longer pushing on it or, more importantly, results would no longer informative—then ice box it until/if it becomes relevant again. When projects have been ice boxed for longer than a few months, you can usually remove it from your plate entirely unless your hiring manager might tell you otherwise.

Why was this novel to me? In grad school, we have a “backlog” that we work through. We’re used to working on very long timelines compared to industry projects. Even if we can’t get to something asap, we’ll likely eventually get to it. This ofc excludes TA class work.

In (the tech) industry, if you maintain a backlog like completionists/perfectionists like me, it’ll scale like Everest. The concept of ice boxing helps manage the number of total projects on your plate and how to prioritize them.

Phase 3: Learn how to do things better

So now that you’ve spent the last 3-6 months (or longer! take the time that you need!) learning how to be minimally competent, now your goal is to learn what it takes to improve your processes. Again, no need to “disrupt” or “break” anything—insert other tech jargon here—within your team/org. Just think about what you can do to improve your own work.

Reflect on things like:

  • How successful has your personal organization process been? Can your intake process or communication with other collaborating teams be improved?
  • Have you noticed data limitations? What would it take for you to have access to the data or level of data that would make your work more robust and impactful?
  • Can anything in your process be automated? Can you write any scripts that would automate repetitive workflows like data cleaning?
  • Can any communication processes be converted into templates? e.g., slide decks, slack canvases, PRDs, SLAs

This might mean comparing your personal workflows with other teammates and learning new strategies and overhauling what you are currently doing. This might be mean filling in some blanks that you hadn’t learned previously.

I remember asking The Teammate for yet another walkthrough:

In my first 3 months, I learned how to do “A-C-E” to get my initial projects done. Can I ask you to walk me through your workflows again? I feel like now I’m learning how to do “A-B-C-D-E-etc”.

I had already asked her for a walkthrough when I first started my job, but I hadn’t fully understood all the nuances back then because I didn’t have the knowledge and context that I did 3 months later. She’s been very generous in walking me through anything as many times as I’ve asked because we both love talking process and organization. It is also good to ensure that your A through E processes align with your manager’s vision of A to Z.

Again, this means investing in new processes that would help you longterm (e.g., I spent a solid month early on in my job developing new data collection processes that I knew would not only help others longterm but more importantly, would help me get my own work faster and better longterm).


Be protective over your time & energy

You will inevitably get better at the things that you put time and energy into. Be careful that you intentionally take on work that moves you in the direction that you want. It is good to be well-rounded in the longterm. Leaders should be able to balance both technical and high-level strategy thinking. But make sure that you know how you are being evaluated today and whether that matches the direction in which you want to be moving.

Concrete example: Women in tech are often asked to take on work that is outside their IC (individual contributor) role. This might be pitched as leadership opportunity. Which sounds and genuinely can be great. However, as you are just starting out, you will be evaluated as an IC, not a manager. If you take on managerial work, you will inevitably get better at it — but early in your career, this may take away time needed for you to be learning the technical skills needed to be a stellar IC and to be recognized as such. Because of this, you may get tracked into a managerial role because that is now where your skillset is. This can be great, but only if it was a goal of yours to be a manager.

Don’t let external validation about your ability to learn new things be used against you in a way that leads to burnout or dilute your execution on projects that you want to build your career on. I highly recommend reading this article on “glue work”: https://www.noidea.dog/glue


Phase 4: Learn the market trends & data gaps

One of the most important things that I realized is that everyone is learning about AI at the exact same time that I am. (My work involves evaluating GenAI models.) This means that there’s no standard for expertise what what one should know. In fact, I learned that my true value in my job is identifying what we don’t yet know in the market and figuring out ways to “close the gap”.

Sound familiar?

Academia is all about identifying research gaps!1 It’s the our bread and butter of our literature reviews. Leverage this hard won skillset that you developed in the last 5+ years of your academic training.

Once you’ve figured how to improve your own processes, start to identify trends in your company or industry market and more importantly, call out the data gaps that you see. And verify that these gaps are real. This’ll likely require talking to many other teams because identifying gaps is about reading between the lines, not in reading any documentation as is. Having these connections from Phase 1 and developed trust in their specific expertise domains is critical.

For the record, it took me about 12 months to develop the expertise needed in my job to figure that what I didn’t know is also what everyone else didn’t know.

Phase 5: Learn how to do things in the right direction

So you found a real, important data gap. Whoa. Even calling this out can be high business impact. What’s more impactful and helpful to you is developing strategies to close that gap.

Unlike in academia, you don’t need to put in all the effort to close it by yourself. Also, in industry, the scale needed and access to the data needed is likely beyond what you can alone. Identify which teams (e.g., engineering, UXR, legal) are needed to access, analyze, and share out the data needed.

This is likely going to be a longterm process. But hey that means that your job is needed! Brainstorm and pitch your strategies for (1) how to do this (methods); (2) what resources will be needed to do this (e.g., financial plan); and most importantly, (3) what’s at stake for how important this project is (business impact).

I’ve only been talking about one big data gap as an example. But likely you’ll have discovered many gaps of various sizes and importance through your learnings in Phase 1-4. For example, process inconsistencies, new growing user groups, data quality improvement opportunities, etc. The point is that now that you have the expertise and professional team & cross-functional relationships needed, you can start to adapt your own workflows AND help develop structure to help other teams adapt their workflows to improve the prior system in the right direction.

I am highlighting “improve” and “right direction” because I strongly believe that productivity can merely mean producing more things. Those things can just be… things that maybe aren’t meaningful, interesting, or helpful to others. In the grand scheme of life, I personally don’t think that consumers need more things. We need things that’ll help us lead more meaningful, ethical, beautiful lives.

Ok, I’ll get off my soap box.

But I strongly recommend thinking about what productivity in the right direction means for you.

Phase 6: Make more connections

At this this point, we’re talking about serious, longterm change that you are strategically recommending for your team and potentially many other teams. It’s also a marked step up from being “helpful” to making recommendations with meaningful directions based on clear data insights. This is very different from the “learn how to do the bare minimum” advice from Phase 2.

To build the structures, processes, and plans needed to move the needle in the right direction, you’ll need help.

Again, it’s about making connections with people at work to learn how to level up: to develop collaborations with those who can build the tools that you may need, rally others to the directions you are recommending, convince others to adopt methods that you’ve been working on, strategically share out the insights that you’ve been collecting or directly address the knowledge gaps that you’ve identified, etc. (And again, does all of this sound a little familiar? It’s the same research paper & talk pipeline but carried out in a different way.)


Many thanks to my first manager and The Teammate who also came from academic backgrounds and all my other teammates and collaborators who have provided very excellent & patient feedback on my career in industry so far!


Note: This post is titled “The first 365 days of your first job in industry” but honestly, I expect that Phase 4, 5, and 6 will be on rinse-repeat for the rest of my career at my current company. And if I ever switch companies, I’ll probably start at Phase 1 again.


AI was not used to write, edit, or brainstorm this post. All mistakes and em dashes are my own.

  1. See section Literature gaps vs. Market data gaps in Academia and industry aren’t that different ↩