BUILDING A MONOREPO PLATFORM TEAM TO ENSURE FAST FLOW
Over the past few years, the energy market has undergone rapid changes. Customer expectations have risen, new regulations have been introduced, and global politics alongside climate change continue to influence how businesses operate. To stay competitive in this evolving landscape, Essent IT has adopted a strategy to position itself as the driving force behind the energy business through cutting-edge IT solutions.
To achieve “fast flow”, we believe the key is to empower development teams at Essent IT by removing friction from the entire software development lifecycle—from design to deployment and maintenance. In this article, we will outline how we are reducing friction for teams building integration and backend systems that align with our target architecture.
BACKEND DEVELOPMENT AT ESSENT
At Essent IT, our strategy is to take full ownership around building & maintaining our core services. To this end, we have stream-aligned teams focused on key domains, such as energy insights, budget bill advice, and become a customer. These teams are responsible for managing the complete lifecycle of their domain-specific services.
Our backend systems are built on a serverless stack within AWS, leveraging technologies like Lambda, DynamoDB, and SQS, with TypeScript as our primary programming language. To ensure consistency across teams, we have established an active TypeScript community of practice and a Tech Crew that maintains a company-wide Tech Radar (more on this in future articles).
As detailed in an earlier article (Essent’s Tech Evolution: Monorepo Adoption and API Innovation), we have adopted a monorepo for all backend development.
SHORT RECAP ON MONOREPOS
A monorepo is a single repository that stores the code for multiple projects, often related, under one roof. Unlike polyrepos, where each project has its own repository, monorepos allow teams to share code, manage dependencies centrally, and enforce consistent practices across all projects.
BENEFITS OF MONOREPOS INCLUDE:
- Code Reuse: Shared libraries and components can be easily reused across different projects.
- Simplified Dependency Management: Centralized control over dependencies reduces the chances of version conflicts.
- Consistent Tooling: Teams can use the same tools and configurations, simplifying the development process.
CHALLENGES WITH MONOREPOS
However, monorepos can introduce challenges, such as scalability issues and the need for sophisticated tooling to manage the repository effectively. Without the right approach, a monorepo can become unmanageable and slow down development rather than speeding it up.
CHALLENGES WITH OUR GROWING BACKEND MONOREPO
At Essent IT, we have been rapidly increasing the number of development teams working on our target technology stack. Over the last two years, we have grown from just 3 teams using the monorepo to over 15 teams. Looking ahead, the projection is that 30+ teams will be using the monorepo.
Our monorepo strategy has delivered substantial practical benefits, but we’ve also faced challenges in ensuring a stable environment for all developers contributing to the monorepo.
In the early stages, collaboration between the teams using the monorepo happened naturally. When issues arose, it was relatively easy to organize solutions, and addressing technical debt incurred little overhead. However, as we scaled, new challenges began to emerge. Pipeline failures became more frequent, and addressing technical debt became more complex, as changes often affected multiple teams across the monorepo.
Initially, we addressed these challenges through monthly hackathons, where representatives from all teams would focus exclusively on improving the monorepo ecosystem. While effective at first, we soon realized that the scope of the necessary improvements had grown beyond what could be achieved in a short time-frame. This led to larger improvement tasks being spread over multiple months, which in turn slowed down overall development progress.
These challenges made it clear that dedicated, continuous attention to non-functional aspects of the monorepo was required. Specifically, we needed to focus on: - Continuous Integration (CI) pipelines - Generic building blocks - Local development environments - Continuous deployment and deployment scripts.
BUILDING A MONOREPO PLATFORM TEAM
When we realized we needed dedicated attention for the monorepo we also needed to make the choice for the monorepo very explicit. The adoption of the monorepo in the last years was organic, and not everyone was aware of the usage and potential benefits. There has been considerable debate surrounding the monorepo vs. polyrepo approach, a topic we've also discussed within Essent.
In the meantime we launched a knowledge roadshow across Essent IT for development teams as well as IT management. We explained our future plans, benefits as well as potential risks with strategically choosing for a monorepo. As a result of the roadshow, we were able to demonstrate the value of the monorepo to both the developer community and IT management, successfully influencing their decision to adopt it.
We decided that the monorepo would be the default ‘landingzone’ for backend development teams. If teams feel like they should operate outside of the monorepo, this is still possible after a formal approval.
As a result of this strategic decision we could move ahead and assemble a platform team.
THE ROLE OF A PLATFORM TEAM
A platform team, as defined by the Team Topologies framework, is a dedicated group responsible for building and maintaining the shared infrastructure, tools, and practices that other teams rely on. In the context of a monorepo, the platform team plays a crucial role in managing the repository, ensuring that it remains a solid foundation for all development activities.
Diagram outlining the different type of team in the Team Topologies framework.
TEAM COMPOSITION
To address our challenges and set up the team quickly, we formed a small, agile group of 5 developers. This included senior developers from existing teams who brought in-depth knowledge of our systems, paired with external senior developers who contributed fresh perspectives and best practices. We also included junior or mid-level developers from within the organization to provide support and gain valuable experience.
This mix of internal and external talent was crucial to the platform team’s success. Internal members ensured continuity and familiarity with our setup, while external experts introduced new ideas and approaches, fostering both agility and effective problem-solving.
CREATING THE FIRST BACKLOG & ROADMAP
When setting up the platform team’s initial backlog and roadmap, we were fortunate to have experienced monorepo developers within the team. This allowed us to quickly identify the highest priority items to tackle. However, even from the start, there were ongoing discussions about what responsibilities would fall under the platform team versus what should remain with the feature teams. We were cautious not to take on full ownership of the entire development stack, as this could lead to feature teams becoming overly dependent on the platform team, which would slow down innovation and autonomy.
To strike the right balance, we initially focused on managing and improving the infrastructure, while leaving the development of functional building blocks to the feature teams. This approach ensured that feature teams retained control over their core responsibilities, while the platform team concentrated on providing a stable and efficient foundation.
The primary goal of the platform team in its early stages was to stabilize and harden our Continuous Integration (CI) pipelines. By focusing on this critical area, we aimed to reduce build times, minimize failures, and improve the overall reliability of our pipelines—key factors in supporting fast flow and smooth development processes.
During the first six months, we identified the following key success criteria:
- Prioritize addressing user pain points: To build trust with feature developers, the platform team should focus on solving problems that the user community perceives as significant. While this may seem obvious, it’s easy to start optimizing areas without confirming their importance with users.
- Maintain continuous engagement with the community: It’s essential to stay closely connected with the developer community. Proactively interacting with developers helps prevent misalignment between platform and feature teams—a common pitfall for platform teams.
- Clarify team responsibilities: Clearly communicate which topics are owned by the platform team versus those handled by feature teams. This ensures transparency and avoids confusion about roles.
- Promote the monorepo journey across the organization: Treat the platform as a product and continuously share the monorepo’s story. Highlight both the challenges and positive outcomes to keep the entire organization engaged and supportive.
- Go the extra mile: Build a high-quality, stable platform that developers love, as this will boost developer happiness and productivity.
RESULTS
As we are scaling the usage of our backend monorepo within Essent IT, we faced various scaling challenges. By establishing a platform team around our monorepo, we achieved significant improvements in both performance and stability across our pipelines. This transformation has brought us to a point where we feel confident and in control of our development infrastructure. The positive outcomes have strengthened trust within the development community, reaffirming that the decision to adopt a monorepo was the right one.
The platform team has played a crucial role in enabling feature teams (or stream-aligned teams, as defined in Team Topologies) to focus on building core functionality, without being distracted by non-functional concerns like infrastructure, tooling, or build issues. This shift has not only enhanced the Developer Experience but also contributed to faster delivery cycles, supporting the goal of achieving Fast Flow across the organization. By allowing feature teams to focus on their strengths, the platform team has successfully reduced friction and improved overall efficiency in software delivery.