Starting your first job is tough: you have to juggle learning the ropes of professional life alongside skilling up as a new engineer. You're probably doing this concurrently to a whole host of other life changes: leaving home/college, moving across the country, etc. As such, you might believe the going gets easier each subsequent job switch. Sorry to disappoint: it doesn't–taking a new job mid-career comes with increased expectations.

You're no longer "entry level" and will be expected to arrive as a mostly competent and productive member of the team. The pressure is further increased by the fact that job changes often result in a title bump: how does one live up to the expectations of Senior Software Engineer when virtually all of your new colleagues will be outperforming you for the foreseeable future–even the ones without the shiny new title?

Worry not: you've got this. You do have something valuable to contribute. The fact you're here means something; software hiring and interview practices have not become Machiavellian torture tests for nothing. That doesn't mean you can just show up and start acting like you always know best; what matters most is that you stay humble. Getting the most out of this experience requires keeping an open mind to different ways of working. Over my own career, I've developed a basic 3-step process to ramp up quickly, learn a lot, and start making a big impact fast.

Phase 1: naturalize and observe

In the beginning, your strategy should be to listen and learn. Joining an established organization, your biggest hurdle will be navigating the existing structures and norms, and none of the short-hands and relationships that carried you in your old job will exist. The goal is to understand the unique culture of the team and what is (implicitly) expected of you as a newly minted member of that culture.

The company and your manager likely have some sort of onboarding planned for you; put all your energy into that and be present. During your onboarding you should take notes; write everything down...especially 1:1 advice, as well as anything you have to figure out and research on your own. Collect useful links and documentation you come across. This serves three purposes:

1. You can enhance the existing onboarding documentation, and guide future new hires as someone who has recently been through the experience.
2. Peers and managers will offer a lot of advice during this period, and much of it will never be repeated once you're considered a fully vested employee.
3. Much of the information you encounter will parse differently rereading it 3 months/6 months/12 months into the job.

Do your best to follow instructions and perform responsibilities as directed. When in doubt (or for lack of guidance), identify a role model and copy them. Formalizing your relationship with this role model as a mentor will further increase your access to tips and tricks for navigating the new environment, and bolster your work social network early, when it is sorely needed.

As an experienced hire, you may be inclined to show up and start agitating right away: you should already know how to do the job, and were hired for your knowledge and experiences right? If you keep it to yourself then what's the point!? Don't, stop, cease, wait...no! This way lies madness (and much animosity).

I'm not saying you should be meek and complicit. Rather, you would be well advised to prioritize listening so you can actually understand what others expect of you and avoid operating off prior assumptions. Moreover, in an ideal world, you would be joining a company you respect and want to learn as much as you can about their unique culture/secret sauce/system of work as you can. Some of the key cultural aspects and behavioral norms I look out for include:

• Communication norms: when does the team use chat, email, or a meeting? How polished are meeting presentations and agendas? When do discussions and decisions get recorded in writing? How long and formal are these documents? Does the group do any form of collective brainstorming, pair programming, etc?
• Decision making rules: how does the team make decisions? Who is involved? What approvals are sought and when? What decisions can you make solo and which should be formed via consensus? How are decisions recorded and shared?
• Jargon: what terms of art, nonce phrases, and aphorisms get used? What are the preferred phrases for key concepts (e.g. I have worked at places where saying "CI" would get blank stares, but "postpush testing" is crystal clear)? What terms are verboten or conjure up violent negative reactions?
• Transparency and socialization: how much or how little do people share about their personal lives and preferences? How tolerant is the group of "chit-chat" or "small talk?" When does socialization occur and between whom?
• Polish and failure: how complete and refined are solutions and ideas before they are shared or publicized? How and when are problems/blockers declared? How tolerant is the group of failure and taking bets...how often do others fail?

Fully engaging in your onboarding, and attempting to learn the traits of a model team member gives you a strong foundation for future success. As you start to influence the culture, make changes, and even come into conflict, you have a "safe haven" to return to when things aren't working out: a set of behaviors that you know will be accepted (and rewarded). Most importantly, this demonstrates a great deal of humility and respect, and will make you a more effective change agent: others will be more receptive to your ideas and criticisms believing they come from a place of understanding, rather than a blind attempt to be more like <previous employer X>.

Phase 2: compare and contrast

As you start to get more comfortable in your new job, you'll want to expand your impact and scope of practice to be more than just task completion–focusing on how to multiply the overall efficacy of your new team. This is hard...like, really hard, like the-whole-point-of-your-career hard.

At this point, it is still very hard to provide significant value-add. You're missing lots of history and context; systems of work are not simple things to understand and you probably only see one tiny corner of the whole enterprise; existing relationships, cliques, and rivalries may only be partially mapped out. Fear not and don't get ahead of yourself: you must walk before you can run...and in this case "walking" means thinking in metaphors.

The overarching goal at this point is to bring to bear all of your hard-won experience. The best way I have found to do this is to draw comparisons, identifying aspects that are similar and forming 1:1 maps from your new role, team, and company to previous encounters. Through this process interesting "diffs" will emerge that explain unique challenges (or advantages) for you to exploit. You will sometimes find the silver bullet lies in one of your past experiences, it just wasn't obvious how it applied until you constructed the metaphor. This applies just as much to interpersonal and leadership problems as it does to technical issues. Some examples from my life include:

