Until recently I was working in a function where I moved around different projects every 3–6 months, often working with new people and new teams each time. Over the course of half a dozen moves I built up a list of questions that helped me gather useful contextual information quickly. Now I’m on a longer term project I refer to these questions less often, but I’m saving them here as I know future me will find them useful.
About the team
Some simple questions to ascertain who’s who in the team. I’ve found these especially important when working remotely as I’m unlikely to ‘meet’ everyone in the first few days but I might need to call on them for assistance, so I need to know their names and what they are broadly responsible for.
Who is in the team?
What are their roles?
Who will I report into? How much contact time will I get with them?
Who is around to support when I have ‘newbie’ questions?
Who is responsible for making decisions?
Ways of working
These questions elicit variable responses. Some teams are very aware of their WoW and discuss them often; other teams are so used to their patterns they don’t even notice them. These questions can also be helpful to understand how the things the team says (e.g. ‘we’re agile’) mean to them in practice.
What’s the cadence of the work?
How often do you check in as a team?
Do you work in sprints or kanban or something else?
Are there any regular milestones or meetings?
How much time can I expect to get with users?
How much time can I expect to get with subject matter experts?
Mission
I’ll always receive an introduction/brief before joining a team, but it may be quite sparse or produced in a hurry, as the teams I work with are often under pressure. As someone who is motivated by doing a good job and knowing the value of my work, these ‘why’ questions are really important.
What are the key priorities for the team? (Including but not limited to the bit I’ll be working on)
How will we know if we’ve done a good job?
What is the problem we’re trying to solve?
If we get this right, who benefits and in what ways?
Potential pitfalls & what’s gone before
It’s increasingly rare that I join an entirely ‘greenfield’ project, where there’s never been an attempt to boost efficiency / ‘modernise’ / adopt digital tools or practices / ‘transform’. It’s important to acknowledge what came before to prevent immediately losing trust of the team or users by suggesting something they already rejected or didn’t work. Don’t get me wrong, I’m not put off entirely by ‘we tried this before, it’ll never work here’ — I think sometimes a change can be derailed by timing or factors outside the team’s control — but knowing this context will shape how I approach my actions and recommendations.
What have you already tried to resolve this problem? How did that go?
What documents have you already written that I can read?
What pressures are the team under?
Are there any key dates / deadlines that have already been agreed?
Let’s go!
I learn best by doing. I find it demotivating to join a team and immediately be handed a dossier of documents and/or an e-learning course and be told to come back in a week when I’ve digested it all. I like to find a low-stakes/low-risk task to get going, and through doing I get to know the team, their approach, their culture etc.
Where is a sensible place for me to start?
What meetings can I observe this week?
(If they have a visible work board that I can read) Can I help with x? (Where x is a task that’s well-defined, small scale, relatively familiar)
Do you have time for a virtual coffee? It’d be great to hear a little more about what you do.
