It can be daunting entering into a new team, especially if they're a high output, fast-paced, well- oiled machine.
I will take you through some of my top tips for integrating smoothly, getting up to speed quickly and becoming a valued member.
Here are my top tips:
- Sit in on every meeting with the team to begin with, no matter what the subject
- Read the product backlog
- Have a 1:1 with each person in the team
- Update the onboarding documentation
- Pair program with each team member (dev focused)
- Refactor something/everything (dev focused)
- Draw a relevant diagram with the team
Sit in on every meeting with the team to begin with - no matter what the subject
So my first top tip is to sit in on all the meetings.
Meetings are a great way to get introduced to people.
They're a great place to listen to how people communicate in a team.
And when I say, "no matter what the subject", generally speaking, cross-functional teams will have meetings about all matter of things.
Frontends may have a planning meeting. DevOps have separte sessions - and maybe the backend people will be talking about something entirely separate.
If you sit in on all of these then you get a great overall picture.
Essentially, you'll be able to identify the people who are big personalities, and people who are dotted across the personality spectrum.
Finally the big benefit to this is you get to hear about all the things that are going on with your team. Find out about peoples' trials and tribulations (solve those and this can quite often lead to quick early wins for you and them).
You will hear some of the politics, understand some of the direction.
Afterwards you can then start to assess what on earth is going on.
Read the product backlog
This is what you'll be building, so become familiar with this.
Look at the kind of tasks being done - how they're structured, how they're moved around or prioritised.
Check out the tags on these tasks, this gives you a great indication as to how they divvy up the work. There maybe backend tasks, frontend tasks, DevOps tasks, POCs, Spikes, and War Games.
If you can't understand what a task is about, or how to carry it out, then maybe they have something wrong with their process?
This is great feedback for the team.
Maybe their acceptance criteria is confusing or doesn't exist.
Maybe there are no descriptions on any of the stories.
This kind of stuff can really help speed up a team so you'll become immediately valuable by providing that feedback.
Have a 1:1 with each person in the team
Use this as a chance to have a friendly chat, ask about work things, what they're good at, what they enjoy doing, what they don't enjoy so much.
Ask them if there is anything in particular you should know about or know about them.
Some people may come out and say, "I don't like being disturbed in the mornings", and others may like to offer help at any time.
This can really help you get to know people quicker.
You can do this over a coffee, or water-cooler convo... in the soft area on sofas - whatever your space has to offer.
Update the on-boarding documentation
The on-boarding process always changes, so every new member should update it.
The people to talk to for particular problems may have changed.
The laptops might all be different now.
The coffee shop round the corner might have gone... the list goes on.
Update the on-boarding pack with the name of the next new member, and be their buddy!
This is about to get development specific, but definitely carry on reading if you're a manager/scrum master/tech lead etc. - there are lots of great tips!
Pair program with each team member
If you're in the development world, theres no better way to acquainted with a system than to experience the work patterns of the team members.
You can see all the shortcuts they use (not just keyboard, but bash scripts to do repeatable tasks), and you can see the files they're regularly changing.
Best of all, you can see how they debug/test/deploy the code, which is invaluable to making your first contribution to the team backlog.
If you think some part of the system can be done in a better way - start refactoring and going crazy with it.
Because you'll start to pick up quite quickly how the system all ties together (patterns, practices, architectures, styles, preferences).
If you're ever working on an existing piece of code, to understand it as quickly as possible, I find it best to refactor it.
Now this bit is important! You're not necessarily going to commit this code. In the first instance, this is just to benefit you, so, you can understand whats going on. Once you do, you revert what you've done and carry out the task following the current "pattern".
If you genuinely think the piece of code can be improved by a refactor discuss it with the team!
If they agree with you, then sure, go ahead and refactor. Housekeeping is always welcome in code bases and should be done all the time (in small amounts - no one likes a 5-page PR which is jam-packed with refactorings).
Draw a relevant diagram with the team
Once you've settled in - maybe after the first week - aim to draw a picture of what is going on. In dev teams, draw an architectural diagram of the app or infrastructure (or both!).
If you're in the business you can draw the roadmap or business architecture.
Everyone loves a pretty picture, but I always always get to a whiteboard to start verbalising and ironing out the thoughts in my head - or to teach people something.
Whiteboards are the best - and everyone has one - so no excuses!
What you can do for new members!
Hey, this isn't all on the new guys!
Every single person plays a core part in the team.
Be open to all of the above and make it work!
Nothing is better than joining a new team where the current team members go out of their way to talk to you.
To help you set up your environment. To take you to lunch, play table tennis/pool with you (whatever your fancy office has these days).
To buy you a coffee/hot chocolate/soft drink.
Try to understand the personality of the person as quickly as possible. Some people may not like being put on the spot - so it's best not to get them to stand up and say something about themselves in the next company meeting.
Hello, from Slate
At Slate, even though we've got people working everywhere, we all make an effort to do this.
I wholeheartedly believe that this works.
When you join Slate and get added to Slack - there will definitely be a message there from everyone saying, "Hello, and welcome to Slate!"
Get in touch if you are interested in joining our team.