What to Do While You Are Blocked at a New Job

Two people start on the same day with the same skills, and by the end of the month they are perceived completely differently. The difference is rarely talent, and it is rarely how quickly they got their environment working.

It is what they did while they were stuck, which in your first fortnight is most of the time.

Waiting is not a task

In your first fortnight you will be blocked constantly. An access request in a queue. A licence not yet assigned. A repository you cannot see. Somebody who has the answer and is on holiday until next week (recent true story).

The temptation is to treat that as a legitimate stop. You raised the ticket, you are waiting, there is nothing to be done.

There is always something to be done, and the difference between the person who finds it and the person who does not is visible from a long way away.

Parallel queues

The habit worth building is to keep a parallel queue. When something blocks, you switch to it rather than stopping. Filling it is easy, because everything in this series belongs on it:

The reason I emphasise writing things down is that note-taking helps you remember things, even if they don't yet fully connect. I write this with a recent experience fresh in mind and honestly, there were plenty of things I was writing down that didn't make a lot of sense. I wrote them down anyway. Those notes gave me clues to work with, and as I learned more, I started recognising the same terms, ideas and connections. Before long, things that had initially seemed disconnected began to fit together.

The point is not to look busy. It is that all of this work is useful, it all compounds, and none of it needs anybody's permission.

There is a communication half to this too. Being blocked should be visible, in the ticket and at standup, as covered earlier. Quietly working around a blocker without telling anybody means it never gets fixed for the next person. Raise it, then get on with something else while it clears.

Throw yourself at the daunting thing

Early on, you might be offered something that is daunting. The system is still unfamiliar, the problem vague, and the deadline optimistic.

Take it, anyway. Here's why:

You dive in, not out of bravado. Because complex and unfamiliar is the normal condition of this job, not a sign that you are the wrong person, and the only way through it is to start badly and improve.

The instinct to wait until you understand it properly is the trap. You will not understand it properly by waiting. Understanding arrives through contact: reading it, running it, breaking it, asking about it. The first day on a daunting task is meant to feel unproductive. That is what the first day looks like.

But given time, these systems do make sense.

Every codebase that looks impenetrable was written by people solving problems in sequence, under constraints, with reasons. The reasons are often not good ones, but they are reasons, and once you know them the code stops looking arbitrary. That understanding arrives more reliably than you expect.

The curve is always steepest at the start. Not because the work is harder, but because everything is unfamiliar at once.

Anything you do daily, you master quickly. It gets easier quickly and then keeps getting easier. The build process you cannot follow today is something you will run without thinking by the spring. The deployment you find nerve wracking becomes routine in a month. Repetition does the work whether or not you study, which means the terrifying thing in week two is frequently mundane by week ten.

That is why I would tell somebody in their first week to be positive: not as encouragement, but as an accurate forecast. You are at the worst point of the curve and it does not stay here.

When to raise a concern

I recently found myself feeling overwhelmed on a new project. In hindsight, a lot of that came from still getting to grips with a huge amount of new information and trying to fill in the gaps in my understanding.

My instinct was to voice that concern. Raising risks early is what experienced people are supposed to do.

But I learned that how you raise them matters, especially when people do not know you yet.

Some of what I thought I was communicating as, "here is a risk we should be aware of," was heard more as, "I am not sure I can do this." A manager pulled me up on it, which is why I am mentioning it here.

One thing they specifically called out was that more junior members of the team were in the room.

That had not really occurred to me at the time. To me, I was thinking out loud among colleagues. But when you are the more senior person in the room, your uncertainty carries more weight than you might realise. What feels like a concern you are working through can sound to somebody more junior like, "the senior person thinks this is not going to work."

And part of being senior is recognising that people are calibrating on you. They are looking to you for confidence, judgement and direction, even when you are still getting to grips with the situation yourself.

I still think some of the concerns I raised were accurate. What I had not accounted for was how they sounded coming from me, in that room, to people who had not yet seen how I worked.

I learned that lesson the hard way.

So I am not saying you should keep quiet when something looks wrong. You should raise risks. But especially early on, try to pair the concern with a strong sense that you are already moving towards a solution.

Show that you are willing to dive in. Show that you are being proactive. Work tirelessly to connect with the people who can unblock you. Dig out information on Confluence. Focus on what folks say in meetings, and take notes.

I found it helpful to draw up a to-do list, with each step needed to unblock me, for example: "1. Reach out to the platform team about VPN access, 2. Download and install the corporate certificates, 3. Clarify requirement A with the tech lead."

Instead of making something sound impossible, dive in as best you can. Make an impact with your presence.

Certainly, explain the risks, what you are doing about it, and what might need to change if the risk becomes real. But get stuck in and communicate.

I know that can sound a little corporate-drone-ish, but in my years of corporate life, I've found that that is genuinely what people respond well to.

People want to hear that you can see the problem without being paralysed by it. Be bold, charismatic, brimming with energy.

Raise the concern as a plan

The reframe that fixes almost all of this is simple, and it changes nothing about the information you are conveying.

Instead of:

I am not sure this is going to work. It is a lot more complicated than it looks.

Say:

There are two risks here: the data migration and the integration with the older service. I would like to spend a day proving the migration first so we find out early if it is a problem. If it is, we have options. Can I take that approach?

Same concern. Same risks. But a very different signal. The first sounds like doubt about yourself. The second sounds like somebody who has already started managing the problem, which is what raising a risk is supposed to be.

Three components make it work:

  1. name the specific risk rather than a general feeling
  2. propose the next step, and
  3. say what you need.

The window where you can see what is missing

Now the specific thing I would most like you to do with all of this.

For roughly your first month, you can see what is missing from the documentation. You know which steps were not written down, which page was wrong, which acronym nobody explained, which setup instruction failed silently.

That window closes, permanently.

I can prove this to myself with my own notes. I have a setup document I wrote in my first fortnight at one job, and reading it back a year later, roughly half of it describes things that by then felt so obvious I would never have thought to write them down. Somebody joining that month found those the most useful half. In six weeks the knowledge will feel obvious, and you will not be able to remember what it was like not to have it. This is how expertise works, and it is why documentation is so often written by the people least able to see what a reader is missing.

For those few weeks you can do something nobody who has been there two years can.

Document your journey

I recently joined a new project as part of a team. We were all at various stages of onboarding.

A colleague took the initiative to create a page on the company's confluence, documenting the setup journey.

It included chronological steps, a glossary of terms, important links and trouble shooting steps. It was especially useful, as we were all struggling with configuring the proxy and downloading relevant certs. Collecting this sort of information in one place is not only worth days of someone else's time, it also reflects well on you.

Before long, the rest of the team were updating it too. He later created additional pages for other team specific rituals such as "testing", and more.

If the place you're at does not have a publicly editable Confluence, you can hopefully find a similar platform to document such as on Slack.