LeSS Transformation in Wartime Ukraine: Building an Adaptive Organization at DIM.RIA

A story of how a Ukrainian PropTech company redesigned its structure, embraced LeSS principles and built adaptability and resilience amid the challenges of full-scale war.

About the Company

DIM.RIA is one of the leading Ukrainian PropTech platforms and part of the RIA.com Group, one of the country’s largest digital ecosystems. The product is a real estate marketplace that connects buyers, sellers and agents across both residential and commercial segments.

The company’s core value is trust through verified information – its mission is to provide users with only verified, reliable listings, ensuring transparency and confidence in every transaction. Beyond listings, DIM.RIA offers verified property data, valuation tools and digital services that help users make informed decisions. Over the years, it has become one of the most trusted and widely used sources for property search and transactions in Ukraine.

At the beginning of 2022, when Russia launched a full-scale invasion of Ukraine, the real estate market faced turbulence. Demand and construction volumes dropped sharply, with many projects suspended or lost due to hostilities. Companies in the sector had to adapt quickly, rethink their business models and stabilize operations amid constant uncertainty and shifting market dynamics.

Our organizational transformation took place entirely remotely – online. Because of safety concerns, blackouts and the realities of war, our people were spread across Ukraine and even beyond its borders. Yet, despite the distance and challenges, the teams managed to stay connected, collaborate effectively and drive deep structural change together.

This transformation became a living example of how people can unite and overcome extraordinary challenges, even when dispersed across different parts of the world and successfully carry out something as complex as an organizational transformation.

Acknowledgements

I want to express my deep gratitude to the entire team for believing in this change. You are amazing!

Special thanks to Roman Marchenko (Chief Product Officer, Board Member) and Oleksandr Lishchynskyy (Chief Technical Officer, Board Member) for the trust and engagement.

Introduction

In the summer of 2024, I joined the team DIM.RIA. At the time, the company employed over 100 people, with approximately 50 working within the product organization.

The product team was actively searching for organizational solutions. The main question was:

How should we organize our work to achieve better results?

The organizational structure had been adjusted multiple times, often in response to shifting definitions of the product. In earlier periods, management had attempted to implement selected elements of the Scrum framework, hoping this would improve team efficiency.

As I later heard from team members, they had experienced so many transformations that they joked they could survive one more. But I felt the teams’ fatigue after these words. Because these changes lacked clear direction, addressed only short-term problems and focused on local optimization.

Studying the Organization

I began exploring the organization by asking management a simple but fundamental question:

 “Why does your structure look like this?”

The team was divided into three main areas: Sellers, Buyers and Core functionality.

●      The Buyers stream focused on users and product features aimed at people searching for real estate.

●      The Sellers stream, in turn, worked on tools and features for those listing properties.

●      The Core team developed functionality for internal users, such as moderators and internal departments, and was responsible for building shared services, databases and other foundational components.

Within each stream, there were managers responsible for specific parts of the product. As a result, each manager had their own list of tasks, prioritized independently.

In addition to Product Managers, there were also Project Managers who coordinated team events such as sprint planning, daily scrum and retrospectives. They were responsible for writing task descriptions, documenting requirements and tracking the status of work within each sprint. Each stream also included roles such as a Data Analyst, Designer and Team Lead.

Development Teams

As for the development teams, they were divided according to clear specializations. Full-stack developers worked on both backend logic and the frontend logic of the web application. Mobile app developers focused exclusively on the mobile application and were not involved in backend development. QA specialists formed a separate team and were primarily responsible for manual testing of anything assigned to them. There was also a dedicated frontend markup specialist who handled web layout tasks.

In this setup, specialists were focused strictly on their specific areas of work. However, they often lacked broader context about what was happening in their part of the business. Within each stream, individual specialists worked only on the specific functionality assigned to them. That made it easier to control changes in their part of the product, but limited visibility.

Only the Team Leads of each stream had a wider understanding of the overall picture. Design and analytics competencies existed within two of the streams. However, they operated separately from the development teams. Instead of working as part of cross-functional squads, designers and analysts received tasks directly from product managers.

Sprint flow

The teams did not have clear sprint goals. Their main focus was simply completing their individual lists of tasks.

Before sprint planning, some tasks might have been discussed between individual specialists and a product manager to clarify certain implementation details. But in practice, it was the product/project manager who wrote the requirements and assigned tasks to different specialists for execution.

On planning day, each product manager would gather tasks from their own backlog that they wanted to include in the sprint. The stream team would then come together and each manager would take turns assigning work to the developers they were in regular contact with.

At the end of the sprint, a presentation was held where managers shared what they had planned for the current and previous sprints, what had been released to users and what was still in progress. Developers did not participate in these presentations at all.

This is an example below of how a large feature, intended for all platforms, could end up being developed over multiple sprints due to functional separation and a long chain of handoffs.

Not every feature took as long as five sprints to complete, but the same working pattern remained. For instance, the mobile app team couldn’t start their part until the backend work was finished – which often meant waiting until the next sprint to even begin.

And in reality, these handoffs rarely went smoothly. Mobile developers would go to the Team Lead or product manager and say that the backend was delivering incorrect data. The managers would then step in to resolve the issues.

The organizational design through the Org Topologies

These observations gave me a clear understanding of the organization’s setup. Viewed through the Org Topologies the organization clearly matched the Resource Topology archetype.

The development teams were positioned at levels TASKS-1 and TASKS-2. So the delivery was fragmented and coordination-heavy because of a lot of hand-offs.

At the same time, Product Managers and Team Leads operated at levels PART-1 and PART-2, reflecting their partial ownership of business areas and decision-making responsibilities. A big part of their job was coordination across multiple teams.

Teams were not empowered to deliver independently across the full value stream. They were workloaded due to their individual capacity. That’s why the whole delivery flow was based on handoffs. Managers or Team Leads obtained the role of coordinators in this process.

This organizational design shows that the structure was built around utilization, driven by a resource-management approach and the splitting of product areas and codebases across different teams or specialists.

In practice, the organization was optimized for utilization and coordination, rather than for flexibility and flow.

Assessing the organization

With this understanding I finally got an answer to my question: “Why does your structure look like this?” and here’s what I concluded:

●      It was a linear decision made as the team started to grow.

●      The structure made it easier to manage developer workloads and assignments.

●      When each developer works only on what they already know, they naturally maintain control over changes in the codebase, and it’s always clear who to talk to if something breaks.

This belief reflects a mental model of local ownership and specialization – one that shaped the structure of teams, roles and workflows across the product organization. And it shows how an initial need and a mental model can lead to growing organizational complexity.

In our case, streams meant new product functionality. So when the team realized they needed to build something new (for example, a new search or filtering capability), it was treated as a new project. And the belief was that each project needed its own manager to lead it. As a result, adding new streams naturally increased the number of managers and developers, which led to overall team growth.

R1: Growth Trap Loop

