The Infinite Loop Part II: The Solution

Creating a culture of trust, ownership, and data-driven continuous experimentation that fosters sustainable growth and high-performance digital product teams. #

In Part I, I explored some of the most popular software development methodologies (SDM) to explain why they often fail to improve our outcomes. In Part II, I will focus on The Infinite Loop, a new but not revolutionary (on purpose) SDM.

Note: This is going to be a long post! Please note that if you don’t have time (or don’t fancy) to read this much, the contents of this post are also available as a more concise slide deck.

4. How do we fix this? #

The following list contains some of the main actions I believe we must take to solve the problems described in PART I.

4.1 Sounds good but doesn’t work #

Trying to convince your organisation’s management team to do things such as eliminating estimates and deadlines may seem out of touch with reality. My problem with this reaction is that I have experienced first-hand what it is like to work under these principles.

4.1.1 True leadership #

While I was a Microsoft MVP, I had the honour to spend a little bit of time with Anders Hejlsberg, Daniel Rosenwasser and other members of their team. I witnessed what happens when a product team tick all the boxes: True leadership, trust, clear goals and strategy, product-led, customer-centric, pragmatic engineering approach that sees technology as a tool, not a goal. The key realisation I had while observing the TypeScript team at work was that having a clear mission, vision, and strategy was extremely powerful, so powerful that as long as you had it, you almost didn’t need any project management overhead. All the members of the team were aligned like a high-precision laser. It was made up of missionaries, not mercenaries. This level of alignment is rare and is only achievable by true leadership. I also witnessed master levels of customer-centric and balancing technical debt with delivering customer value.

To be 100% fair, I must disclose that the TypeScript team operates under a Scrum-like methodology and have a quarterly release cadence. However, their version of Scrum was supercharged by the best parts of Lean UX, DevOps and product-led growth. The team performs nightly beta releases, high amounts of user research, and direct conversations with customers. The team also has a quarterly release cadence, but it didn’t feel like a deadline because, by the time the release date was reached, the team had already mitigated 99.99999% of all potential risks.

4.1.2 Open-source #

My open-source project (InversifyJS) had the following characteristics:

The preceding should not be a surprise, as this is how most open-source projects operate.

While working on InversifyJS, I experimented with the power of some of these ideas first-hand:

Today InversifyJS has over 100M downloads on npm and seeing my customer’s delight was the most fulfilling professional experience of my career to date. At that point, I realised how much we miss when we are not part of a high-performance team.

Being part of a high-performance team doesn’t mean being in a group under a lot of pressure; it means being in a team that is highly motivated to achieve a goal as a team. It means being part of a winning team. Being part of a winning team can feel very good. Winning can bring a sense of accomplishment, pride, and a positive self-image. It can also boost morale and increase motivation as team members work together towards a common goal. In a winning team, everyone’s contributions are valued, and everyone feels a sense of ownership and responsibility for the team’s success. This can lead to a strong sense of unity and a shared sense of purpose. Being part of a winning team can have a positive impact on an individual’s well-being and can help to foster a sense of community and belonging.

I dream that one day the entire software industry will get a chance to experience this feeling, and I believe that we can make it happen. Now the choice is yours:


“You take the blue pill, the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill, you stay in wonderland, and I show you how deep the rabbit hole goes.” - Morpheus

5. The infinite loop #

The Infinite Loop doesn’t try to reinvent the wheel; for the most part, it simply takes elements from other methodologies and software development principles.

The infinite loop

The Infinite Loop proposes the creation of product-led teams that use a pull-based system and two backlogs with a focus on different but equally important objectives:

5.1 Why infinite? #

The word “infinite” is used in The Infinite Loop to reinforce the idea that developing digital products is an infinite game. Developing a successful digital product is considered an infinite game because it is never truly “won.” The goal of an infinite game is to keep the game going, with no clear endpoint and dynamic rules. This is in contrast to finite games, where the objective is to win and there is a clear endpoint with set rules.

