Team Management in the Context of Change: Lessons Learned

Team management is one of the most challenging, rewarding and fun aspects of my job as a Scrum Master — I’ve always enjoyed looking for new ways to bring people together. But, what happens when you need to build 4, 5 teams at once? And then rebuild them again?

Zenitech faced this exact situation when our customer account went through major growth and transformation, from mid-2018 up to the end of 2019. We went from about 12 people to 27 in less than a year, and then added 5 more. We needed to move fast, so we failed fast and learned a lot in the process.

Therefore, I decided to share the lessons I have learned in a series of blog posts. The topics may not be brand new, and a lot of people have talked about these things before, even so, the entire experience and the way we approached the challenges is personal. Hopefully, other people going through something similar can find some answers in here, or maybe this can give the dose of ‘you’re not alone in this’ reassurance we all need once in a while.

Lesson 1: On-boarding

We needed to hire a lot of people fast, and we wanted to ensure they would feel welcome, accepted and useful from day 1. Given that, and the complex nature of the customer infrastructure, we needed to come up with a process — this lesson is about how we got there.

Their first day comes way faster than you would ever expect.

HR informs you about a newcomer as soon as they sign the contract and quite often it is weeks in advance from the actual starting date. That is nice! Plenty of time to get ready, right?

What happens in reality (at least in our case), is that you make a note of it, maybe even mark it in your calendar and then take care of ‘more urgent’ things. It is in our nature: we do tend to prioritise the urgent over the important.

And then comes a day when HR comes and asks where they’re going to sit so they can set up their desk for the next day, and you go ‘DARN, ALREADY?!?’.

The first day at a new job is something people remember and something that can have a lasting impact, so what did we do to make sure the newcomers felt welcomed and involved from day 1?

Have a workshop — make a list

After failing to meet our standard of welcoming a newcomer a few times, we sat down in a meeting with other managers in the account and started writing down things we want our newcomer to learn/know. You might want to have a tech lead/a dev/a QA representative depending on the context.

Turns out the list is quite extensive, so we grouped the topics, decided who should talk about each of the items on the list, and put all of that into our and the newcomer’s calendar as a series of workshops.

This resulted in a very intense first week for our newcomers, but they did not feel unwelcome!

Distribute the effort

There are a lot of things for a newcomer to learn — processes, domain knowledge, the context of their ongoing project, plans, — you name it. It is quite a lot to cover for one person, so we worked out a system where every part is introduced by a different person. For example (do this in an order that makes sense for you):

• Their scrum master gives a general ‘welcome’ and introduction into who we are, who is our client, and what is the onboarding plan for the newcomer.
• A senior developer gives a general overview of the client infrastructure and the types of projects/products they have.
• Then you can get a representative from each of the scrum teams to present the projects they are working on.
• You get them to meet the team. What we do right now is an activity called ‘coffee with the team’. It is an informal conversation, sometimes accompanied with food, where the team members simply introduce themselves to the newcomer and vice versa. It can be a bit awkward at times, but it is a nice gesture and it can be a great kick-off to find things in common and form bonds.
• Finally, you get them their first tasks and ask for someone to guide them through.

I am a huge fan of this approach, as it gives the newcomer not only the information they need, but also a legitimate reason to talk to their new co-workers and get to know them.

And if you’re up for one more step further…

At first, we asked people to take part in the onboarding process of their peers as if it was a favour, and then, once we got more mature and the hiring process was still ongoing, it became a natural part of our lives. We would just lookup free spots in people’s calendars and explain what we want in the meeting description, as most of the people have done it before anyway.

The newest thing we have applied and which I have enjoyed the most, not only because it would imply less work from our side, was to give the newcomer a sense of ownership and control. We would hand in a list of topics in a specific order, with names next to them and specify that it will be their task for the week to go through the list with the people assigned (e.g. release management with Billy, coding standards with Jim, etc.)

This way they have to approach people and arrange the knowledge sharing sessions themselves, at their own pace and convenience.

It depends though

Everyone is different, and I believe it is our job as Scrum Masters to find the best way to get our colleagues engaged. Some appreciate more freedom; some require support at first due to lack of experience or because of a shy personality. Once you have a basic process/system in place — you spend less time worrying about WHAT to do, and you can focus on HOW you’re doing it.