As the team grows, communication becomes more complex, leading to coordination problems and inefficiencies. These problems create pressure on Product Owner, who respond by hiring additional managers to improve control and oversight. But this only increases the size and complexity of the system – feeding back into more communication overhead and more problems.

This loop is self-reinforcing and hard to break from within. It feels like you're solving problems by hiring additional managers, but in reality, you're fueling them.

R2: Backlog Multiplication Loop

As the team scales, more managers are added. Each manager tends to manage their own backlog (due to the mental model of individual responsibility), increasing the number of disconnected lists of work. This increases cognitive load, misalignment and pressure on Product Owners who must now coordinate across more fragmented areas. In response, the organization again hires more managers and the loop continues.

Together, these two reinforcing loops created a self-sustaining trap. The more the organization scaled, the more structural and coordination complexity it introduced. Attempts to regain control, by adding more managers and splitting ownership, only deepened the system's inefficiencies. Over time, this created organizational fatigue, misaligned delivery and mounting internal friction, despite the good intentions behind every decision.

 

Diagnosis Summary

The current structure is characterized by handoffs, fragmented ownership and manager-driven coordination. It is optimized for resource allocation and control, rather than for efficiency and value delivery. This design emerged not as a deliberate target, but as a result of well-intentioned decisions aligned with a mental model of individual specialization and responsibility.

This structure became self-reinforcing: developers executed assigned tasks, while problem-solving and coordination were handled through managers. The organization, while growing, unintentionally optimized for control – not adaptability or learning.

Designing the future organization

I presented my observations and conclusions to top management. While the overall reaction was positive, some points were difficult to accept. The biggest insight came when I explained that the goal of the current structure wasn’t efficiency,  it was utilization and resource management.

This highlighted that utilization and resource management should not be the primary goal of an organization. Because it didn’t bring benefits anymore. The management realized that simply adding more people wouldn’t lead to greater efficiency or better performance. In fact, it could make things worse.

After all those conversations and reflections we back to the familiar question which I mentioned at the beginning:

“How should we organize our work to achieve better results?”

This is the key question that determines the state of the future organizational design. From the earlier findings and research, I began forming certain hypotheses about the future organizational design. But the answer wasn’t straightforward. So, I wanted to validate my vision. I decided to clarify the organization’s needs. Because understanding those needs shapes how the organization must operate in order to achieve its product goals.

My next step was to review the Product Strategy, Product goals and initiate a round of additional conversations with management to clarify the organization’s real needs.

As the result of this research, the main organization’s needs were:

1. Focus on what matters most and prioritize according to the overall strategy.

2. Make product decisions based on data and real user needs.

3. Ensure consistent functionality for all users across all platforms.

And it was aligned with the LeSS principles:

●      Whole product focus

●      Customer centric

●      Empirical Process Control

Comparing the current state and the organization’s needs, the conclusion was obvious: the existing organizational design couldn’t meet those needs. As I mentioned in the first part of this case, the structure was effectively optimized for utilization and control of work and not for adaptability, learning or delivering product value.

It was close to my previous hypotheses. But to be honest, I still didn't believe in the idea of LeSS Transformation. Because it looked like  a difficult and complex journey – elevating an organization from component teams to end-to-end feature teams. I wasn’t sure the organization was ready to take on such a huge challenge.

As I mentioned earlier, the organization had already gone through many different phases of change and transformation. Because of that, the motivation to make the new round of changes, even if it is more structured, was very low.

"Once again, we’ll start changing something, but in the end, it won’t affect anything, and we’ll just go back to how it was," – one of the Team Leads told me.

Such a fundamental change should always be about organizational structure. Especially, when the organization's needs are intertwined with LeSS principles. LeSS adoption always required structure changes.

Three Adoption Principles

LeSS defines three adoption principles that describe the necessary conditions for organizational change. The first principle "Deep and Narrow over broad and shallow" suggests starting change within clear product boundaries rather than attempting to transform everything at once for reducing risks.

The second principle, “Top-down and bottom-up,” states that transformation cannot be driven from only one direction. Leadership must actively support the change and explain its business intent, while teams need to be involved and understand the purpose behind it. This alignment between management intent and team-level ownership requires shifts across the entire operational layer, including how the organization thinks about product development.

The last principle, “Use Volunteering,” emphasizes that transformation depends on people who are willing to step forward as change drivers, leading by example and encouraging others to engage.

Applying the Three Adoption Principles to our context, the first principle was straightforward. As part of the organizational changes, we needed to focus on a specific area of product development involving about 50 people. According to the second principle, my intention was to work across all levels of the organization, not to create yet another local optimization at the team level. However, the third principle raised some questions. I had strong support from the C-level executives – they were active and deeply engaged in the process. But the teams were still uncertain. They didn’t fully understand what was going to happen or, if changes did occur, where those changes would actually lead.

Absorbing all these thoughts, I shared with the management that we should begin with a LeSS Organizational Design training. This training had several goals:

1. Involve people in understanding the current problems we were facing;

2. Educate everyone because it is an important part to help everyone understand why behind the needed change;

3. Check the mood of the team and how LeSS concept would met;

4. Identify volunteers who were motivated to support and lead the change

LeSS Organizational Design training

Educating everyone is a difficult challenge especially when we're talking about 50 people. So the decision was to start with the first training group which included: C-level representatives, Head of Product, all Product Managers, Project Managers and Team Leads from development, analytics and design.

This group included the key authority figures within the product development organization – those whose understanding and support would be critical for any future change.

I started preparing for the training. And then I created a chat in a common workspace to announce this event for this group with all details and agenda.

The LeSS training programme:

Day 1: Complex domain, Scrum basic, System Thinking, Optimizing Goal, One Product Backlog.

Day 2: Scaling, LeSS principles, Team design and capabilities in LeSS setup, Cross-Team Refinement, LeSS Adoption steps.

After the full two-day training, we achieved great results. Aligned with the training’s goals, we were able to highlight current organizational problems and explain the dynamics behind the existing structure. Participants gained a deep dive into system modeling, which helped them better understand the underlying patterns and causes within the system.

The key insights that were:

●      The existing organizational design optimized for utilization and control of work.

●      We need to define a clear optimization goal.

●      We should move toward a single Product Backlog.

●      We must align around one shared Definition of Done (DoD).

●      We need to rethink team structures and roles.

●      And we must place greater focus on user needs.

I was surprised by the level of engagement. People were energized by being involved in discussing challenges across the organization. And they were part of the organizational designing and decision making process. For the first time, they didn’t feel like they were simply receiving instructions from above, they felt like they were co-creating the future of the organization, not just following top-down directives.

Almost all 20 persons became drivers of future changes in the company. And based on training’s insights we created a Transformational Backlog together as a team.

The Items in Our Transformational Backlog:

●      Create the Optimization Goal

●      Create a single Product Backlog for the Whole Product

●      Accept the decision about the team structure changes

●      Conduct LeSS training for the engineers

●      Team Design Workshop

●      Accept the DoD for Whole Product

●      Preparing tools for the teams’ online work

