For the first decade of my career I carried around a magnetic tape containing all of the tools I had built for myself starting in graduate school. My first task at a new employer was reading this tape & getting my shells & my Emacs set up just right.

What a waste of time. It helped that eventually I came to an employer without access to a tape reader. But also, those tools I laboriously portaged from place to place:

• Didn’t help me that much.

• Distracted me from learning my new environment.

Refugees

You’re a senior engineer. You’ve recently downshifted from a FAANG to a smaller (but still successful) tech company. Your new employer struggles with a problem that was totally solved at your old employer. What do you do next?

Start with what not to do—don’t say, “Well that doesn’t need to be a problem. I’ll just reimplement what we did at FAANG.” Why doesn’t that work? What can you do instead?

Context

Every solution was created with loads of context. There’s technical context like your tech stack, your patterns of demand, your tooling. There’s business context like the cost of failure, the cost of delay, the required profit margins. There’s social context—the people who know how to use various tools & how those people interact.

All this context has unpredictable consequences. Small shifts in context can have major influence on what constitutes an effective solution. And you’re new. You probably didn’t fully understand the old context even though you’d adapted to it. You certainly don’t understand the history & nuances of your new context. Copy a solution wholesale & you risk big problems at the very moment your employment is most vulnerable.

Succession

Instead of saying, “How can I replicate <my favorite tool>?” ask yourself what is the tiniest slice of that tool you can implement that will bring actual value to actual people at your new employer. Even if the tiniest slice is a spreadsheet macro, get on that loop of creating value leading to reputation leading to autonomy leading to creating value.

“Yeah but…” I hear the objections coming, “I know, from experience, I really truly know that we are going to need A, B, C, D, E, F, & G. May as well work on them all at once.”

• Working on them all at once won’t buy you that much. You’ve been through this before. You aren’t going to make big succession mistakes even if you implement a slice at a time.

• You don’t have the social capital you had at your previous employer. This increases the value to you of early & frequent realization of value for the organization.

• Who’s to say you won’t discover something new along the way, something in the aforementioned context that changes the problem & the solution? If you end up implementing A, B, E, J, P, & Q, that’s better for everyone.

Principles

Re-addressing a problem is a marvelous opportunity to glean first principles. What was it about my old context that made that tool work? Not technically, but socially, businessly [ed: sorry for the new word]? What are the underlying principles?

How is my new situation similar to or different from the old situation? Can I address the equivalent need in a completely different way?

Your experience & fresh perspective are a huge counterweight to your naïveté & ignorance. Use them, yes, but a little at a time. (There come moments for revolutionary change, but those are the exceptions.)