In finite games, the focus is on winning, and this can lead to a weak sense of purpose. Organisations and individuals who play to win at all costs may sacrifice their values and relationships in the process, ultimately losing the game. This can lead to a culture of fear, where employees feel pressure to meet targets and achieve results, often resulting in burnout, low morale, and high turnover.

In infinite games, the focus is on maintaining the game and continuing to progress. There is a strong sense of purpose, and leaders inspire others to join them on a journey of unknown and infinite possibilities. A culture of trust and ownership, and a sense of shared purpose, is critical for achieving ambitious and long-term goals.

Treating the development of a digital product as a finite game is not possible in the long run because there is no clear endpoint and the rules are constantly changing. The focus on winning would eventually lead to burnout and a loss of purpose, ultimately hindering the success of the product. A more sustainable approach is to view the development of a digital product as an infinite game and focus on maintaining progress and continuously adapting to changes in the market.

5.2 A side note about the “Zone” #

One of the goals of L∞P is to encourage the creation of work environments that facilitate a flow state. A flow state, also known as being in the zone, is a highly productive state of mind where a person loses track of time and is entirely focused on their work. This state is considered ideal for achieving maximum productivity and is often sought after by individuals and organisations. However, the average person experiences a flow state only rarely because their work environment and culture can often prevent it from happening.

To achieve a flow state, there are certain prerequisites that must be met:

The Zone

Having a team that regularly experiences flow state can greatly impact an organisation’s success. Such a team is estimated to be 10 times more productive than an average team, making it a formidable weapon against the competition. Organisations need to create a work environment and culture that supports a flow state and maximises the potential of their employees.

5.3 L∞P Principles #

L∞P proposed ten equally essential principles:

5.4 L∞P Roles #

“If you want to go fast, go alone; if you want to go far, go together” - African proverb

L∞P tries to balance collaboration and working as a team, so we can attempt to achieve goals that are bigger than ourselves (go far) with focus and alone time so we can get into the zone and be super productive (go fast). When we work together, our goal should be to remove unknowns and enable autonomy; then, we can go our separate ways and get stuff done.

The L∞P team structure is designed to ensure all disciplines are aligned and work without silos. Instead of having separate teams for product development, sales, marketing, and other functions, there is one cross-functional team in charge of discovery and development. This team integrates with sales and marketing by aligning goals and strategies around the product.

L∞P Roles

5.5 The product manager (PM) #

The role of the project manager is the most critical one in the product team. The PM is often seen as the proving ground for future CEOs, as the success or failure of a product falls on their shoulders. It’s therefore important that the PM role is reserved for the best talent, with a combination of technical expertise, deep customer and business knowledge, credibility among stakeholders, market and industry understanding, and a passion for the product.


A PM must be smart, reactive, and persistent, with a deep respect for the product team. They should also be comfortable with using data and analytics tools to inform their decisions and drive the success of the product. The PM’s main task is to ensure that only the most valuable work items reach the backlog, guiding the product team towards building solutions that deliver the greatest impact and customer value.

In addition to the PM role, the PM is also often responsible for the product owner role, ensuring that the product backlog is always aligned with the product vision and strategy. They must have a strong understanding of customer needs and market trends, and be able to work closely with the development team to prioritise work items and drive the product forward.

5.6 L∞P Artefacts #

In this section, we are going to take a look at the L∞P Artefacts. We will mention common artefacts from other methodologies, clarify why we will not use them, and introduce some new ones.

5.7 L∞P Ceremonies #

In this section, we are going to take a look at the L∞P Ceremonies. We will mention common Ceremonies from other methodologies, clarify why we will not use them, and introduce some new ones.

5.8 L∞P and the future of work #

In this section, we will learn how some of the core principles in L∞P can prepare organisations for some of the biggest trends in the future of work.

5.8.1 A trust culture prepares organisations for Remote Work #