●      Conduct Initial PBR (new format)

But there were still open questions about Product Backlog, Teams’ Flow. While the training topics were clear and well-received, fully accepting them required a significant mindset shift.

It’s important to highlight that this training was not just about introducing the LeSS framework. Honestly, we didn’t focus on terms like “LeSS” or “LeSS Transformation.” Instead, we approached it as a process of organizational design, using systems thinking and LeSS principles to shape the possible future state.

But the training wasn’t the end of that process. Over the following 4 months, we prepared for the flip toward a more adaptive organizational structure. During this time, we did a lot of work: discussing, debating and aligning around key topics like the Product Backlog and Team Flow.

We were able to carry out comprehensive work on identifying the organization’s needs and conduct high-quality training. This training helped the team gain knowledge in system modeling, new approaches to product development and product management, as well as a deeper understanding of LeSS principles and practices.

Creating the Optimizational Goal

This was a particularly difficult step. We were misaligned in our visions and priorities. Despite the training and shared insights, the old mindset was still holding us back from moving forward.

I pushed for a focus on adaptability, because it was clearly rooted in our previously defined organizational needs. However, part of the transformation team remained focused on financial goals above all else.

In the first iterations, the proposed optimization goal sounded like: "Maximizing company profit through the execution of the product strategy." – with a small note underneath: "One Product Backlog, Cross-Functional Teams.". And nothing about organizational structure. I didn’t like it at all.

Over the next few sessions, we focused on creating the Optimization Goal. We returned to the organization’s core needs as the primary source of our direction. I reminded the team of the key insights from the training and the LeSS principles – all of which pointed toward adaptability as our central challenge and aspiration.

I reminded them that the current structure was not designed for adaptability. It was built for control, coordination and utilization. That’s why the Optimization Goal had to reflect the real purpose behind the change, not just surface-level improvements.

We needed a goal that would unify the organization and guide future design decisions. It defines what the entire system is intended to achieve. Without it the common understanding of changes could be lost. And looking ahead, I can say that the Optimization Goal truly helped us make the right decisions about the future organizational structure.

After several sessions of discussing and repeating all that we learned from the training we reached a shared agreement on our Optimization Goal and we all agreed that this is a vision that will help us to elevate our adaptability:

To build an organizational structure that enables self-managing development teams to focus on delivering the most valuable functionality for users.

Q&A sessions

At this stage, only the volunteer group knew about the upcoming organizational design change. Even after we had completed the training, created the transformation backlog and defined the optimization goal, people still had doubts about the future design. And I understood them, when you start to realize that you’ll have to break a familiar way of working, along with all your established processes and connections, it’s natural to want to take a step back.

Although the training helped them see the situation from a different perspective and even inspired them, there was still fear and a feeling that everything might break and get worse.

So before moving forward and announcing the change to the entire team, we needed to align among ourselves to present one clear, unified message. The main doubts were about: the Product Backlog, the role of Product Managers, E2E feature teams, Definition of Done and sprint dynamics in the new setup.

So we ran a few Q&A sessions discussing these topics.

We started with Product Backlog. All work items were stored in Jira, but spread across different projects. Each team: iOS, Android, Web and QA, had its own Jira space with different workflows, statuses and definitions of done. In addition, every manager created their own items in separate projects, maintaining personal lists of work.

I reminded them that the Product Backlog should be:

●      A single source of work for all teams

●      Ordered to maximize progress toward the Product Goal.

●      Prioritized by the Product Owner

I explained to them what a Product Backlog Item (PBI) is and introduced the concept of vertical slicing. That’s when they realized we would need to create the Product Backlog from scratch. This was disappointing for them, as they already had a large number of requirements in Jira. Now, all of that would have to be merged into a single list and, even more challenging, the specialized tasks could no longer exist. At this point, I felt some resistance which was natural.

I refocused them on the Organizational Needs we had discovered together. These needs aligned with Whole Product Focus, Customer, High Value Items Delivery, Customer Feedback. This alignment helped us make the final decision to create a single Product Backlog.

Regarding the role of Product Managers, I explained that they were not going anywhere – instead, they would become more involved with the Product Owner’s team. The only condition was that they would no longer have their own separate backlogs to manage. Instead, they would contribute to the single Product Backlog and the overall product work, without being tied to specific teams.

The possible New Organizational Design

The most interesting discussion was about teams’ flow and teams’ design. They began to challenge the idea of feature teams. Everyone understood the need for change and the reasons behind it, but the transformation team started asking questions and reflecting on possible designs. It was difficult for them to imagine a format where they were no longer tied to specific product areas. Their proposal reflected this concern: keep the separation between Buyers and Sellers, but remove the Core team and distribute its competencies across the two streams.

From their perspective, this made sense for two reasons. First, such a design was more familiar to them – they could keep their existing competencies and since the product had both Buyers and Sellers on the platform, developing in these two directions seemed logical. Second, it required less effort, meaning the change could happen faster while globally keeping the structure they were used to.

But this was a very fragile moment. I remembered the phrase: “When the structure changes, the behavior changes as well.” In their proposal, the structure essentially remained the same setup, just with slightly reconfigured teams. I asked them directly: “Why do we need to keep these two directions at all?” For them, the answer was simply that it was familiar. What they couldn’t yet see was how to combine both directions into one Product Backlog and ensure meaningful collaboration between the Product Managers and the teams.

I started filtering their vision through the lens of the organization’s needs and pointed out where their proposal didn’t match. Second, I reminded them of what we had agreed during the training: that our product is not about separate streams. By removing those streams, we could increase our adaptability, not by creating work for specific directions, but by exploring user and product problems and solving them with a faster response than we have today.

The proposed design still reflected old thinking – distributing work by competencies. This would have required creating new teams whenever new skills or product directions emerged, adding unnecessary complexity to the system.

When speed of change was raised as an argument, I challenged it by asking how previous “quick” transformations had truly improved the system. Through these questions, I helped the group shift their perspective from local optimization and short-term fixes toward systemic needs and whole-system functioning.

Finally, we agreed that the quick and simpler solution did not meet our needs or align with our optimization goal. Keeping the two product streams would only preserve the system’s existing problems. We chose to make a complete structural shift creating an adaptive and value-driven organization.

Involving volunteers, especially team leaders, made it possible to address much of the initial resistance and doubt right from the start. It also allowed us to finalize, together, the shared vision of the future organizational design.

Communication to the whole team

After we reached a shared understanding with the volunteer team, we began preparing for a meeting with the entire team to involve them in the current challenges and explain the need for changes. We prepared a presentation in which we talked about:

●      the functions and goals of the current way of working

●      the organization’s needs

●      the main insights from the training

●      the optimization goal

●      our next steps

Since the key leaders were already engaged, answering questions and facilitating discussion became much easier. The explanations were coming from people who had been working alongside the team for years and not only from me.