• The Verve Asset Manager (VAM) I inherited at Verve stores data in a user-configurable schema that allows customers to specify arbitrary fields and relationships for all the items they want to track. This turned out to be very similar to the feature set and problem domain of the custom CMDB in use at <redacted employer>. The CMDB had run much longer, served a larger customer footprint, and had already surmounted many of the same technical hurdles (sharding, replication, asynchronous streaming, etc)...meaning VAM was able to avoid several pitfalls before they occurred.
• Working in IT at UW-Madison gave me a lot of experience serving an internal customer base. Both the Architecture group at Two Sigma, and the Engineering Productivity group at Google function very similarly: providing services (consulting, tools, support, etc) to a captive customer base. Besides the experience itself, there is a wealth of literature, talks, and best practices to call upon when doing IT service design, and I was able to apply all of it—principally shifting the nature of our customer engagements from one of governance and control, to one of education and enablement that let us exert greater influence over technical direction and team dynamics.

You never know when inspiration will strike and you see the hidden connection to something from your past. My last example raises an important source of inspiration: inter-disciplinary metaphors. If you have exposure to ideas outside of tech (or in parts of tech that are less frequently traveled by software engineers like IT, product, support, etc), you will find many "hard problems" are already partially solved. Turns out software engineering isn't the first field to attempt collective problem solving in a professional environment /s.

One of my favorite ah-ha! moments of late was coming across Vargo and Lusch's "Evolving to a New Dominant Logic for Marketing." In this paper, the author's claim that the fundamental economic shift from exchanging value in the form of tangible goods and products, to exchanging value via intangible resources like knowledge, relationships, and services, leads to a similarly fundamental rewiring in the theory and execution of marketing. One aspect of this shift is how "goods are transmitters of operant resources (embedded knowledge); they are intermediate 'products' that are used by [customers] as appliances in the value-creation process." How does any of this apply to my day job?

I work in Engineering Productivity at Google, wherein I aim to create the best place to be a developer: where folks can come and focus on building great products and experiences, and the tools and processes to do so fade into the background. The problem? There is no silver bullet; I can't just build the most-magical-CI-system-you've-ever-seen and have that make everything better. Some improvements can only come when the way the software is designed and implemented changes. What do you do when it's not your product or team that needs influencing? The key mindset shift that is required is to stop thinking in terms of delivering a tangible product (a piece of software like a CI/CD platform), and more in terms of delivering a service (software engineering and methodology consulting). Through that lens, the tools I build become the "transmitters" of the actual "operant resources:" my particular philosophy and approach to software. I'm not selling a tool, I'm selling a lifestyle...ready-made tools propagate that lifestyle in a very attractive package.

"Evolving to a New Dominant Logic for Marketing" describes this shift in detail, and if you continue to extend the metaphor, there are even more novel and applicable takeaways for anyone in roles such as mine. Exposing your new team to foreign ideas and concepts that they might not encounter otherwise is one simple way to start providing extra "value add" even before you've fully mastered the new gig and have your "sea legs" underneath you.

Phase 3: invent and expand

Thinking in metaphors can take you very far, and as you get further soaked in context, you will start to make novel leaps and new ideas that are all your own. Bear in mind there are no bonus points for originality, but it definitely feels good when you're able to solve a problem with your own creativity.

I have no secret wisdom to share: you will know when you're here because your brain will form new connections and pick up on provocative ideas almost entirely unbidden...the subconscious mind at work.

At this phase you should take care to avoid fixating on "innovation for innovation's sake." The urge to change things and pursue new projects will intensify as the volume of your insights increases, but you should remain anchored in solving real problems.

• Continually assess alignment with the team, product, and business. Solving imagined problems or working towards a divergent end goal delivers no value.
• Use leverage as your yardstick for measuring effectiveness, rather than just output. Time is your most limited resources as unlike other resources, time cannot be stored, extended, or replaced.
• Think of (almost) everything as an experiment and ask yourself what you should do to maximize the amount of new information you can gain, even if that experiment should "fail."

Enduring beyond the first year

I have used this mental model while starting 4 new jobs over the last 6 years, and it has served me well. While job hopping has become quite typical for software engineers–increasing the need for guidance such as this–it is still the case that you need to find a job and stick with it for some number of years to build real mastery. 5 years of "1 year of experience" is very different from "5 years of experience." I have done 3 such extended stays in my career (6 years, 4 years, and 2 years in duration).

In year 1, much of your work and priorities are predetermined. The manager that hired you had to justify your headcount somehow, and that typically requires 1+ year worth of high-value projects on the backlog that are ready to go. You spend your first year nailing those projects, and relying on your team/boss's social networks to get things done...then year 2 rolls around the real challenge begins.

In year 2+, you will be expected to continue delivering value, but there may not be a shovel-ready project in the wings. How you source, identify, and select the next big thing you work on is critical...it doesn't matter if you do this as an individual or as a team. That is why the tips I have shared here are singularly focused on bringing your innate creativity to bear.

It's can be nerve-wracking to start over mid-career...the challenge of getting back to your former level of productivity and effectiveness will be different every time (maybe that's partly why more and more of us are drawn to job hopping?). Good luck, and enjoy your new job 😊