Kick-off week
I was asked by a colleague the other day for advice on how to run a kick-off day for a brand new team and what activities I typically do. I ended up splurging too much info in Slack. In this post I shall attempt to share my current go-to list of activities and some principles I’ve learned along the way in getting a bunch of strangers focused on delivering valuable stuff, remote-first & within a few days. Here goes…
Principles
It’s not my first rodeo to get new teams up and running. Via feedback over the years, I’ve got some general rules I typically follow:
- Do not try do all the following in a day or two
- Ideally space out sessions and have them no more than 1 hour - people need time to let info sink in, probably no more than x3 sessions in a day
- Do not skimp on team bonding/sharing people’s personalities - building trust with one another is important
- The ultimate goal of the week is having consensus on direction/boundaries - not on having the answers, discussion is good
- This is just an intro and a snapshot in time - the whole team should expect the landscape to change as we gain more expertise in the area we are working in
- Typically someone in the team knows the most and leads a lot of the sessions, it’s better when you have a few people that can contribute to get diverse opinions - also helps people not lose their voice
- Aim for sharing “just enough”… going too deep and specific in week 1 tends to not be the best use of time, remember - you probably have multiple months together - some sessions can definitely wait
- Don’t stress too much about taking tangents
- You’re probably going to repeat yourself on some key points many many many times.
Also be authentic. It’s a new team that probably haven’t worked together before/met and the methods chosen signal your view on the culture of the team. If you feel the urge to do something completely different I’d probably say don’t listen to me - pick sessions that you feel comfortable with.
Outcomes of the week
So with those principles in mind. I typically am super transparent to people what the outcomes of the week are. They are:
- Shared understanding on the purpose of the team
- Shared understanding on who our users are
- Know the context & landscape we work in
- Know more about each other
- Collectively agree on ways of working
Purpose of the team
The first couple of sessions on the first day typically centre on the following.
Typically as a product manager I’ve been thinking about what the team will do further in advance than those in attendance. So it’s time to share my reflections/current thoughts. This usually means:
- What I think the current vision of the team will be
- Key users we’ll deliver stuff for/with
- I try to share what amazing looks like to me, usually via some form of storyboard:
- Typically split by user
- Usually 6 panels
- Saying how their life will be better because we ace’d x or y problem/opportunity
- Scope of the team (ideally delineated vs. other teams)
- What we will not do
- Rabbit holes/ice box for things if we start thinking about too much right now it will make us all confused and lost. These things the team an unpick over weeks and months.
You can decide how these get delivered. As much as it’s not sexy, it typically ends up as some form of presentation with a smattering of facilitating people to offer their view/steer/input.
Note: I’m not a big icebreaker person but they definitely have a time and place. For this type of week, if I were to do one then something like draw your neighbour or draw yourself. Something short, fun/creative and anyone can do.
What we know & don’t know
Second topic and usually a couple of sessions. This is mainly about your primary users. Sharing back what you know about them and the context they live in, typically sourced from some form of user research or lived experience. Amazing if you have someone in the org that can drop in and share their perspective (e.g. if you are delivering for psychiatrists then bring in a psychiatrist or a user researcher who has spent a good chunk of time with user group is also good).
Touching on points you’d find in things like empathy maps are good enough.
You’ll need to spend far more time with users going forward so it’s ok for “just enough”. I typically have another ice box or place to stick down all the things we do not know about users. Referring back to existing research for extra reading is also useful for those who want to dig deeper.
Technical landscape
For this, as a Product Person, I’d only do it if I was confident or most likely… I had a colleague who could run this session themself. Usually the person would’ve been in the org long enough or worked in the same area as the new team. Otherwise they might not have the knowledge or confidence to share. Inevitably this will touch on things that will slow us down, are dependencies or are kinda broke. I’d encourage in this session to pinpoint who are good people to pair with moving forward.
This can be omitted from the week if people simply don’t know enough yet.
Expectations on the team & risks
This session is a chat about what people are expecting from us as a team. This could be akin to “business needs” on the work you’ll be doing. I tend to take it a bit broader, lots of takes on the internal landscape and how that will affect the team. Could be that the organisation wants to see more prototyping and A/B testing because of a new snr hire or lots of publicity in the area we’re working in so be very careful on how work is perceived to the public.
Typically by this point it also leads into a chance to speak about any potential pitfalls or risks. These can be numerous, deadlines on the team, budget, team shape issues, etc.
Stakeholders
People will have already skirted in and around this through prior discussions. Which is good - prime place to talk through it.
I have used the agile team onion many times and always good enough to map out who is important to know. Realistically lots of the team will do this session once then not revisit the team onion but it still has value in the early days on who to go to and contextualise who people are when they suddenly pop up asking questions. By this point I’d hope we know who are the people we’ll need to be partnering with but it’s something that is constantly in flux.
Sharing more about yourself
A new method for the last team I setup, opted for a verison of the user manual for me. I have only tried it once but it worked well. One reaosn for this I think this is because it is possible the key facilitator is sick of talking at this point & people are sick of listening to the same person. So it’s lovely to hear from others. Sit back and actually know your new team as real people.
At the start of your week it is good to give people a warning that this session requires some pre-thought. So they have a few days to decide what they want to share. I made a game of it by saying you can share back the user manual in the most creative way possible. So some people did a quiz, others presentation and I was hoping for some dancing or singing but not this time. Prizes were awarded for the one’s that were most fun.
Ways of working
You’ll be near the end of the week at this point. Ideally you want the team to have the foundations to start getting their hands dirty next week so some team decisions inevitably need to happen.
This is far more collective decision making so voting happens quite a bit. I tend to always try get agreement on:
- Ceremonies we’ll do as team
- Frequency they happen
- Any team rules we should implement (e.g. no meetings after 5pm, write weeknotes as a team)
- Team tools / services the team agrees to use (e.g. should we use Trello or Jira)
I tend to do a mix of team principles or it’s ok to… type team declarations to hold each other to account/foster a budding team culture.
Informal get together / team bonding
If you’ve managed to get to the end of the week and touched on the above you’ll probably be shattered. In truth, the team event/party has often been done the week after and I always schedule some back-up sessions early the next week to mop up anything missed. So perfectly acceptable to push back.
Obviously if you are remote then it can be tough finding some activities but the one I used last time was quite fun and inclusive - skribbl. It allows you to also add in words/phrases your team have amassed in the hours spent together (some form of inside joke). Once again, I’d stick something on the line… a small gift delivered to your new colleague to the winner.
Fin…
With all those done above. Team should be in a good-ish place to take its first steps to delivering amazing stuff. Feedback is always good so I suggest seeing what worked and did not for your future reference.
There is a real bonus to keeping some of these artefacts too, especially when new colleagues join. I tend to reuse them/reshape them when onboarding new team members - good to go over who you think your users are, team principles, stakeholder maps, etc. The artefacts I keep up to date and visible as the team grows and changes too.
I hope this helps someone, it’s an evolving list but most importantly be true to yourself and good luck!
Inspiration from others: