Lean Software Delivery: Empowering the Team

From my experience, a truly empowered software development team is one that has the ability to impact the entire Value Stream from start to finish. This team, starting from an idea or the identification of a problem (even discovering the problem alongside its users), takes responsibility for delivering value to those customers. This value is not limited to creating new features but also includes protecting what has already been built, minimizing the cost of unnecessary developments, and fostering capabilities that help achieve business objectives efficiently and effectively. End-to-end responsibility involves evolving, operating, and continuously maintaining what they have built, taking full ownership of their development.

https://blackswanfarming.com/value-a-framework-for-thinking/

Value streams can be directed both to external customers and to other teams or departments within a company. At Alea Soluciones, my team was responsible for the value stream for the end customer (management/telephony/TV/internet software for telecommunications operators) as well as the value stream for tools that accelerated and assisted another department in charge of network deployments and physical network operations. At The Motion, our value stream was for the end user of our product. And both at Nextail and currently at Clarity AI, my teams (team topologies: platform teams) are responsible for internal Value Streams aimed at accelerating/enabling other teams responsible for Value Streams to our end customers (team topologies: Stream Aligned teams).

Therefore, this empowerment—from idea to delivery and maintenance of value—always takes place within a value stream, whether internal or external. In companies, there is usually a combination of both types of value streams.

As John Cutler aptly describes, these are the so-called Product Teams.

https://amplitude.com/blog/journey-to-product-teams-infographic

Product Engineers / Impact-Oriented Approach

The mindset and culture I have always tried to promote align with what now seems to be in vogue: the "Product Engineers" way of thinking. That is, forming teams that do not merely execute tasks assigned by a manager or the Product area, but instead become true opportunity seekers, problem solvers, and value generators. These teams work by identifying problems—or even discovering which problems need to be solved—then offering the best possible solution, progressively evolving it through user and system feedback. This is always done with the end customer in mind, considering both the short and long term. Focusing solely on the short term can lead to neglecting the ability to continuously deliver value through new evolutions of the delivered software.

To give some practical examples, at Alea Soluciones, the entire team rotated through customer interactions, support roles, and meetings with the CEO and department heads. We all got involved in understanding why we did things, what impact we were aiming for, and with that knowledge, we were able to develop solutions iteratively, adapting them to the desired impact. This allowed us to learn more about our business and continuously provide better solutions.

At Clarity AI, within the Platform teams, we have conducted numerous interviews with internal users, used surveys, collaborated with interested teams on joint developments, and implemented beta tester and champion programs when developing new internal products. We also rotate support responsibilities so that everyone remains connected to customer needs and usage.

How to Foster This Mindset

Ultimately, it’s about shaping the team’s culture—something that sounds easy when put into words but is, in my experience, one of the hardest things to achieve (enough to fill entire books).

As we’ve been exploring in this series of articles, Lean Software Development is geared toward fostering this kind of culture—one that maximizes value (from the customer’s perspective), minimizes waste, and naturally aligns with customer needs.

What has worked for me in the past to help build this type of culture includes:

• Prioritizing it in hiring, by asking specific questions about product impact and past contributions. I try to assess whether candidates see software as a means to an end or as the end itself.

• Evaluating user empathy and a focus on quality and testing in the hiring process, as I believe these aspects are closely tied to the mindset of delivering sustainable value.

• Ensuring a critical mass of team members who already have this mindset so that it can spread. In some cases, this has meant temporarily bringing in experienced individuals or hiring external experts to help establish that foundation.

• Providing training on vertical slicing, product topics, and Domain-Driven Design (DDD), emphasizing ubiquitous language, domains, etc.

• Technical coaching, training, and collaborations with professionals who embody this mindset (I’ve been fortunate to do this with Carlos Ble, Modesto San Juan, Alfredo Casado, Xavi Gost, Aitor Sanz, Codium, etc.). I also keep certain companies on my radar—those I know can bring this mindset in case an opportunity for collaboration arises (Codium, 540, Leanmind, Code Sherpas, Codesai, tech93, etc.).

• And finally, what some consider my superpower: Being an absolute pain in the ass—constantly repeating the same message about user focus, sustainable quality, impact-driven development, and so on. 😆

Empowered Teams, Balance, and Trust

For a team to be truly empowered, it must have the ability to decide what to work on and how to approach it—while always staying aligned with the organization’s needs. This means properly balancing short-, medium-, and long-term priorities, as well as finding the right mix between behavioral changes (new features) and structural changes (design improvements or architectural changes).

