How we restructured and rebuilt our teams in a remote world

CORE is a function within Redgate’s engineering team of around 45 people. We’re a mixture of development and operational teams whose role is to manage the critical infrastructure to keep Redgate functioning. CORE’s structure and the way the CORE teams work changed as we moved into 2021. Since then, we have started a reteaming process and the restructure is well on its way.

This is the first time CORE has tried an exercise like this (and doing it while working remotely has been another first!), and the CORE teams have been static in their structure for many years. The aim of the restructure is to change from a functional to a cross-functional structure, to reduce communication barriers and to create experts in various business domains.

Remote working added an interesting challenge to the reteaming process; ordinarily we would have occupied a few meeting rooms and scribbled on post-its and whiteboards as we progressed our ideas. We could not do that in Q1 2021 for obvious reasons, so Mural, Zoom and breakout rooms became our allies in supporting the reteaming activities.

What happened in the first few weeks?

To maximise the value of CORE’s reteaming activities, we began with a couple of working assumptions:

• People in the new teams did not know each other that well, or they knew some people well but not everyone, because they may never have worked together closely despite being part of the same function.
• We would purposely focus on people getting to know one another and sharing how they like to work — this would take time, but it would also help massively with team building.

So, taking on board these assumptions, over the first week we focused on breaking the ice and helping the teams to get to know each other. An icebreaker of two truths and one lie was a fun way of learning some random things about everyone’s new team members, and some of the truths were quite a revelation! We ran these sessions as a function rather than asking individual teams to run their own activities, to ensure that everyone was involved in similar sessions and we were all moving along together.

Another technique we used was the Johari window exercise. This is an interesting activity as it asks people to pick a few words (from a pre-selected list) to describe themselves and then asks others in their team to pick a few words to describe that person. The aim of the session was to highlight how people perceive themselves, how others view them, and any areas of difference between these two perceptions.

In week one, we also asked everyone in CORE to complete a user manual and discuss their user manual within their team. This helped find people who like to work in the same way, and highlighted things that different people find difficult or easy — again, the aim was to build on our collective understanding of one another within CORE and within the teams. The CORE management team also created user manuals, and everyone has shared their user manuals on an internally accessible confluence space.

As part of the move to the cross functional teams, we’re trying to move from thinking in terms of systems, to instead thinking about business capabilities, for example, moving away from thinking about Salesforce as a system, but instead thinking about the lead flow or quoting capability.

While reteaming, a key set of questions appeared when we reviewed the boundaries and remits for our new capability teams.

• What does it mean to own a system as capability team?
• What does it mean to use a system in a capability team?
• What are the criteria for things sitting in the platform teams?

Historically, the teams would have sat in a room and discussed these questions until we reached a consensus. But with in-person sessions off the table, we needed answers quickly to unblock future sessions, and for everyone to feel that they had contributed to answering these questions to build a shared understanding and a sense of ownership.

To achieve those outcomes, we ran a session using the 1–2–4-All technique to answer the questions above. It was great to see diverse groups of people come together rapidly with a single answer to a question, allowing us to quickly answer all the questions and resolve any confusion.

We have also had three new starters join CORE at the start of January, so these sessions and discussions have also been a terrific opportunity for the newest members of CORE to learn about the capabilities that we support and begin getting to know their new colleagues.

What did we do next?

There is still a lot of work to be done with our reteaming process but here are some of the activities we ran next:

• Running a session called ‘Purpose to Practice’ to help the teams create a shared purpose for why the team exists
• Building team charters, so that everyone understands what it means to work in each different team
• Building and publishing team OKRs, so that the teams can see how their work aligns with company objectives
• Backlog creation and review, to help the teams focus on the right things so they can deliver against their OKRs

Reteaming activities in a remote world requires a lot of facilitation and participation by all involved. For the time being we have paused our events to give the teams time to come together and learn to work with one another on day-to-day projects and requests, but we’ll pick up again soon.

If you’d like to learn more about how the product side of Redgate’s engineering team managed reteaming please see this blog post.