The team especially liked the plan. We explained that the preparation phase would last several months and wouldn’t start the day after the meeting. As part of this preparation, we would go through training together and address questions as they arose. This approach gave them the opportunity to feel involved in the process.

Learning Organizational Designing and LeSS Framework with rest of team

I remember that a few times the management suggested that maybe we shouldn’t conduct training for the team and instead speed up the implementation of changes. But this is a principle that cannot be violated and it was my main condition – to train everyone.

So, I reviewed the structure of the previous training and made some adjustments, adding more emphasis on the principles of working with a single backlog, feature teams and the main events in LeSS.

During the training the most discussed topic was E2E team design. It took time to explain to them why the organization needed such kinds of teams. I prepared the frame with types of team design: narrow focused specialists (BE, FE, etc.), multi-functional teams responsible for some functionality, cross-component and cross-functional teams. And asked them to generate pros and cons for every type. We discussed and then I asked, what type is aligned with organizational needs and our CLD. Only a few people said that third type. We stepped back to the Single Product backlog and asked them to explain how the 1st or 2nd type could match. Gradually, they began to see that only the third type could truly support adaptability and whole-product focus. It wasn’t easy for them to shift their thinking, but eventually they agreed.

We finished the training with a batch of insights. The team realized their accountability and influence on the product was much greater than they had assumed. They gained an overview of LeSS and system modeling.

I especially remember one developer saying afterwards: “Nothing like this has ever happened before, that we are involved in shaping the changes, that our opinions are asked and that problems are discussed so deeply.”

Before team design workshop

The LeSS guide recommends running a Team Self-Design Workshop. After our training, we met with the Team Leads to discuss the next steps. When I presented the workshop agenda, they were not comfortable with the idea of letting people select their own teams.

Their main argument was that before working with me, they had already gone through several reorganizations that year. By this time, they were only just beginning to settle, build trust and establish working relationships. The idea of reshuffling everyone again felt too disruptive and they were not ready for it. They were ready to agree with some changes to balance all teams with all necessary competencies.

I decided to make a compromise and step away from the LeSS recommendation. Looking back, I wouldn’t call it a critical mistake, but it did slow down the pace of knowledge sharing and reduced the initial willingness of teams to take on unfamiliar PBIs. The lesson I learned here: trust the system, not the fear. Because the fear blocks any useful changes.

However, it only slowed us down and it didn’t stop us. With every Sprint, teams became increasingly confident in picking up new items outside their comfort zones. The fear of mistakes gradually disappeared, as the new structure encouraged exploration and learning.

Team design workshop

We held this workshop online. Ideally, such a session works best when everyone can gather in the same physical space, but due to the war and blackouts in Ukraine, we didn’t have that opportunity.

The plan on the workshop were:

-       Introducing the team design and setup

-       Building the competencies map

-       Creating perfection vision

-       Define DoD

Introducing the team design and setup

The team listened to the arguments about the teams’ setup decision. They agreed with the purpose of feature teams and the proposed team composition. Still, there was some nervousness, as it was a completely new experience for them – working together in one team with web, iOS, Android and QA specialists.

The next was creating the competencies map. All new teams went to the virtual rooms to discuss their experience, knowledge and skills. When they came back, they were more energized and motivated. This part turned out to be very valuable, they learned a lot about each other and even more importantly, they saw what their teammates wanted to improve and agreed to support each other through knowledge sharing.

Perfection vision

On that positive wave we went forward and worked on Perfection Vision. I asked them to imagine the ideal state of engineering practices, product, organization.

They wrote down many different ideas of what they wanted to see in their product. These included improving stability, boosting business metrics, increasing technical expertise, enhancing teamwork and much more.

I remember them saying that they had never discussed these things together before. Now, they could see just how many great ideas emerged from such a conversation. They also noted how engaged everyone was and how interesting it was to listen to each other. It brought them closer together as a team.

Definition of Done

At this stage, we spent time discussing the current Definition of Done (DoD). We quickly noticed differences – each team had its own conditions for what counted as completed functionality. We gathered these together and created a shared baseline list called “DoD NOW,” which became our starting point.

Then, I asked the teams to think about what they wanted their DoD to look like in the future. I reminded them of the perfection vision and gave them time to work in groups. Afterwards, we shared the results and voted on which items were both realistic and important. This became our improvement list “DoD 2.0” and we agreed it would be our collective focus for next improvement.

The end of the workshop

We did a great job that day. The teams left with a stronger sense of ownership and mutual trust. For many it was the first time they had open discussion about vision, product, their impact and how they could support each other across roles and platforms. This created energy, motivation and a shared belief that change was not only possible, but also within their influence. We closed the session with clarity that we would build a structure capable of delivering end-to-end product value.

But I made a huge mistake that affected us later. At the time, I didn’t realize how critical it would be. I overlooked key competencies such as design and analytics, which should have been embedded within the teams. I will describe this in more detail later.

Product Backlog Creation

After the Q&A sessions about the Product Backlog I mentioned earlier, the PO and Product Managers organized themselves into a working group. Their main task was to create a transparent list of high-value items that weren’t sliced into narrow technical tasks.

From there, we began prioritizing the Product Backlog in alignment with the Product Goals. By the end, we could finally see what really mattered most and this clarity allowed us to identify the highest-value PBIs to bring into the Initial PBR.

Initial PBR

The LeSS guide recommends that the Initial PBR last for two full days. In our case, we spent three days refining PBIs. We worked through a large scope, refining everything in the backlog several sprints ahead. Looking back, I can say this wasn’t necessary. Refining just two sprints ahead would have been enough.

At the time, we did it because we had the false feeling that it would make things easier, and because we didn’t yet understand our delivery rhythm and actual capabilities.

We started with the product strategy and the main product goals. The PO emphasized what was most important for the product, how the product needed to evolve, what steps we had to take and which metrics we would focus on.

This stage helped broaden the teams’ understanding of expectations and impact. Previously, teams, and even individuals, were used to working only within their own parts of the product. Now it became clear that the boundaries were wider. Teams began asking questions about the product and its goals. This was something completely new compared to what I had seen during planning meetings in the old structure.

Then we moved on to presenting the PBIs, where the PO together with the PMs briefly explained the context of each item. The teams paid close attention, asking the PMs clarifying questions such as which platforms a particular feature should be implemented on. It was fascinating to watch, because in the past teams would receive tasks already split by platform. Now the teams themselves were seeking clarification.

After walking through the backlog, I asked the teams to split into small groups to refine backlog items. We ran several rounds of multi-team PBR. After each round, I suggested giving short feedback. After the first round, it was clear that people were not yet generating solutions as much as they were learning with the parts of the product functionality. For many, this was entirely new knowledge. Within the groups, more experienced specialists in specific areas explained to others how the systems worked.

Round by round, we kept moving forward, building up more and more shared knowledge. I remembered the doubts teams had voiced during the LeSS training, when they questioned the point of feature teams: “How will I work with the backend and discuss tasks if I don’t know the backend?” And then I watched them in practice – a backend developer sitting with iOS and Android developers, figuring out the API logic together.