If the team lacks this decision-making power and an external entity dictates what they should work on at all times—without real discussion—several common problems tend to arise:

• An imbalance in priorities, which over time slows the team down.

• The accumulation of technical debt or a decline in code quality.

• The addition of new features without the necessary evolution of the system’s architecture.

https://x.com/johncutlefish/status/1622093852969680896

How to Enable Teams to Make These Decisions

In my experience, ensuring that the team can take ownership of these decisions requires:

• Earning the organization’s trust by working responsibly and staying aligned with business needs.

• Delivering quickly and in small steps, making it much easier to continuously blend small behavioral changes with structural improvements. This ensures a continuous flow of user value while maintaining the system’s evolution and sustainability.

Following Lean Software Development and Extreme Programming (XP), which naturally guide us toward this way of working—small steps, maximizing value.

Ultimately, Lean Software Development aims to create positive feedback loops, where:

• Small, incremental impacts build trust within the organization.

• That trust leads to greater autonomy for the team.

• Autonomy enables better decision-making, driving continuous improvement (Kaizen).

If the team is not initially truly empowered, it is up to us to analyze the situation and propose or implement small changes to improve it. The most crucial aspect of this process is earning the organization’s trust, as this is what accelerates the shift toward empowerment. After all, no one will grant more autonomy unless the team consistently demonstrates, step by step, that it is responsible and systematically strives to achieve a positive impact.

Just as Lean creates a positive reinforcement loop, where:

• We gain more autonomy, which allows us to have a greater impact, and

• That impact generates even more autonomy for the team,

there is also a negative reinforcement loop:

• If the team fails to deliver frequently or with the necessary quality, the organization trusts it less.

• That lack of trust reduces the team’s ability to make decisions, limiting its autonomy.

• In turn, this reduces opportunities to improve delivery frequency and quality, perpetuating the negative cycle.

Empowerment and Architecture

As we’ve discussed, an empowered team is one that has end-to-end responsibility, from idea to production deployment and operation of the solutions they develop. For this to happen effectively, the following conditions must be met:

• Minimizing (or eliminating) dependencies on other teams. When dependencies do exist, there should be clear interfaces and rules to coordinate work, minimizing bottlenecks.

• Working in an environment and on a platform that allows the team to autonomously deploy and operate their solutions in production.

Of course, we all know that these conditions are not simply given to us—we must continuously and consciously invest effort in:

• Eliminating dependencies with other teams and designing our solutions to avoid creating new ones.

• Continuously improving and strengthening our development, deployment, and operations platform. This can be seen as making our "workplace" habitable, recognizing that without ongoing investment, it will inevitably degrade.

Concrete Practices That Have Worked for Me in Different Teams

• Maintaining a sustainable pace (Extreme Programming) and allowing time for continuous improvement and experimentation. It’s critical to avoid operating at full capacity all the time, ensuring enough slack to address internal improvements and explore new ideas.

• Applying "Bounded Contexts" from Domain-Driven Design (DDD) to structure architecture based on business/domain criteria rather than technical components.

• Avoiding separate QA teams and assigning quality responsibility to the development team itself. While specialized quality profiles may exist, ownership of quality should be shared by the entire team.

• Embracing the "You build it, You run it" principle, eliminating the need for a separate operations team. This encourages the team to take responsibility not only for building the solution but also for running it in production.

• Investing in observability and monitoring, both from a product perspective and a technical standpoint, to gain a better understanding of performance and potential issues.

• Absorbing work from other teams when it helps eliminate dependencies. This should be done strategically, considering knowledge requirements and workload, but in many cases, it’s more efficient to acquire the necessary expertise and automate certain tasks rather than remain dependent on another team.

• Working in small increments (vertical slicing, deployment pipeline automation/optimization, exhaustive testing, etc.) to enable continuous delivery and reduce risk with each change.

Non-Empowered Teams

In some cases, the biggest obstacle to team empowerment is the organization itself or the company culture. The most common scenarios I’ve encountered include:

• Division by specialties and functions: When the organization is structured into separate areas such as frontend, backend, operations, QA, etc., making collaboration and team empowerment difficult.

• Teams as "feature factories": Even when cross-functional teams exist to some extent, they are often treated as mere executors of solutions decided by Product or Business, with no real decision-making autonomy.

• Cross-functional teams with technical responsibilities: Sometimes, organizations attempt to create cross-functional teams, but their responsibilities are assigned based on technical components rather than business domains. This means that delivering any functionality requires coordination across multiple teams, limiting agility and autonomy.

