Moving companies as a Staff+ engineer

How to keep calm during a big move

It's been a little over two years since I moved from Atlassian (as a lead principal engineer/architect) to a staff+ engineer at Stripe. I spent a long time at Atlassian (eight and a half years) and grew my SaaS career there. I had friends there who I worked with for a long time, and lots of people knew me (and hopefully had high opinions). Making the move was scary, and it has taken this long to finally be comfortable reflecting on a successful transition. Here are some lessons that I learnt.

Trust that your skills and experience are relevant

Earlier in my career, when I changed companies (or switched clients back in my consulting days), I had confidence in my technical skills and ability to quickly pick up new technologies or domain knowledge. As I became more senior in Atlassian, my role evolved into being a connective tissue between teams and engineers I knew well and identifying problems (and solutions) based on my understanding of the systems I had helped build. I wasn't in the code anymore; I was in the nebulous world of engineering leadership. When I moved to Stripe, I no longer had the people, systems, or domain knowledge I previously had. People talked and operated differently, and the technical and business concepts sounded foreign. How do I quickly make impact to justify my pay packet?

Take a breath and let your analytical skills take over. Remember that you know how to learn and do what you usually do (read, talk to people, search for documents, ask silly questions on Slack channels, trace through user journeys in code). Relate the new domain to your past personal and work experiences. Bank account details are like credentials (especially in the US), so expect similar operations. Settlement of funds is effectively batching of data transmission. Tools and processes should be similar across companies, too, but at different maturity levels, and it is a matter of finding them (and they may be manual).

Did you find something missing from mapping the new domain to your past experiences? That may be a gap worth exploring and where you can help bring improvements. This is the start of your impact.

Take your time

Some cricketers are nervous starters in their innings; they're jittery and keen to score early to get off the mark (sorry if you're not a cricket fan; I'm sure there are analogies in most other sports). I'm like that, too.

I constantly reminded myself that it wasn't a race but about finding your place and making a meaningful contribution. Many people, including myself, were told that it takes about a year to truly feel comfortable in a new role. I can attest to the truth in that advice. Looking back, I can pinpoint the exact day when I finally felt like I knew what I was doing, and it was spot on one year! So, take your time, and trust that you'll get there.

Sharing your expertise when you are trusted

When I first started at Stripe, many people told me that I could bring fresh eyes to problems and suggest improvements even outside my direct area of focus. Your expertise is valuable, and sharing it can make a real difference. I should do this, especially before I become too used to how things work here. I remember giving the same advice to new starters at Atlassian.

I now realise this advice is only partially true. It is well-meaning and valid for those who are receptive to feedback, but unfortunately, not everyone is:

• People don't know you, so why should they believe you? You have no shared experiences.

• Again, people don't know if your suggestions will work in this new environment because you don't have shared experiences of them working.

• Changes need to overcome inertia, either from people (egos and project goals), processes (it's how we do things here), or technology (it's been built this way). As a senior engineer, it's your job to push through, but that's hard as a new starter, especially outside your realm of responsibility. So, do you spend time pushing or focusing on your day job?

To be clear, I'm not one for saying, 'We used to do Z at this company, so we should do it here.'; those changes don't work or last because of nuances in the new environment (or, in the worst case, people leave). Instead, I would like to understand why Z worked, and if similar conditions exist in a new environment, I propose using first-principles reasoning. i.e., we have problem X, my diagnosis is Y, and Z is a possible solution based on past evidence.

Instead, I would now suggest:

• Make your suggestions early on, especially small ones. It's great if you can push them through, but otherwise, treat it like warning your kids; it's okay if it's not a life-threatening scenario and they ignore your warnings.

• Keep a log of improvements and find quiet time to reflect on how things work in your organisation and the company (e.g., I like the shoulder periods just before and after vacation). Reflection should naturally include seeing what happens outside of the company bubble, including what you have experienced in the past.

• As you learn to speak in new company terminology and problems and find others who can help you push through changes, start making more significant suggestions. Now armed with local lingo, getting traction will be much easier. I am still suggesting improvements based on past experiences two years in.

Recalibrating expectations

After working at a company for a while, you learn the shared expectations of different roles and levels. Unfortunately, expectations differ between companies (and perhaps organisations within companies). Product Managers may be more or less technical. Staff engineers vs senior engineers are expected to do X here. The fact that titles are inconsistent across the industry and levels may be hidden based on HR policies makes it more difficult.

Be prepared to recalibrate expectations and be explicit with people. Are you doing X, or am I? Confirm expectations on a junior engineer by working with their manager. Ask your peers about how they work. I still internally translate levels back to what I was used to (like how I still need to think in metric units while living in the US), and I tweak my mental model based on explicit feedback on expectations.

Remember why you moved

In the early days, when I was uncertain that I fit in, I regularly asked myself, 'Did I make a mistake?' Luckily, I had left Atlassian on good terms and wasn't running away from my last job; maybe I could go back.

It's easy to get lost in the day-to-day challenges, but it's important to remember why you made the move. Keep your goals in mind; if you haven't achieved them yet, keep pushing. I wanted to try something different, to experience being in a nascent product org (rather than a platform), and to work with others from various tech backgrounds. Had I achieved my goals? If not, then I should stick around and make it happen.