In another group, developers explained to a PM how the current search logic on the website worked and suggested possible implementation options. Other group members were present, listening, asking questions and learning new functionality themselves.

The next day we continued our work. Together, we defined the greatest value we needed to deliver in the upcoming Sprint and identified the most high-priority PBIs. Then I asked the teams to meet separately, review those PBIs and decide which work they could take on. After that, we ran team-level PBRs so they could prepare more deeply for the Sprint. At the end of the day, we gathered again to summarize the results of our work over the past days.

The teams felt a strong sense of responsibility and didn’t want to make mistakes. They were eager to understand the PBIs thoroughly, so they asked to dedicate one more day to learning and refining them. From my experience, I knew they would not be able to break everything down to the smallest details or prepare perfectly for the Sprint, but I decided to support their initiative. For me, it was a positive signal that they were engaged and making decisions within the process.

Sprint Planning

After all 3 days of Initial PBR we gathered on the Sprint Planning. As the teams had already chosen their PBIs, we started with Sprint Goals. The PO stated the main focus and then we reviewed the PBIs once more to ensure they aligned with the goal.

Next we clarified dependencies among the PBIs and lack of knowledge among the teams. And there teams agreed about coordination and consulting each other during the sprint. And then we took time that teams go and planned their work, define their sprint goals and observe their scopes of sprint to finalize all.

After that, we all gathered to finalize the Sprint goals and the work for the Sprint.

Sprint Goal

This was our first experience in defining a Sprint Goal. Even with all the available recommendations, it doesn’t mean you can immediately do it well. But it is important to start, and to improve gradually. To define a Sprint Goal, you need to answer the question: What exactly do we want to invest this sprint in? Or What specifically should change in our product after this Sprint and why?

These questions point the way toward creating the right kind of goal. Around them, the team can start practicing setting goals, even if at first they are not very clear or perfect. It is a practice that helps build product thinking within the team.

However, it is important to avoid goals that are too abstract or technical, such as: “complete all tasks” or “deliver tasks to testing.”

Closing Sprint Planning

When we finished planning, the teams still felt nervous. For them, this was a completely new way of working. They didn’t yet know their real capabilities, how the new setup would function, what problems might arise or how to solve them along the way. So I reminded them that for some time we would simply be adapting and experimenting with this new format. I emphasized the importance of sharing feedback, because that would help us move through this phase faster.

Despite their concerns, they wanted to try. Compared to all the previous transformations they had experienced, this time felt different.

We did it online

The main challenge in our journey was that we were doing all of this during the full-scale war in Ukraine. We had no possibility to gather together physically, as the team was spread across Ukraine and around the world. So everything had to be done remotely, using online tools. Despite all recommendations to work on such changes in one physical space, for us it simply wasn’t possible.

Even under these conditions, we managed to carry out comprehensive preparation work entirely online, following LeSS guides and principles, and it worked. We:

●      educated everyone

●      involved the volunteers

●      created a single Product Backlog

●      created 3 feature teams capable of taking on any PBI from the Product Backlog

●      did the initial pbr

●      planned the sprint

Through this experience, I can say that the real strength lies in the team. When people truly care about their product, are willing to make it better, act as ambassadors of change and open to experimentation, then even being far apart, in the difficult conditions of today, teams are capable of making big transformations.

From an organizational dynamics perspective, the challenge was even greater: questioning an entire way of working that had been built over years, and then shifting to a completely new structure within just 4 months. It was, in fact, a stress test for the entire organization. And I am deeply proud of the people I worked with to make this possible. I believe I was fortunate to have this team.

LeSS Organizational design

Making the flip is a major event for any organization. It represents the moment when it dares to challenge its familiar way of working and rethink itself. However, at this stage, it is very difficult to evaluate whether these changes will actually lead to the expected results. The teams move forward mostly on belief and adrenaline, as the familiar structure they were used to no longer exists. I can say that when an organization makes the flip, that’s when everything actually begins.

The entire preparation process took us about four months. However, I believe that if an organizational change has the highest priority and strong management involvement, this preparation phase can be completed in a shorter time. Still, speed should not be the key criterion in a transformation process. It’s better to invest more time in preparation, discussions and involving people, so that the organization truly understands the necessity and embraces the idea of change. That’s why it’s important not to rush – just to be faster.

Here is how the new structure looked compared to the previous one. It clearly illustrates the reduction of complexity and the descaling effect that emerged after the transformation. Multiple fragmented backlogs and component-based teams were replaced by a single Product Backlog and three cross-functional feature teams capable of working across the whole product.

Teams dynamic at the beginning

The first two Sprints were not very representative in terms of evaluating the results of the new way of working. During that time, there were several staffing changes unrelated to the transformation itself and it also coincided with the vacation period. Therefore, we can say that the beginning of 2025 became the point when we could truly start assessing the impact of the changes.

However, even in the first Sprints, the teams began to notice significant changes in their work dynamics. The full responsibility for managing and organizing their work had now shifted to them. The teams started independently organizing their Daily Scrums, resolving development issues and coordinating their work. Managers, who previously facilitated meetings or made technical decisions instead of engineers, were no longer involved in these processes.

This happened due to several factors:

●      Team design. Each team consisted of 8-9 engineers, which significantly simplified communication and interaction – both during team meetings and in day-to-day work.

●      Sprint Goals. The teams now set their own Sprint Goals and were fully responsible for achieving them. Consequently, they also took ownership of resolving all questions and challenges related to reaching those goals.

This simplified interaction and helped the teams become more autonomous and they liked it much more than in the previous structure. Now, within their own teams, they discussed progress directly, shared information openly and highlighted where support was needed. The teams also started communicating directly with other teams whenever necessary, which significantly accelerated problem-solving. They no longer had to wait for a manager to find time to gather everyone and lead the discussion. It was a small, but meaningful victory that built confidence and trust that the changes were truly making things better.

Product Backlog

A single Product Backlog for the entire product was something completely new for the organization. It started to create a shared understanding of what was truly important for the product. In practice, it became the single source of work for all teams – the place that answered the question: “Where is the product heading?”. Over time, this shared understanding continued to improve.

We created an end-to-end backlog that included PBIs from various product initiatives. The Product Managers, acting as subject matter experts (SMEs), met regularly with the PO to keep it up to date and to define priorities together. Structurally, it looked like this:

But there were several problems. The first issue we began to notice was decomposition or rather, the lack of it. In the first Sprints, neither the managers nor the teams had yet developed an understanding of iterative development.

As a result, the PBIs brought to PBR sessions were mostly clarified and discussed from an implementation point of view, but not broken down further. The teams then took several of these large PBIs into the Sprint and were unable to turn them into a ready Increment by the end of it.

The teams were finishing their work on these items by the end of the Sprint, usually at the testing stage, at best. For several consecutive Sprints, the situation didn’t improve.