If these approaches define the status quo in our organization, there’s no alternative: change is necessary. Fortunately, our industry already offers extensive material on team organization, the pros and cons of different structures, the relationship between software architecture and team organization, and team management. Some valuable concepts in this area include Team Topologies, strategic patterns from Domain-Driven Design (DDD), Conway’s Law, Kotter’s change model, Systems Thinking, and socio-technical systems.

From experience, I can tell you that waiting for changes to happen magically (spoiler: they won’t) is a bad strategy. When I’ve seen the need for change, I’ve taken the initiative to drive it myself. You’d be surprised how much can be done without asking for permission.

Examples and Experiences

Alea Soluciones

At Alea Soluciones, we had almost complete autonomy—not only in deciding what to work on but also in how to implement our solutions. We coordinated directly with the CEO and key department heads, and all product and organizational decisions were made by our team. Our starting point was always the company's overall strategy, integrating continuous feedback from both internal and external customers. Additionally, our working methodology was entirely our own, evolving constantly through a process of continuous improvement. We even had the freedom to make hiring decisions, as long as we stayed within the agreed budget.

This autonomy and empowerment were deliberately pursued, and to achieve it, we focused on:

• Gradually earning the company's trust by delivering high-quality solutions with a significant impact.

• Taking on work from other departments to eliminate dependencies.

• Encouraging multidisciplinary skills within the team to avoid silos.

The Motion

At The Motion, while we had a high level of empowerment, initially, the product and design/UX functions were separate and worked several months ahead of the rest of the team. This model, focused mainly on backend-driven video ad generation, worked well at first and didn’t create friction. However, as the product evolved and required configuration and administration interfaces, this gap started to cause problems.

As the organization evolved, we brought in team members with frontend and layout skills who also had a strong sense of product development and visual design. We also added a designer with experience in web layout, which facilitated a gradual design evolution. In most cases, we worked in pairing between the designer and a frontend developer, allowing us to progress in small increments and eliminate the initial delays. This shift gave us greater autonomy and better synchronization between design and development.

Clarity AI

The teams I’ve built at Clarity AI were designed from the start with end-to-end responsibility, allowing me to enjoy the benefits of empowered teams from day one.

When I joined in 2020, there was already a transition underway to create cross-functional teams, although reporting lines were still structured by specialization (frontend, backend, data engineering, and cloud/systems). This shift toward cross-functional teams aligned with my vision, so I joined the tech leadership team to accelerate the transformation using Team Topologies principles. Over the following months, we adjusted reporting structures, redefined guild functions to operate as communities of practice, and adapted the engineering career framework to fit the new structure.

This new way of working enabled us to support rapid growth, creating both stream-aligned cross-functional teams and platform teams.

Today, after much effort, the teams are highly autonomous, with near-complete end-to-end responsibility. In Clarity AI, some teams require specialized knowledge of sustainability, and we’re working on integrating this expertise in the best way possible to further enhance their empowerment.

Additionally, we've embedded key engineering principles that reinforce end-to-end responsibility within teams:

• "You Build It, You Run It"

• "Squad Autonomy Over Standardization"

• "Flow-Driven Product Delivery"

Applying Lean Principles

Empowering teams is not just an effective organizational strategy—it embodies the core of Lean principles. By reducing unnecessary approvals and handoffs, we eliminate waste, allowing the team to focus on what truly matters and accelerate their work without bureaucratic obstacles. This approach reinforces continuous learning, as the team can experiment and adapt quickly, developing a deep and shared understanding of their own processes and outcomes.

At the same time, autonomy enables faster decision-making, removing bottlenecks that typically slow down development and allowing us to deliver value more efficiently. Quality becomes a shared responsibility, embedded within the team, giving them the confidence to uphold high standards without relying on external reviews.

By applying these Lean principles, we create a more efficient, adaptable, and innovative software development environment. This not only speeds up value delivery but also naturally aligns with small, incremental steps, making continuous improvement and technical excellence an inherent part of the team’s daily work.

References and related links

• Book: Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency

• TBM 27/52: Mandate Levels

• Value: a framework for thinking

• Journey to Product Teams

• Book: Empowered: Ordinary People, Extraordinary Products

• Product vs Feature Teams

• Video: Alea Soluciones: Alineando valores con prácticas técnicas en CAS 2016 (Spanish)

Special Thanks:

This article has been improved with feedback from:

• Nacho Viejo

• Dani Latorre

• Isidro López

• Alfredo Artiles