I just switched jobs. After five years at the same place, where I was the founding engineer, I packed up and walked into a smaller, much earlier-stage company.

When I joined that first one there were only a few people, all of them founders and chiefs, and I was the first actual hire. That made me the first engineer on the ground, with no team and a lot of decisions waiting to be made. I watched it grow, in real time, into something genuinely incredible, from those few people into a real org with teams and process and a roadmap longer than any one person could hold in their head.

The part of the work I missed the most, though, was the scrappy early stage. Building the thing for the first time before there is a playbook, when you make the calls that everyone after you ends up living inside. That is the part I enjoy and the part that stretches me, so going back to it was a step toward the work I want rather than a step away from anything.

The decision still was not easy. I was leaving people I loved working with and something that had finally become stable. But once it was made, the hard part was the thing nobody really talks about, which is the transition itself.

A job switch is one of the few moments where you hold two enormous amounts of context at once, the old place and the new one, and the gap between them is where things quietly fall through the cracks. The thread you spent five years building can snap in a week if you are not careful with it. Here is how I keep that from happening.

1. One place to capture everything

Before I touch a line of new code, I set up one place to capture everything. For me that is a command center in Notion, the same setup I use to keep my own apps from sliding into chaos, but the tool does not matter. What matters is that there is one inbox for the firehose that is about to hit you, because the first two weeks are a flood of names, acronyms, service names, and the weird thing about staging that everyone just knows. A typical entry looks like this:

- who owns the payments service? (ask in standup)
- "the monolith" = the legacy rails app, not the new one
- staging db resets nightly, do not trust old data
- why are there two auth flows? old vs new?

Half questions, half facts, and when I get an answer it goes right next to the question. Three weeks in, that document is the most valuable thing I own, because it is the map of everything I did not know on day one and now do.

2. Leave the old role clean

The other end of the thread is the part people skip when they are mentally already gone. After five years, an enormous amount of context lived only in my head: the reasons behind decisions that looked strange from the outside, the service that has to deploy in a specific order, the history of why we never did the obvious thing in some corner of the code.

So I spent real effort writing it down for the people staying behind. Not a polished wiki, just honest notes on the things only I knew.

The same act forces you to capture what you actually learned over those years, the lessons you carry into the new place. Leaving clean is how you make sure the best of the old context comes with you instead of evaporating.

3. Map the new codebase before you change it

The instinct, especially when you want to prove yourself, is to start changing things, and it is worth holding off for a while. Your first job is not to write code, it is to build an accurate mental model of the system.

The mistake I see people make is trying to read the whole codebase top to bottom, which does not scale and mostly covers things you will never touch. What works far better is to trace one real thing end to end. Pick a single feature a user actually triggers and follow it all the way through, from the request to the route to the service to the database and back.

Do that two or three times and you have a skeleton to hang everything else on. You will not understand the whole system yet, but you will understand its shape, and that is enough to start.

4. Ship something small early

As soon as I have that rough map, I ship something small, and the smaller the better: a bug fix, a copy change, a bit of cleanup nobody would think twice about. The change barely matters.

What I am there to learn is the pipeline, the invisible machinery every company has around getting code from your editor into production and almost never writes down. How do you run it locally? How do tests run, and which ones do people trust? What does a pull request look like, who reviews it, how does it deploy?

A tiny change forces you through all of that while the stakes are low, and it gets your name on the board early, so you stop being purely the new person who only asks questions.

5. Learn the roadmap and the why

Code is only half the picture. The other half is direction, and it is where strong engineers stay junior too long in a new role, learning the system but never why the company is building what it is building.

So I make a real effort to learn the roadmap and the reasoning behind it: what the priorities are, what is load-bearing versus what is in flux, who decides and what they are optimizing for. Most of that lives in conversations, not documents, so I go have them.

And as the new person you have a short window where naive questions are not just allowed, they are valuable, because fresh eyes catch the things everyone else stopped seeing. Ask them out loud, early, before you become one of the people who stopped noticing.

What I'd tell someone switching

Do not let anyone make you feel like going to a smaller, earlier-stage place is a step backward. The early stage is a skill, and it gets rusty if you spend too long inside a mature org where the hard early decisions were all made before you arrived. Going back to it on purpose keeps that muscle strong.

And you do not need to know everything at once. The thing that carries you through a switch is not your memory, which fails, but the organized context you hold onto, the one place where every question and landmine and decision lives. Get that right and a job switch stops being a scary leap into the unknown. It becomes the next stretch of the same long thread, picked up somewhere new.