Everything I write here is about getting in. The cert, the project, the CV, the offer.
Nobody warned me that the offer is where the difficult part starts.
My first weeks at AWS I was learning a new job, a new cloud, and three certifications at the same time. I had spent so long preparing to get hired that I had not prepared to be new. Every meeting had acronyms I did not know. Every customer question had a right answer that someone else in the room already had.
The imposter feeling career changers describe before the offer? It is louder after it. Nobody tells you that because the people writing career advice are mostly selling the part before the offer.
I have now watched a lot of mentees go through the same wall. The one who went from a Band 2 support role to a Band 7 data engineer had the hardest ninety days of his life after the job he had spent a year chasing. He got through it because he had a plan for being new. Most people do not.
The first 90 days decide the next three years
Here is what I have noticed. Your reputation in a new tech job is set in the first quarter and it barely moves after that. Not by how much you know on day one. Nobody expects much. It is set by whether you are visibly learning, visibly shipping, and visibly easy to work with, in that order.
So the plan for being new is not "know everything." It is three things, in three phases.
The plan
Days 1 to 30: ask the obvious questions early. There is a window where "I do not know what that means" is charming. It closes around week five. Use it. Keep a running document of every acronym, system and person you meet. By day 30 you should be able to draw your team's architecture on a whiteboard, badly.
Days 31 to 60: ship one small thing end to end. A fix, a doc, a script, a dashboard. Tiny is fine. What matters is that your name is on something that exists and somebody uses. This is the moment your colleagues stop thinking of you as "the new person" and start thinking of you as someone who finishes.
Days 61 to 90: own one thing. Volunteer for the small, unglamorous problem nobody has time for. Become the person who knows it. Every senior engineer I respect started as the person who owned one boring thing properly.
Underneath all three, keep a wins journal. One line a week, every Friday: what you did and what you learnt. In month three you will have your first performance conversation and you will have forgotten 90% of it. The journal is the only reason I could say anything useful in mine.
Today's sponsor is TigerData. If the team you join keeps a separate database just for analytics, TimescaleDB is their way of doing that inside Postgres instead, which is exactly the kind of thing worth adding to your running document in the first 30 days.
Most teams add a second database for analytics. Then manage sync, lag, and drift forever. TimescaleDB extends Postgres instead. Hypertables, 95% compression, aggregates. No pipeline.
💬 If you are in a new role right now, which phase are you in? If you are still job hunting, what worries you most about the first month?
Reply with DAY1 and one sentence. I will tell you the one thing I would do this week in your position. I read every reply.
Know someone starting a new tech job this autumn? Share your referral link. 1 friend subscribes, you get a free LinkedIn Profile Optimisation Checklist.
{{rp_refer_url}}
Shola
P.S. If you want the three phases on one page, with a 12-week wins journal to bring to your first review, here is the First 90 Days Plan (1 page PDF), direct link, no signup. October's editions are already planned. Same time next week.