Working through this together with the teams, we identified that this was a clear violation of our Definition of Done. If we look at this moment in terms of metrics, the Sprint Task Completion Rate was around 45–55%, while the Sprint Goal Completion Rate was about 40%.

To address the issue, we agreed on the following steps:

●      During PBR, teams should decompose any PBI that is too large to complete within one Sprint.

●      Reduce the number of PBIs brought for discussion during PBR.Gradually decrease the number of PBIs planned per team for each Sprint.

●      Ensure that everyone understands and adheres to the DoD so that each Increment meets it fully.

At the next PBR, I began by explaining what decomposition and iterative development mean. I suggested we try decomposing a PBI using a real example, so everyone could understand both the process and the expected outcome.

This small workshop helped everyone understand how decomposition really works. It also helped us manage expectations within Sprints more effectively. Managers and teams began to see the concept of “customer value” differently. They realized that value can be increased iteratively step by step by gathering feedback from users along the way. This was very different from the way they used to work before.

Product Backlog Refinement

PBR has become an integral part of the teams’ work and learning. It is thanks to multi-team PBR that we maintain knowledge sharing across teams, which greatly improves understanding of both the product development context and the engineering context. This is especially important considering that, in the past, developers worked only on separate parts of the product. In my opinion, this is one of the most essential elements for increasing adaptability, as the teams are no longer limited by knowledge of a single functional area – instead, they explore PBIs together and develop higher-quality solutions.

Multi-team PBR also helped us anticipate potential blockers and dependencies before the work even started. This made it possible to plan actions that would help resolve these issues ahead of time or manage them more effectively during development. In practice, it improved overall team coordination.

Multi-team PBR facilitation

Under the conditions of the full-scale war in Ukraine, all teams work primarily online. Tools such as Miro, Mural and Confluence whiteboards help us create a shared virtual workspace for team collaboration.

A day before each PBR, we meet with the PO and PMs to review and update the backlog, and we prepare the virtual board for the upcoming session.

We start each PBR with the PO presenting the upcoming priorities,  explaining why they are important and which of them are most likely to enter the next Sprint. We briefly go through the PBIs to provide the teams with context. After that, the teams organize themselves into mixed groups and move to virtual breakout rooms to discuss the proposed PBIs. Usually, we divide into three groups. During the session, each group completes three rounds, rotating between rooms so that everyone has a chance to work with all PBIs.

At the end of the session, we finalize the results of the PBR and determine which PBIs are ready for planning and which still require additional work. For those not yet ready, the teams agree to refine them individually, either because they are interested in taking them into the next Sprint or because they want to explore them further and later share their findings with everyone.

The teams quickly began to see the value of PBR. At first, this format seemed complex to them, but now they want to understand as much of the broader product context as possible. It’s also important to note that PBR has shifted the focus from simply analyzing tasks assigned by managers to enabling teams to propose their own solutions to product problems. It is expanding organizational agility and domain knowledge among engineers.

Sprint Planning

We start with a short alignment session where the Product Owner, together with Product Managers, reviews the Product Backlog one more time to finalize expectations for the upcoming Sprint. At the same time, teams meet in their virtual rooms to synchronize and update their context. They review their boards, check if there’s any remaining work from the previous Sprint that could influence the next one and briefly revisit outcomes from the last retrospective to incorporate improvements into the new Sprint.

Next, we all come together for a joint session. Each team gives a short update on whether they still have unfinished work or if there’s anything that needs to be added to the planning scope. Then, the PO shares overall expectations for the Sprint and walks everyone through the backlog.

After that, teams split again to analyze the expectations and backlog items and to decide which work they want to take on. They mark potential items directly in the backlog. Once all teams have done this, we review the selections together to identify overlaps, for example, when two teams have marked the same item and agree on ownership. Each team then holds its own Sprint Planning session, where they define their Sprint Goal, create a plan and identify dependencies and interactions with other teams.

At the end, we come together again for a short Sprint summary, where we align on Sprint Goals, team scopes, open questions and then officially start the Sprint.

Story Points experiment

Over time, we decided to run an experiment with estimation. Previously, teams estimated work in hours. This approach caused a lot of frustration and it didn’t provide any real guarantee that tasks would be completed on time and it was almost impossible to predict how many productive hours each engineer would actually have during the Sprint. Most importantly, it reinforced an old pattern of individual estimation and task assignment, where work was distributed per person rather than owned by the team. Following old patterns also affected Sprint results. In the first few Sprints, teams still had unfinished work and often failed to achieve the Sprint Goal. I believed this was happening because the teams were not yet acting as a single unit and each person still held their own context and estimates around tasks and maintained an individual focus rather than a shared one.

I suggested trying Story Points instead. I know there’s a lot of criticism around this approach, but in our case, the reasoning was very specific. The goal wasn’t to measure velocity – it was to break the pattern of individual focus and to encourage shared team understanding of the work.

The hypothesis was simple: if teams start estimating together, they will communicate more, share knowledge and better understand how to achieve the Sprint Goal collectively. And that’s exactly what happened. Through Planning Poker, teams began to discuss implementation details, ask clarifying questions and uncover hidden assumptions.

I believe this is the true purpose of Story Points is not to measure precision, but to help teams talk, think and plan together to find the best possible solution.

If you face a similar situation or believe this approach could be useful in your context, be ready to sell the experiment to the team. My proposal was not just about changing the estimation technique, it was about solving a specific problem. I started by clearly explaining the goal of the experiment, the problem we wanted to address and my proposed decision – to try Story Points. Then I described what Story Points actually are, how they work and how we would implement them together.

This framing was important. When teams understand why a change is happening and what problem it solves, they are much more likely to engage, experiment and make the approach their own.

As a result, this experiment became one of the elements that helped us improve delivery stability. It wasn’t the Story Points themselves that made the difference, but the shared understanding, communication and team alignment they encouraged.

At the same time, I wouldn’t recommend using Story Points just because “Agile teams are supposed to estimate this way”. They are not a universal solution – their value depends on why and how you use them. In our case, Story Points worked because they solved a specific problem and helped the teams grow together, not because they were part of some agile rulebook.

Sprint Review

A major change for the organization was the introduction of the Sprint Review. Before the structural transformation, there was already something similar, it was called a Sprint Results Demonstration.

The mechanics were quite simple: managers prepared slides showing what they had planned for their teams, what had been released during the Sprint (which could include functionality started in earlier Sprints), and then, during the meeting, they presented this information slide by slide.

When I asked the questions, “Why aren’t the teams doing this?” and “What is the value of this meeting?” I received the following answers:

●      “Should the teams really be doing this? It’s the managers who manage the tasks.”

●      “To share progress on these tasks.”

There were no conclusions, feedback or discussions during this meeting. In fact, the manager simply reported on “their” tasks.

When it came time to prepare for the Sprint Review, the teams began asking why they needed to do it themselves. The main concerns among the teams were about preparation and presentation. It was clear that they were reluctant to invest their time and effort into it. They perceived it as additional work, something they hadn’t been responsible for before. For them, it felt like extra effort and new responsibility, because in their minds, this had always been the managerʼs job.

