Breaking Out Our Project Team Into Multiple Stream-Aligned Teams

Problem

When I joined thinkmoney, we had one large project-focused development team. We worked on multiple projects at the same time with lots of work in progress; we would allocate engineers from this large team to work on a specific project and undergo activities such as 'resource' planning. However, our ambitious scaling plans required us to think differently, we had to consider some other options.

"Our ambitious scaling plans required us to think differently."

Thanks to data and insights we were aware of areas of our banking product where customers were not transacting as we'd expect. This made us consider smaller teams - aligned to a customer experience rather than a product or technology. We also wanted engineers on those teams to be committed and accountable for their work rather than hop from one project to another.

Actions taken

We reorganized Development to consist of multiple smaller, cross-functional teams. We augmented these smaller teams by adding UX Designers and Product Owners, making them self-sustainable. We started small; we set up one small cross-functional team first and got it up and running. We experimented with setup and processes, and only once they achieved a good level of self-organization, we emulated the whole process with multiple similar teams.

"Our first stream-aligned team (Marketplace) was set up with a clear vision and precise delineation of their domain."

Our first stream-aligned team (Marketplace) was set up with a clear vision and precise delineation of their domain. People on the team were mission-oriented and dedicated and worked hard to meet all of their key objectives and OKRs. The whole team became fairly invested and organically adopted the mission without having to be pushed by a Product Owner. That seemed critical for a mindset shift as they gradually started to understand how, as engineers, they were adding value.

As a manager, promoting a change in mindset is something that will always be challenged. I wanted my team members to understand why they should move from solely thinking about technical solutions to one of contributing and adding value to the organization. So I was patient in explaining how they could add value through ROI, low code automation, "shift left" (shifting security and testing earlier in the process), leading retrospectives or standups, etc.

We also put a lot of emphasis on collaboration and psychological safety. With clear demarcation of what the teams owned, we created rounded-up domains. At the same time, we created a psychologically safe and supportive environment where people could speak openly and voice their opinions, especially in standups and retros. We wanted our engineers to fail fast, without much time spent on deliberation and use those failures to learn, thus avoiding making the same mistake over and over again. A safe and supportive environment, coupled with clear ownership in only a few months, brought to that mindset shift and increased accountability and responsibility of all team members.

Finally, we focused on making processes more inclusive and participative. Instead of having a Delivery Manager or Scrum Master run standups, and other ceremonies, we encouraged every team member to step up and partake in the process. We would do that on rotation, ensuring balanced participation and making the team even more invested in other-than-coding activities.

Lessons learned

• Start small. If you want to reorganize your team and make it more focused on certain aspects of your product, don't experiment with the whole team. Pick a smaller group of people, organize them as a team and then start experimenting. If you fail, you will fail on a small scale. But, you will be able to gather some learnings too. If that works, you can roll it out to the second and third team, etc.
• For teams to become self-organized, you should ensure a high level of psychological safety. When they start to feel safe and supported, they will also feel more accountable and willing to take ownership.
• Managers, including delivery managers or Scrum masters, also need to undergo a mindset shift. In self-organizing teams, backlogs should be collectively reviewed and regularly prioritized so that engineers can pick any work rather than waiting to be assigned work. Managers should be genuine servant leaders supporting engineers to make the decisions and be there to unblock them. As servant leaders, they should also spend a significant amount of time coaching the team rather than delivering instructions.
• Self-organizing teams excel when they have a great support framework. Leaning on Product Owners, Delivery Managers, Engineering Managers, and Technical Leads will ultimately set teams up to succeed.
• Embrace organizational evolution over transformation. Change is constant, it has no end.