A culture of trust leads to a sense of ownership because trust creates a foundation of mutual respect and understanding between employees and their managers. When employees feel trusted, they are more likely to feel valued and appreciated, which can increase their sense of belonging and commitment to their work. This sense of belonging and commitment can then lead to a sense of ownership. When employees feel a sense of ownership, they take pride in their work and feel more responsible for its outcome. They are more likely to go above and beyond their job requirements, take initiative, and be more creative in their problem-solving.

In turn, this sense of ownership can lead to increased autonomy. When employees feel that they have a level of control over their work and are trusted to make decisions, they are more likely to feel empowered and motivated. This autonomy allows employees to work more efficiently, as they are able to make decisions and take actions without having to constantly seek approval from their managers. Additionally, when employees are given autonomy, they are more likely to feel valued and respected, which can lead to increased job satisfaction and engagement.

Therefore, having a culture of high trust is crucial for effective remote work as it creates a positive work environment that encourages ownership and autonomy, leading to increased employee motivation and productivity.

5.8.2 A data-driven culture prepares organisations for the adoption of AI #

Having a data-driven culture prepares organisations for the adoption of AI** by emphasising the importance of data collection, analysis, and informed decision-making. Organisations with a data-driven culture value data as a key asset and have processes in place for data management and analysis. This creates a foundation for successful AI implementation as AI relies on large amounts of accurate and high-quality data for training and decision-making. Additionally, a data-driven culture can foster a more analytical and evidence-based approach to problem-solving, making it easier for organisations to evaluate the potential impact and limitations of AI solutions.

5.9 Scaling the infinite loop #

This section will look at strategies that can help organisations scale their operations under the L∞P framework.

5.9.1 Multiple product teams #

You can create multiple product teams with different focuses. The following list details some of the most common strategies:

5.9.2 Loop of Loops (LoL) #

Loop of Loops (LoL) can be used to coordinate and manage the dependencies between multiple Infinite Loop teams working on a large, complex project. It is a way to scale the Infinite Loop beyond a single team to handle the communication, coordination, and integration challenges that arise when multiple teams work together. The Loop of Loops typically involves the PMs from each Infinite Loop team meeting regularly to discuss and resolve cross-team dependencies.

In this approach, the PMs communicate what their teams are working on, what they need from other teams, and what roadblocks they are facing. This helps to ensure that all teams are aligned on the project goals and are making progress towards the same end goal. The Loop of Loops also acts as a forum for cross-team coordination and problem-solving. For example, if one team is blocked on a certain aspect of the project, they can bring the issue to the Loop of Loops meeting to find a solution with the help of other teams. The Loop of Loops is also a place for sharing information and updates, such as customer insights and changes in priorities.

5.9.3 Platform engineering #

A platform engineering team is a group of software engineers, developers, and other technical experts who are responsible for building and maintaining the technical infrastructure that supports the development and deployment of software applications. The primary goal of a platform engineering team is to create a stable, scalable, and efficient platform that enables other teams within an organisation to build and deploy applications quickly and reliably.

A well-functioning platform engineering team can bring several benefits to an organisation, including:

The scope of a platform engineering team’s responsibilities may vary depending on the size and needs of an organisation. Some common tasks and responsibilities of a platform engineering team include:

6. What next? #

These two posts are the very first iteration of The Infinite Loop. My goal is to develop something with enough maturity and well-documented enough to gain some industry adoption. I’m aware that this is a mammoth task but trying is free!

My first goal was to put it out there. My next goal is to get as much feedback as possible. Please use the comments or complete this survey to help me take this idea further.

Thanks for reading!


Now read this

Dependency injection in TypeScript applications powered by InversifyJS

About # InversifyJS is a lightweight inversion of control (IoC) container for TypeScript and JavaScript apps. InversifyJS uses annotations to identify and inject its dependencies. The InversifyJS API had been influenced by Ninject and... Continue →