So, I decided to remind them once again of the purpose of the Sprint Review and to explain what the teams’ responsibility truly means. The purpose of the Sprint Review is to inspect the Sprint results and gather feedback on the created Increment in order to define further changes to the product. This event creates a shared context among all interested roles. The teams are the owners of the Increment because they are the ones who built it during the Sprint. Therefore, they should be the ones explaining and demonstrating it. Preparing for the Review also builds a sense of responsibility and self-organization – helping teams realize that they are not just executors but the true owners of the result.

According to this, the teams agreed with this experiment and took the responsibility for preparing the increment. We also agreed that the teams would prepare for it by themselves, deciding how they wanted to present and inspect the developed Increment and would be active participants in the discussions. Also, we aligned on the structure for the Sprint Review:

●      The Sprint Review begins with the PO giving an opening message, highlighting the main focus areas.

●      Next, the PO briefly reviews the key product metrics and provides short comments on their dynamics.

●      After that, the teams take the stage one by one. Each team talks about its Sprint goal and demonstrates how the new Increment works. At the end of each demonstration, the team leaves time for questions, feedback and discussion.

It might seem like nothing particularly significant had happened — the teams simply started taking an active part in the Sprint Review. But here are a few of my observations on how this change actually influenced the teams.

This change had a strong impact on setting clearer expectations. Now it was not the manager showing some results, it was the team that created the Increment within the Sprint and was responsible for it. This, in turn, influenced how teams began to perceive and relate to the Sprint outcome. There was now a clear Sprint Goal and clear expectations. This significantly increased the level of ownership and accountability. As a result, the teams started approaching PBR, Sprint Planning and the upcoming Increment much more consciously.

PO team dynamic

As I mentioned at previous parts, the system before changes had been built around the idea that Product Managers divided the product into separate areas and directions. Each PM was responsible for their own part and was expected to deliver results and report on progress. Consequently, they had their own individual goals that they wanted to achieve.

In practice, this prevented the product from evolving in a unified direction, as each PM was focused on pushing forward their own initiatives. Each manager was mainly interested in ensuring that their tasks were taken into development. As a result, planning meetings brought together component teams and managers. Each manager would present their tasks and, together with the Team Lead, decide which developer would take on which task and how many. In the end, every developer had a list of tasks for the next two weeks, and the manager coordinated their execution.

From the very beginning, during our training on organizational modeling, we explored the roles of the PO and PM, and how collaboration between the PO, PMs and Teams should work. The key idea that managers needed to accept was that they no longer had to push their own tasks into development or compete for resources. Their role remained important – they continued to support the PO in developing the product, but they were no longer responsible for coordinating teams or managing events. Most importantly, all future work now flowed through a single Product Backlog.

This created some difficulties at the beginning. Each manager still remained an expert in their specific part of the product and continued working within that area, preparing corresponding PBIs. Naturally, each of them wanted their items to be taken into development –  otherwise, they felt they were losing their sense of importance and contribution.

The PO was the one who made the final decision on where to invest the next Sprint’s effort. Not everyone liked this change, but we followed the principle of “job safety over role safety.” It was also important for them to understand that situations where a manager explored a direction and their findings were not immediately taken into discussion or included in the next Sprint were completely normal. We focused on what was important for the product, not on how many tasks a manager could prepare or plan for the team. However, not all managers fully accepted this new reality and over time, some decided to leave the company.

For those who stayed, there was a period when they felt somewhat disconnected from the teams. They were no longer facilitating team meetings, solving development issues, or coordinating daily work. However, this was the right direction for them – it allowed them to focus more on product research and development. The teams themselves began to approach the managers whenever they needed support or expertise.

Expanding engineering competencies

One of the most rewarding observations was how deeply engineers embraced the idea of sharing product knowledge and developing new competencies. A great example of this was the initiative to spread app testing expertise across teams. Due to several staffing changes, the number of dedicated testers was significantly reduced, which made this skill set critical. Our Engineering Manager, together with internal experts from the teams, designed a practical training course on testing. They developed a learning plan and, over several Sprints, conducted sessions to teach and mentor developers and other testers on the testing practices used within the company.

This initiative greatly helped to spread testing knowledge, reduce bottlenecks and strengthen the teams’ autonomy. And helped to support the quality of the product on the level. Now there is no fear or resistance to testing work – it’s no longer seen as “someone else’s responsibility”. Teams understand that quality is a shared responsibility and that mindset has become part of our culture.

This was a beautiful example of mature self-organization showing how a culture of shared responsibility and learning can spread organically across teams, without being enforced from outside.

Definition of Done

When it comes to the Definition of Done (DoD), we initially gave it little attention. We defined a basic version at the start, but over time teams began to follow it only partially. Such an attitude can easily lead to a gradual decline in quality, especially as the organization scales. A Sprint Increment must always meet the Definition of Done. If the DoD is unclear, incomplete, or inconsistently applied, it creates invisible debt: unfinished work, untested code and technical uncertainty that accumulates over time. Without a shared and enforced DoD, the meaning of “Done” becomes subjective and predictability and quality quickly erode.

Over time, we returned to review our DoD again. The engineers agreed that we needed to adhere to it consistently and improve it together. This led to new, clearer items that became mandatory for all teams. We are now working to ensure that every team has the capability to meet these standards so that each Sprint delivers a true, high-quality Increment.

As a result of this reflection, we created a plan that includes developing new skills within the teams. This clearly demonstrates how the Definition of Done directly drives development of engineers capabilities and continuous improvement.

I highly recommend establishing a clear Definition of Done. Define what activities it includes, how DoD can be measured and how the organization will support it Sprint by Sprint.

Results and Organizational Impact

In conclusion, I’d like to share some concrete results. Many people in the industry often ask – why are such organizational changes even necessary and what do they actually bring to the business? There’s a fair amount of skepticism in the market about these kinds of transformations.

And I didn’t want to answer with something abstract like: “It’s a complex systemic process with many influencing factors, but overall it’s a better way of working because it aligns the organization around a single source of work and puts the customer at the center.”Those words are true, but they still don’t answer the real question: did it actually make a difference?

I chose a few tools to evaluate the success of the changes: key metrics and the Org Topologies mapping.

The main metrics I tracked were Cycle Time, Throughput and Sprint Goal Completion Rate. These are simple indicators that help observe how the system is changing.

●      Cycle Time showed how quickly we could turn started work into usable outcomes.

●      Throughput helped us see the stability and predictability of delivery.

●      Sprint Goal Completion Rate reflected how well the teams understood priorities, planned their work and delivered on what they committed to.

These metrics were easy for everyone to understand and discuss, which made them a great entry point for learning and reflection. They also served as signals of whether our changes were really improving the system or just shifting the symptoms.

After seven months of operating in the new LeSS structure, the impact on key flow metrics was striking.

