A full-fledged detailed LeSS case study of Poster POS Inc. that happened in times of COVID-19 and the war.
Part 1: "Org Before Change"
Preamble (by Candlelight)
About Poster And This Case Study
Scope Of This Case Study
Inspiration and Appreciation
Company and Business Context
COVID-19 and Remote Work
Product Development Before LeSS
Component Development before LeSS
Product Owners at Team Level
OKRs and Contract Game
High Defect Rate
Internal Product Complexity
Engineering Practices
Product Stabilization Period
Quality of User Experience
Overall Development Capacity
Quotes from Employees
Preamble (by Candlelight)
December 2022 in Dnipro, Ukraine. The employees of Poster POS Inc are gathered to celebrate the company's 9th anniversary of “simplifying business management” - that’s how they call their mission. The event is held by candlelight because due to recent (and often) shelling by the Russian forces, the blackouts have intensified.
Among many other things, Poster’s CEO, Rodion Yeroshek, is sharing some data insights. And it is unbelievable. Only during the first week of November during the wartimes Poster managed to onboard 100 new restaurants in Ukraine:
That’s what true resilience is. Everyone is proud and sure of the victory on both fronts: the business and the real one. Looking back: the whole year of 2022 was challenging. On March 1 (a week after the full-fledged Russian invasion) Poster blocked the accounts of 10,000 Russian taxpaying businesses, losing 50% of its B2B clients:
2022 had more dark moments: Poster lost its profitability for several months, and being self-funded it had to lay off some people. And to increase adaptability in the face of extremely high uncertainty and an unclear future the remaining five feature teams switched to one-week Sprints.
It has been almost a year since I, Alexey Krivitsky, stopped actively supporting Poster in their LeSS adoption journey. As an org consultant I spent more than six months with Poster, its teams, and management, helping them embark on the journey of deep change, owning it and making significant reorganization. That change observed by me is the scope of this case study.
And now it is a year since we had parted ways and I am learning about their recent experiments and improvements. To me the rate of the systemic improvements they’ve done is unprecedented:
It is common to see the teams working together sharing high-value work. And sometimes the team boundaries are not clear. In fact, right after the LeSS Flip during the first LeSS Sprints described below all the teams were able to work on the critical set of related product changes together. For comparison, before the LeSS adoptions each team had had its own set of local priorities within their narrow scope of work (a component or a subsystem). Back then it was impossible to make sure all the teams focus on high-priority work all the time. That inability of the organization to deliver value and stay flexible was one of the key driving factors for the change described in this case study.
It became normal to see customers (restaurant owners and employees) on regular Multi-team Product Backlog Refinement sessions (PBR) and Sprint Reviews. During these workshops participants grew a shared understanding of customer needs and product changes by creating user story maps on the spot with developers and users in face-to-face conversation. For comparison: a year ago inviting a customer to such sessions was just unimaginable due to the high technical “how” focus of the meetings rather than a customer-requirements “what” focus. And 1.5 years previous such meetings hadn’t existed at all as there were no feature teams and shared multi-team work had been barely and rarely possible.
Recently, the teams started to run separate multi-team design sessions (“how” workshops); that contributed to making the PBRs 100% customer-centric and problem-focused “what” workshops. For comparison, a year ago, PBRs were confusing due to mixing the problem and solution contexts.
Systemic shared work on quality has resulted in that now, not more than 20% of teams’ overall capacity is spent regularly on customer support duty (compared to 50% a year ago).
Many, if not all, features are developed with built-in feature flags that can be controlled remotely (a year ago, that was only a dream of several people). This results in an ability of staged roll-out of features whose impact/usage metrics are being observed by the teams.
The core parts of the product are constantly collecting data from user behavior that can be analyzed in real-time, and custom dashboards can be configured when needed. A year ago, data collection was ad-hoc and most product changes were made without a way to measure their real impact.
And many more systemic changes.
It is hard to believe that only 1.5 years ago (before the summer of 2021), all the Poster teams were component-oriented and narrowly specializing with dedicated team-level backlogs and backlog owners per team. Back then, Scrum was seen as a team-level method with all the resulting dynamics.
So, how did it happen? What has created that wave of change?
This case study is a detailed story that highlights the key events and insights that led to the creation of the new organizational system at Poster. In this new system, there is a strong focus on the whole product, where constant systemic improvements are the norm. As a result of these deep organizational changes, the overall organizational adaptivity and resilience has drastically increased. This can be witnessed by the business success of Poster even during wartime.
About Poster And This Case Study
About Poster And This Case Study
Scope Of This Case Study
This case describes a journey of a Ukrainian-based SaaS company Poster POS Inc striving for global optimization in product development with Large-Scale Scrum (LeSS).
The change process started around May 2021 with the C-level team attending an online Certified LeSS Basics (CLB) class and accepting the principal LeSS ideas: a single Product Backlog being learned about and worked on during a common Sprint by all cross-functional cross-component long-lived customer-facing teams – for high adaptability towards constantly changing business environment. In June 2021, they made a strategic decision to adopt these principles in the R&D department of the company. My engagement as an Organizational Consultant / LeSS Coach / Scrum Master lasted from May 2021 to January 2022 and is the scope of this case study.
This case study focuses on the following aspects of the LeSS journey:
Preparations for LeSS Adoption and LeSS Flip Event These chapters will describe the driving factors behind the adoption of LeSS, and the process we followed to restructure and prepare for the first Sprint
Observed changes during the first 20 LeSS Sprints Our key experiments, struggles, and wins presented in the most open and frank manner possible.
Remote work and LeSS The challenges and workarounds in adopting high-bandwidth inter-team collaboration in a 90%-remote working environment due to COVID-19 pandemics.
Expansion to the Definition of Done As an essential measure of the company’s progress towards perfection.
Inspiration and Appreciation
This case wouldn’t have been possible without my mentors and friends of the way. Special thanks to Viktor Grgic being my mentor in writing this case study.
I’d like to thank the entire LeSS Community (and, of course, the Candidate LeSS Trainers discussion group) for raising our bar for real change.
Company and Business Context
Poster POS Inc. is a cloud-based SaaS automation for small-to-midsize businesses in the hospitality industry, also known as HoReCa (Hotels-Restaurant-Catering).
The company was founded about 9 years ago (as of writing this case in 2022). It was started in Ukraine as a pivot from another business in the domain of the discount marketplace. The story goes that while integrating discount handling with different restaurant management software, the Poster founders-to-be realized how badly the restaurant domain was automated. They decided to pivot and enter the niche: automation of the end-to-end lifecycle of restaurant businesses.
The small- to medium-sized companies operating in the HoReCa niche provide a big opportunity for automation services, especially in developing countries, like Eastern Europe and Latin America. This is true for several reasons. Firstly, small cafés are looking for effective and easy-to-use, plug-n-play solutions to automate their customer service and the back-office processes. Secondly, in the developing marketing, where the government is constantly fighting with tax avoidance, there is a lot of constant development in the field of fiscal legislation. And this flow of changes is bringing in a steady burden and overhead for the businesses. As an example, sending just-in-time digital receipts to the tax authority for every client transaction (digital fiscalization) became mandatory in Ukraine in 2020. That has resulted in a large demand for modern, easy-to-use digital solutions (in contrast to the old hardware registers that can be seen in supermarkets).
Yet, fiscalization is just one of many processes made easy for businesses by Poster. The vision of Poster is “simplification with automation” of the entire set of business processes (in the HoReCa niche, for a start), so they can be “administrated from a pocket”. More on this – in the Defining the Product chapter below.
In 2021 (right before I joined) the company had just survived numerous COVID-related lockdowns on its main markets and had 190 employees with around 50-people in product development. The company has surpassed 20’000 B2B customers (making it a ratio of roughly 90 customers per employee) and with over 1.2 Million restaurant checks processed per day.
COVID-19 and Remote Work
The location of the Poster’s head office is in the beautiful city of Dnepr in the southeastern part of Ukraine. Throughout the company’s history, they were hiring only in the head office. But during the pandemic, they changed the model and started to hire remotely as well. So by summer 2021, there were already several developers who had been hired to work remotely and who have never met their colleagues face-to-face. And that was the direction the company was heading to – a so-called hybrid mode. A mix of on-site and remote work.
Looking back at this decision: those remote employees were the first ones to be laid off, when the company faced a temporary crisis due to the war in 2022. Doesn’t that illustrate how loose the human connections are between the people when they don’t work face-to-face?
Already back in 2021 as of the start of the LeSS adoption, the hybrid mode of work was already bringing challenges. But due to the lockdowns and the urgent need for change, the preparation, the LeSS flip, and the first Sprints could not be done fully onside. More on the challenges of remote work in the case study: Colocated, Remote or Mixed Teams and Remote Meetings and Multi-Team PBRs.
Product Development Before LeSS
The following chapters describe the company’s work mode before the introduction of LeSS and the key driving factors for the change.
Component Development before LeSS
Before LeSS at Poster, six to ten teams were operating at the level of components and subsystems. They varied in size from 2 to 12 people based on the size and complexity of components they worked on. Sometimes, as a reaction to some urgent business needs, temporary project teams were formed.
Some examples of the teams before adopting LeSS:
A team for a restaurant-check-printers subsystem taking care of the hardware- and firmware-related aspects of fiscalization (producing and printing fiscal checks)
A team for a restaurant-stock-handling subsystem enabling business administrators to manage the stock and their supply chain
A team for a website constructor, allowing clients to create their white-labeled websites with online menus
And other specialized teams with a similar relatively narrow focus
Being a developer in one of such teams, you typically work in one or several git repositories, treating that piece of code as your teams’ codebase. Overall, there were over 40 different repositories owned and maintained by different teams.
During my first encounter with the teams at Poster, I considered them to be pure component teams. Later, after learning more, I have figured that some of them were somewhat more advanced in terms of the Feature Team Adoption map (see below). While some teams were purely built around a single component, others were capable of building specific customer requirements within the product subsystems (e.g. adding a QR code to a check, changing the way taxes get calculated for alcohol drinks, etc.).
As the illustration above depicts, before the LeSS adoption, the teams worked within a given subsystem/component (the vertical axe) such as fiscal operations, point of sale, website constructor, etc.
That work (on the horizontal axe) included activities from analysis to design, coding, and component/subsystem testing. Test engineers, who were spread across the teams, occasionally got together to perform product-wide system testing. There were no separate testing or architect groups. But there was also a single visual designer and a technical writer “shared” by all the teams when needed. An independent two-person ops-team was also there, taking care of the cloud infrastructure.
The teams, in most cases, solely owned code repositories and possessed limited domain knowledge. Due to the modular system architecture, often, the subsystems could be released independently of each other. Isolation of the teams over time resulted in various languages, frameworks, automation styles, branch practices, and release tactics used applied at the level of a specific code repository.
Those painful differences and unnecessary added complexity became obvious once the cross-component features teams started to work across different code repositories during the LeSS Sprints. Those conflicts drove the technical improvements, standardization and simplification. See Engineering Community and Pull for Engineering Practices.
Product Owners at Team Level
Historically at Poster, Scrum had mistakenly been seen as a team-level framework, so most of the teams before the LeSS adoption had its team-level Product Backlog and a team-level Product Owner.
To avoid any confusion with the (real, scaled LeSS) Product Owner for the entire Product, in this case study the role of the team-level Product Owner will be referred to as a “Team Output Owner” (or TOO for short):
The TOO role is inspired by a widely spread in the industry. At scale, this leads to teams who in fact work on the same product pulling work off different priority lists, having their own focus and narrow scope of ownership. This inevitably results in suboptimal results at the scope of the whole product, such as duplicate code, bad user experience, lack of learning, etc. This is the opposite of what we are aiming for in LeSS being Scrum applied at the product level, with multiple teams striving for global optimization.
Scrum’s original idea of product centricity (via a single Product Owner and a holistic Product Backlog for the entire product) is diminished by an organizational design with TOOs. Such an organization breaks down into silos – organizational pockets each working off their locally prioritized team backlogs. In such a fragmented organization due to decreased transparency and high information scatter, it becomes hard to see the bigger picture and make decisions that optimize global concerns. Lacking a broader understanding of the product, busy-ness and the velocity of individual teams become key metrics that drive the fragmentation and segregation in the company further and more. With time and size, the barriers between the teams grow higher, increasing misalignment and the need for inter-team coordination. That coordination gap typically can’t be filled in by teams themselves (due to a lack of understanding of global concerns and lack of global focus) so external-to-team managers-coordinators are introduced to manager inter-team interactions.
Eventually, because of the forementioned dynamics, organizations that apply Scrum at team-level tend to get more complex and slow, diving into a vicious cycle of adding even more roles to deal with the surfaced problems. But one negative dynamics triggers another and another way, eventually creating a very complex net of causes and effects. The next chapters highlight some particularly important ones that were affecting Poster, still being a relatively young and small company.
OKRs and Contract Game
Poster is a company of unique inner culture, a great spirit. But despite everyone’s wish to work closer together, ostensibly some invisible forces were pulling the teams away from each other.
Educating everyone is the first recommended step in a LeSS adoption. And over the course of several months of preparing for the LeSS Flip, it became apparent to many team members and managers during the numerous trainings, workshops and informal discussion, why the teams were unable to work jointly together on customer features and why their workload was unbalanced, causing bottlenecks and waiting.
People behave the way the system allows them to, and the org structure and processes at Poster before LeSS didn’t allow for tighter inter-team collaboration. Due to narrow product knowledge and different focuses, the isolation of teams only grew over time. Each team was busy working off locally prioritized backlogs, but while everyone was doing the best they could, the overall product development system of the company showed the quality of being slow: slow at delivering customer value and slow at reacting to the changed needs of the markets.
As a result, occasionally, the management had to form temporary project groups by pulling developers out of their teams. That was the only applicable method at hand to react to some urgent changes that none of the teams were capable of solving alone. Interestingly, it was also fun to be a part of those temporary initiatives, as you could feel the importance of what you were doing and could really make an impact! Later, after changing the system and adapting the LeSS ideas of a single Product Backlog and feature teams, all the teams could feel the same, all the time. But before that, in the component teams' era of Poster, periodic reorganizations were one of the key management tools helping to address some market emergencies.
One can conclude that the pre-LeSS product development system at Poster was not optimized for shared Product Ownership. No one but the CEO saw the bigger picture, as everyone else was focusing only on a small part of it.
To compensate for that, the CEO of Poster used top-down objectives to help organization focus on what was really valuable and important. Those objectives then were taken into the consideration by the TOOs when creating and re-ordering items of their teams’ backlogs.
Although the OKR technique, in theory, can drive positive dynamics of transparency and collaboration, I was observing how it contributed to the issue of lack of ownership and exerted pressure onto the teams that were already stressed.
The following diagram describes the part of this dynamics: how Scrum applied at the team level, introduction of team-level backlogs and owners negatively contribute to shared Product Ownership. And how this makes management unwillingly fall back onto the “proven” methods of top-down decisions, pushed down deadlines and control - the only methods that seem to somehow work in such a disintegrated system of local concerns.
Poster had quarterly product planning cycles driven by OKRs. From the systems thinking perspective, such a process add-on is a quick-fix aiming to minimize the negative tendencies of local optimization individual teams working off their backlogs. And despite some positive aspects of increasing clarity on the company’s high-level ambitions and goals, OKRs, in my observation, make product management much less direct.
OKR method re-introduces the “management by objective” (the 11th out of the 14 points of Dr. Deming was to eliminate it, see References). Using OKRs contributes to replacing feedback-driven and incremental development with big ambitions and quarterly deadlines.
At Poster, the objectives of some OKRs were set as pure goals and the teams had to come up with key results as specific product changes. Other objectives were formulated as scope rather than goals. But in any case, once the key results are formulated and set, they all tend to be seen by the teams as fixed scope. And then the monthly and quarterly OKR reviews drive the fixed time aspect of it.
Management via fixed-scope & fixed-time projects (no matter the modern terminology) in software development has a strong negative effect on the product quality. And it also contributes to creating an internal contract game where the business orders work from the R&D, as per the cause-effect diagram above.
See the next chapters for more analysis on the quality aspects of product development at Poster before LeSS.
High Defect Rate
I was told that historically, the company has been having a relatively high rate of product defects, and it has been eating up a significant portion of the development capacity. When talking to the developers and managers about that, I heard numerous (superficial) explanations for that. For instance: many people correlated the high defect rat with the high complexity of the product domain. Following this logic, the defect rate in even more complex domains (i.e. rocket science) is skyrocketing no matter the intellectual efforts of putting it down?
Indeed, the product domain of HoReCa is relatively complex due to the number of external endpoints and various business rules: the tax department, external accounting systems, etc. But such a plausible correlation (low product quality to complexity of the domain) isn’t actionable: it serves as a mere excuse and offers no improvement direction.
Some people at Poster communicated another explanation for the high defect rate: “at Poster, we are trying to provide the best possible customer experience, so we are reacting to all kinds of client issues, thus having to spend a lot of time on them”, they said. Yes, Poster, like any other young and self-funded company, is heavily dependent on the satisfaction rate of its clients – a prerequisite for product-led growth and long-term success. But again, it doesn’t drive the improvement thinking.
Of course, it is unlikely that there is a simple explanation of why the defect rate was that high, for otherwise, the company would have already resolved that issue. But what’s more insightful than looking for simple explanations is to try to understand the system dynamics.
What was causing the defect rate?
Was the defect rate growing or decreasing over time?
Was there any seasonality in the data?
Were some delayed effects that contributed to the issue and were naturally hard to spot?
Were there any vicious cycles (reinforcing loops), that were making the things worse over time?
Were there any structural organizational elements in place that made the engineers exhibit some detrimental behaviors and ignore the quality problems?
The following chapters cut through the complexity of the matter by highlighting key aspects of the system’s dynamics at play.
Internal Product Complexity
Developers under pressure are prone to look for easier and quicker solutions. The following diagram below depicts these dynamics:
The above-described “contract game” (caused by the OKR review cycles) created pressure on the development teams with fixed-scoped thinking. Being under pressure, developers tend to cut corners, think more short-term - skip applying well-known engineering practices that make things easier over time for saving time now to meet the looming deadline.
Eventually, those small, mostly invisible actions will accumulate and increase complexity of codebase over time. Eventually having a delayed negative impact on the overall development speed (aka feature velocity) and hence worsening the ability of the R&D to meet the deadlines.
Such a dynamic describes a reinforcing loop (a vicious cycle) where over time the pressure on the developers will contribute to slower speed that in its turn will also make the pressure grow. Furthermore, the ever-growing product complexity and rushing results in developers making more mistakes (even when applying the “fast and quick” changes).
These and other factors lead to deterioration of the overall production system. As a result, Poster, having less than a 10-years old codebase, was constantly spending around 50% of its development capacity on critical product maintenance instead of adding value to the customers.
Engineering Practices
There is a common belief in the industry that teams with narrow code ownership (e.g. owning components or microservices) will take a good care of their code better. In theory, this is plausible, as owning something often results in taking care of it.
However, as observed in software development organizations, component teams tend to produce low-quality software. This is counter-intuitive for many managers who advocate for component team organizations. One observed reason is that component teams typically have low-quality standards. This happens because they are not getting familiar with other parts of the codebase (owned by other component teams), hence having a lack of references to higher coding standards and good engineering practices. That was also the case as Poster. Different teams used different approaches to designing, coding, testing and deploying their pieces of the system. The spread of good practices was impeded by narrow code ownership practices.
To make things worse: as component teams keep working on the same portion of code for a long time, they have a good understanding of it, can remember what it does, and hence are less likely to work on improving its comprehensibility and maintainability.
This dynamic of component team organizations makes systemic, long-lasting improvements to the overall codebase less likely, despite the good will and the efforts of the management to create a high engineering culture.
The following expansion of the cause-effect diagram depicts how component teams contribute to the ever-growing complexity of the product.
Product Stabilization Period
At the beginning of the summer of 2021 (a few months before the LeSS adoption) Poster management decided it was time to pause adding more features and focus on stabilizing the product. A high-level goal and a metric was to bring down the number of product defects. Indeed, if teams’ velocity keeps dropping, running a company-wide product stabilization initiative sounds promising.
For around six weeks, all teams paused any feature development and tried to close as many major sources of defects as possible. After those weeks, the flow of defects improved slightly. Some root causes of major bugs were found and eliminated, some portions of code were rewritten, critical auto-tests were added. Yet, the bug flow remained high, causing a lot of development capacity to be wasted on bug fixing. There is no shortcut in recovering from low quality.
Although product stabilization periods increase product quality, they cannot be seen as systemic improvements as they don’t change the habits and the overall dynamics. On the diagram above, the relationship of the variable “frequency and duration of stabilization periods” to the “internal product complexity” is marked with a “QF” notation, meaning a quick fix, something that works but doesn’t change the system.
An “interesting” unexpected side effect of the introduction of product stabilization periods, where feature development is paused, is that they reinforce the “feature hunger”. The pressure exerted onto the teams is likely to go up on once they resume working on the customer features, thus reinforcing the same negative practices that had created the need for the stabilization in the first place.
The later chapters of this case study describe how the structural changes (within the LeSS adoption) systematically improved this situation.
Quality of User Experience
But it was not just the internal product complexity and the rate of defects that were eating up teams’ capacity. When the teams are rushed, they don’t just produce worse code, they also make worse decisions, that affect the easiness of using the product - the user experience. As the result, the customers misunderstand, misconfigure and misuse the product features, and then ask for help. In its turn, a high flow of customer issues and feedback adds more load onto the customer support and then onto the R&D teams, eating up their capacity even more.
One particular related observation at Poster was that many product features, once shipped, have never been significantly improved afterward. Thus staying forever in what I call an “MVP-limbo-state”, offering minimalistic and unoptimized solutions to customer needs.
Such a dynamic is not uncommon in the industry. It can be seen in so many places that the rather positive term “MVP” (coined by the Lean Startup movement) has a very much negative connotation these days.
So, what is preventing a product development organization from continuously improving its key asset – its product, based on customer feedback?
Let’s recap the dynamics that we’ve analyzed so far:
Because the rate of introducing new features is low and the appetite for new features is high (see the diagrams above), the product management creates ambitious product development plans (feature roadmaps). Those plans are then pushed them down onto the team-level Product Owners (TOOs) and teams.
Because of the lack of decision-making power of the TOOs, they have no choice but to execute the received plans and respect the given deadlines (usually guided by quarterly/yearly set objectives).
This results in a dynamics known as a “contract game” – where business orders work from the R&D with fixed scope and deadline.
Therefore, the TOOs and the teams find themselves in a constant rush to build and ship new functionality to satisfy the “contract”.
The cause-effect diagrams above illustrate how such pressure makes developers cut corners, lower their engineering standards, and eventually worsen the codebase (increasing internal product complexity).
Periodically run “stabilization Sprints” don’t change the overall dynamics and the internal product complexity increases, making development slower and harder over time.
And there is another aspect to this dynamics - it is not just the internal product complexity that is growing. The rush to push more features faster also makes TOOs and teams start working on the next things sooner, without having the time to receive, digest and properly react to the customer feedback.
An example:
Once an MVP of a feature (F1) is shipped, a team shifts to the next thing on their list (F2).
When customer feedback on F1 is coming in, the teams are already in the middle of building something new.
Therefore, that valuable customer feedback on F1 is seen more as a distraction, loss of focus and damage to the roadmap.
Some pieces of the feedback cannot be postponed and requires immediate team’s interventions for fixing.
Other pieces of the feedback that can be postponed got collected and stored for later, typically as new Product Backlog items (F1 v2).
This impedes the ability of an organization to constantly improve its product.
And the habit of shipping half-baked solutions gets into the company’s DNA.
An internal side effect: an ever-overgrowing Product Backlog with “F1 v2”, “F2 v2”, … that is getting harder and harder to manage.
An external side effect: customers unsatisfied with the perceived quality of the product (user experience), they complain, increase load on the product support & teams, lose loyalty and eventually look for other solutions.
Despite everyone being busy working, the pressure to ship more features and improve the product quality grows, making developers rush, cut corners or put in overtime.
The cause-affect diagram below depicts the core aspect of this dynamics.
Overall Development Capacity
Because of all the listed factors and dynamics, by the time of the LeSS Flip at Poster, around 50% of development capacity had to be spent on product support – fixing customer-facing and internal product issues.
See the entire cause-effect diagram below:
Quotes from Employees
Below (and throughout the case study) are quotes from team members and management representatives on the situation at Poster before LeSS.
Alexander Hohol, a full-stack developer says:
In Poster, cross-functional teams are formed around the parts of the product. For example, I work in a team that is engaged in the internal structure of our point of sale. We never work on other features, but only on the things within our field of ownership and expertise.
Yuliia Kastierova, a QA engineer says:
When one of the QA engineers goes on holiday, the other QA people have a slight fear of not being able to help that team due to the lack of knowledge in a given component. Quite often, it is necessary to postpone product releases until the tester, an expert in the desired topic, is available again.
ILLIA Kovalchuk, Head of Engineering says:
In order to start working on something new that was requested by the business, it was necessary to create a dedicated team for that sole purpose. During the lockdown of 2020, we had to pull 6 out of 45 engineers to be able to start solving the things that the company’s survival depended on. That was not sustainable.
End of Part 1.