From developer dread to team triumph
In today’s fast-paced digital world, businesses need more than just functional products—they need solutions that evolve with their needs, deliver continuous value, and are backed by teams fully invested in the product’s success. When developers are empowered, engaged, and working efficiently, they create robust, adaptable products and deliver higher-quality results. Yet, many companies face the challenge of transforming legacy systems that are often seen as burdens—products that developers avoid, which hinders progress.
We have a story about such a product: a monolithic sales platform that checks all the boxes of a developer’s headache. However, our story has a happy ending. Here’s how we helped turn this monolith into a product that became a source of pride and innovation for both our customer and our teams.
Where it all started – facing the challenges
We started with three Levi9 teams. These teams were working on different domains. One team worked on functionalities related to invoicing and billing and the other teams took care of contracting-related functionalities. As both domains were connected, this created many unnecessary challenges for the developers. For example, the lack of cross-domain understanding caused integration nightmares due to domain separation.
Furthermore, the product itself was very complex from both the functional and technical perspectives. It was one big monolith with around 1 million lines of code. Monolithic architecture made changes expensive and challenging, impeding agility and adaptability. Additionally, teams were working and developing features in a shared environment. This limited the teams’ autonomy as they were heavily dependent on other people outside the team to finish their work.
It was painfully obvious that this project needed a change, so we decided to restructure the teams for a smoother development approach.
Transitioning to E2E feature teams
We first worked to reduce dependencies on other teams by establishing End-to-End (E2E) feature teams capable of independently building and owning functionalities from start to finish. This structural shift was supported by our ambitions for technical product enhancements and transitioning to a microservice architecture.
To kickstart this transformation, we engaged our software developers in a workshop, providing them with a set of guidelines to structure the teams. The rules were straightforward: each team should have four Developers, two Test Developers, a Scrum Master, and a Product Owner. Crucially, every team was required to know both the contracting and billing domains.
Through a collaborative effort, we formed five E2E teams. These teams focused on developing features from the functional roadmap and continuously delivering value for the end users. Additionally, we established specialized teams tasked with overseeing the technical transformation process. These teams resembled the platform and enabling teams as recommended in the book “Team Topologies: Organizing Business and Technology Teams for Fast Flow” by Matthew Skelton and Manuel Pais. This means Platform teams provide foundational services and tools other teams can leverage to deliver customer value more efficiently. They create and maintain shared infrastructure, reducing the cognitive load on feature teams.
Teams we refer to as Enabling Teams focus on helping other teams acquire new skills or adopt new technologies. They work temporarily with other teams to transfer knowledge and improve capabilities, ensuring the smooth implementation of technical practices and tools.
Technical improvements
Some architectural changes also had to be made to support our product ambitions. We decided to move towards microservices, containers and Cloud, to enhance the product’s monitoring capabilities and define a test strategy centered on test automation. We formed special teams to keep this process moving forward and on track. This way, by using Cloud, Kubernetes and creating sub-domain specific microservices with the “peeling the onion approach” as one of the common strategies for transforming a monolithic architecture into microservices, we achieved our technical goals while also helping teams become more efficient and productive.
Culture and process improvements
Working with a hybrid microservice architecture also has its challenges, so it was very important to nurture DevOps principles and introduce practices that enabled the teams to perform to their full potential and produce high-quality deliverables.
Architectural oversight – The two special teams were responsible for defining the architecture, making it evolve at the desired pace, keeping architectural oversight and creating an environment for a DevOps way of working. In essence, they helped all other teams reach their full DevOps potential.
High level alignment and knowledge sharing between teams – Architectural and test strategy decisions had to be done jointly, and knowledge and expertise must be propagated to all teams. For this purpose, we established communities and chapters for knowledge holders and team representatives to align.
Streamlined processes – We made sure there were clear communication channels among the teams and relevant stakeholders. Our simple and effective processes and procedures help reduce the teams’ unnecessary cognitive load.
Collaborative culture – Our integration meetings brought together representatives of each team to identify and discuss dependencies. But their collaboration didn’t stop there. We continuously fine-tuned the alignment between teams, so they could effectively work on the same product and achieve shared goals.
Building trust through reliable planning and delivery – Crucially, the teams needed to be able to deliver on deadline. So we helped them to improve their planning, efficiently address the delivery risks, and always openly communicate issues with the customer. We also introduced agile release planning for major epics.
Strong connection to the end users – We closely collaborated with the actual users of the product our teams were developing and maintaining. User representatives were sometimes part of our refinement sessions and were also involved in the release process.
What were the benefits of this approach?
We invested a lot of time and energy, but we can also show how we added measurable value to the project. Here are some of the metrics we collected to make sure we’re doing the right things and staying focused on our goals:
- Quarterly assessments of customer satisfaction showed steady increases over time.
- Team engagement was visibly higher when they had ownership of a feature from E2E (measured via team satisfaction survey)
- Up to a 45% increase in team productivity due to our various initiatives and improvements.
- Product quality improved significantly (based on the quality assessment of an independent party, microservices scored over 4 points, on a scale from 1-5)
- Reduced time to market by 20-40% (depending on which part of the system was changed)
- Comprehensive knowledge of the product and system grew within the teams.
- Personal growth & development was evident among team members (assessed via team satisfaction survey)
Lessons learned
Looking back, we can say that this was one big adventure, full of ups and downs. Here are some of our major takeaways from this journey:
- Have a good understanding of goals, priorities, and ambitions from the business perspective.
- Listen to what your teams are telling you, allow them to share their ideas and make space for them to provide feedback on products, processes, and way-of-working. You need the teams’ buy-in and that is much easier to get when you involve them from the start. Their satisfaction directly impacts the outcomes you wish to achieve.
- Be brave and dream big; set ambitious targets– It is not easy to refactor complex monoliths or change the way-of-working and culture overnight. This work requires special attention to details, good planning and coordination, close collaboration, and constant focus on motivating the teams.
- Keep the end state and goals in mind – Optimize the teams’ organization approach & the architecture design based on the end state and goals in mind. The architecture of the product should follow the business needs and tech best practices. The teams’ organization approach should enable and support the architecture.
- Be patient & persistent – Understand that substantial changes take time to settle for the effects to become visible, but if you persist, the satisfaction is truly rewarding.
By reimagining team structures, fostering collaboration, and introducing key technical improvements, we transformed a challenging monolith into a product that drives value and inspires confidence.
This journey highlighted a powerful truth: happy, efficient developers deliver better results, enabling faster delivery, higher quality, and greater alignment with business goals. For customers, the ultimate reward is a product that evolves to meet their needs, backed by a team committed to its success.
