Back to resources

Breaking Out Our Project Team Into Multiple Stream-Aligned Teams


1 June, 2021

Ehsan Imran
Ehsan Imran

Engineering Manager at thinkmoney

Ehsan Imran, Engineering Manager at thinkmoney, shares how he helped new, stream-aligned teams make a mindset shift and coached them to become more self-organized.


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.

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. 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, shifting security and testing earlier in the process ("shift left"), 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 organisational evolution over transformation. Change is constant, it has no end.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Building A Team
Internal Communication
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Here to Make a Recognizable Difference: How to Develop Teams

5 May

Eric Merritt, VP of Engineering at, divulges on the many complexities of developing teams in management by solving problems according to their needs, and empowering teams.

Sharing The Vision
Coaching / Training / Mentorship
Eric Merritt

Eric Merritt

VP of Engineering at

Balancing Technical Debt Innovation: How Roadmaps for Development Help Your Company Succeed

4 May

Brad Jayakody outlines the roadmap to maintaining a healthy balance between technical debt and team growth. However, just as balancing acts go it is important to have a strong foundation.

Tech Debt
Career Path
Brad Jayakody

Brad Jayakody

Director of Engineering at Motorway

How to Produce Impact as a New Engineer

4 April

Hossain Khan, Principal Software Engineer at WeWork, shares experiences and lessons he’s learned from his career, as well as tips on how to continue a learning mindset.

Personal Growth
Nhm Tanveer Hossain Khan

Nhm Tanveer Hossain Khan

Principal Software Engineer at WeWork

Typical Challenge of Scaling Teams: What to Do When Your Process Doesn’t Scale

30 March

Christophe Broult, Director of Test Engineering at diconium, focuses on how he scaled his team while building organization and management teams in place.

Scaling Team
Building A Team
Team Processes
Christophe Broult

Christophe Broult

Director Test Engineering at diconium

You're a great engineer.
Become a great engineering leader.

Plato ( is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.