Cycle Time across all three teams decreased by around 80%, meaning Sprint Backlog items were completed roughly five times faster than before. This reflected the removal of systemic delays and smoother collaboration across the teams.

Throughput remained stable, even though Work in Progress was reduced by approximately 60%. Previously, teams tended to start more work than they could complete, which led to interruptions, dependencies and items getting stuck in progress. With the new structure, teams focused sharply on their Sprint Goals and committed only to the amount of work they could realistically complete to achieve those goals. This resulted in a much more stable and predictable flow of work.

As a result, Sprint Goal achievement rose from around 40% to over 90%, demonstrating stronger alignment between planning, execution, and outcomes – a clear indicator of improved system coherence and team maturity.

These outcomes were not merely the result of improved metrics. By simplifying the structure, reducing handovers and fostering true cross-team collaboration, the organization created conditions for faster learning and more consistent delivery of value. This systemic improvement also translated into financial impact. In this case the organizational changes did not have a negative impact on financial performance, as is often feared.

Observing New Org Design

The second important insight emerged when I looked at the new structure through the lens of Org Topologies. As described earlier in the Designing the Future Organization section, the LeSS structure was meant to help the organization become more adaptive. From an Org Topologies perspective, such a structure ideally sits in the top-right quadrant. That was our target state.

So what did we actually achieve? We ended up with three cross-functional, cross-component feature teams capable of taking any item from the Product Backlog and delivering it to “Done.” In principle, this meant that each team could work across the whole product. Product Managers acted as subject-matter experts, supporting the Product Owner in shaping the product strategy and aligning the backlog with business goals. Structurally, this seemed like a good step toward adaptiveness.

However, I made a significant mistake during the team design phase. While focusing on building end-to-end feature teams, I concentrated mostly on engineering capabilities: backend, frontend, mobile, QA, and didn’t fully consider non-engineering but critical competencies, such as design and analytics.

Design and analytics were essential to our product development process, yet they remained outside the teams – organized as separate functional departments, each with their own leads and allocation model. These departments provided their services to teams but were not part of them. At first, this seemed acceptable: teams could pick any backlog item and deliver it end-to-end as long as the design and analytics work had already been done. But this dependency became more visible over time.

From the Org Topologies perspective, this revealed a clear misalignment between intent and reality. The teams had indeed moved up the vertical axis – their scope of work expanded to cover the whole product. But horizontally, their scope of skills was still incomplete. They were multi-skilled, but not truly end-to-end. Missing design and analytics capabilities meant that teams couldn’t independently close the full loop of problem discovery, solution definition and delivery.

As a result, the organization unintentionally remained in a Resource Topology. Despite having feature teams, the flow of value was still dependent on centralized design and analytics functions. The teams’ behavior reflected this dependency: instead of continuously discovering and solving product problems, they focused on delivering the highest-priority items that already had design and analytical input. When that input wasn’t ready, teams couldn’t start the work – which in turn affected flow and planning. The Org Topologies assessment made this visible. It showed that even with substantial effort and structural redesign, we had reached only partial adaptiveness.

This realization was eye-opening and valuable. It showed that organizational adaptiveness is not achieved merely by forming cross-functional engineer competencies. It requires integrating all critical skills into the system of value delivery. Engineering alone cannot ensure adaptiveness if discovery, design and analytics remain external. Org Topologies helped visualize this gap and turn it into a clear direction for the next evolution step: expanding team capabilities to cover the full product cycle, from insight to impact.

Reflection

In this part, I share some reflections and key lessons from this transformation experience.

Engagement of top management shapes how the entire system perceives change.

Executives must be present, participate in discussions, attend training sessions and clearly explain, from a business perspective, why the transformation matters and which problems it aims to solve. Their active involvement sends a strong signal across the organization: this is not another local optimization, but a strategic shift in how the company operates and creates value. Leadership participation builds trust, aligns intent with action, and helps the organization see the change as meaningful and long-term. So, top management has to be in the center of these changes.

You must have a mandate for change

Any transformation requires a clear and legitimate mandate for change. Without it, even well-intentioned efforts quickly meet resistance, as existing structures and incentives naturally protect the status quo. A strong mandate creates the necessary space for experimentation, enables decision-making without constant escalation and provides the psychological safety for people to challenge established ways of working.

Organizational Design Is More Than Delivery

According to the Galbraith Star Model, organizational design is built around the alignment of five elements: strategy, structure, processes, people and rewards. Strategy is a core input for shaping the organization.

Reflecting on this experience, I realized that structure and processes cannot evolve in isolation. Even with adaptive teams, stable delivery and growing revenue, success is not guaranteed if the product strategy and decision-making practices remain weak.

It is important to keep it consistent. Product strategy and feedback loop are the most important parts of product development. It’s crucial to avoid a situation where any initiative can slip into the backlog simply because someone wants it. There has to be a clear filter that evaluates how each initiative aligns with the strategy and contributes to the product goals.

That’s why the product dimension of the organization must evolve as well, including how we define and work with product strategy, make data-driven decisions, validate hypotheses and strengthen the overall product mindset. The focus should be on the whole system, not only on the delivery part.

Before starting organizational design changes, it’s worth running several sessions to align on the product strategy, analyze how decisions are made and how hypotheses are validated. Such discussions can expand awareness, improve preparation for the “flip” and help identify missing capabilities in product research and validation practices.

This reflection led me to an important realization: preparing for transformation means not only getting engineers and teams ready, but also developing the product side of the organization, helping product managers and leaders learn how to explore, test and make product decisions in new ways, and enabling engineering teams to contribute to this process as equal partners.

Track Product Metrics

Organizational design should ultimately help the company achieve its product goals, not only improve internal efficiency. That’s why it’s important to track how structural and process changes affect the key product indicators. Connecting organizational changes to product metrics helps ensure that transformation delivers not just better delivery, but real business impact.

 

Be Confident

One of the most important lessons I learned is to stay confident. When facilitating a transformation of this scale, the whole system will often push back, especially at the beginning. Not everyone shares the same understanding of why change is needed; some people will resist it and a few may even try to actively sabotage it.

If you start doubting yourself, compromising on principles or skipping essential parts of the LeSS preparation process, it’s unlikely you’ll be able to bring real value to the organization. Such compromises often lead to mistakes that will have to be fixed later.

If you keep old roles, processes or structures “just for now,” be sure that you’re also scaling old problems into the new organization. Confidence in principles and clarity of intent are what allow the transformation to stay meaningful and effective.

 

Design the System, Then Follow It

Follow the conditions of the system you create. When transitioning to LeSS or any other adaptive model, elements of the old structure will remain. These remnants of the previous system can silently undermine new principles if allowed to dictate the rules.

It is therefore crucial to continuously identify and eliminate contradictions, aligning the organization with the principles of the new design. LeSS is not just Scrum at scale; it is an organizational transformation that demands systems thinking and ongoing adaptation.

Only when all elements – strategy, structure, people, processes and culture operate in harmony with the new model does the system truly come to life and begin delivering real value.