As consultants we find ourselves getting started on new projects all the time. And it’s important to get the first week right. Not only do you want to make a good impression, starting off on bad information, bad assumptions, or with bad blood will make it very difficult to be successful on a project. In our first week, we’ll focus on trying to answer 3 questions:

  1. What is the landscape?
  2. Who are these people?
  3. Why am I here?

As a rule of thumb, assume that all your assumptions are wrong, just like all information given during intake interviews will usually turn out to be wrong or incomplete. So let’s get started.

What is the landscape?

As a consultant you’ll be brought in because there are problems to solve. Existing things are broken or lacking, or new things need to be built. Either way, it’s important to get a good understanding of the technical landscape and the existing documentation.

Reverse Documenting

A good thing to do during your first week is to document an overview of your understanding of the landscape, including any questions you have or potential issues you see. Go through any existing documentation, ask questions, and poke around the landscape. Not only will an overview like that help you make sense of all the information thrown at you; you can use it to validate whether or not your understanding is correct. To get that feedback loop, schedule a meeting with your new team to present your findings. Let them explain what you got wrong, fill in the blanks, and get their opinion on any issues you have identified.

Collaborate on real tasks

Sometimes the best way to get to know a system is to fix it. Team up with one of your new team mates and work on something. This allows you to learn about systems ‘from the trenches’ but also get a good understanding of the team’s approach, their processes, tools, and overall maturity. Are the tasks clearly defined, or are you looking at mostly empty JIRA tickets? Do you end up writing code that is rolled out from a pipeline? Or are you poking around in root shells? How good is existing documentation? Are there obvious ‘heroes’ on the team that everyone runs to for help?

Ask (basic) questions

Since you’re new in the team, it’s your duty to ask questions. Ask as many questions as you can. Ask ‘why’ for anything that isn’t immediately obvious. Pay attention to implicit knowledge, or silent knowledge gaps. Even in the most friendly teams there will be someone who is afraid to ask a certain question, because they’ve already been around too long.