This week I want to tell you about a phone call. Nothing spectacular, but one of those five-minute conversations that sums up a problem I see everywhere.

A recruiter reaches out about a CTO/CIO role, reporting directly to the CEO. On paper, exactly the kind of mandate I like: the company wants tech to carry more weight, to stop being a cost center you put up with and become a real driver of the strategy. They talk about impact, product, transformation. I listen, interested.

And then, as the conversation goes on, the picture sharpens. Alongside this CTO reporting to the CEO, they’re creating a Head of Product role. Reporting to the COO. Not to the CTO, not to the CEO — to the COO. And to staff this new product org, they’re pulling the Product Owners out of tech and moving them under that Head of Product. POs who, in practice, mostly do delivery.

The rationale? “We want business-oriented product teams.”

I hung up thinking it was a textbook case. Not a bad one. A revealing one. Because it’s exactly the kind of situation where a next-generation CIO would add enormous value — and where, at the same time, the org being drawn up will stop them from adding any.

I’m telling you this anonymized, no company name. The point isn’t to single anyone out: the pattern I’m describing comes up far too often.

A next-gen CIO isn’t a CIO with a fresh coat of paint

First, let’s define the thing, because “next-generation CIO” is turning into a buzzword, and a buzzword soon means nothing at all.

We all know the “classic” CIO: solid on infrastructure, governance, information systems, risk and cost control. That’s valuable, and it isn’t going away. But that profile is often too far from the customer and from the speed of digital. Tech gets treated as a black box: you hand it orders, it ships, and nobody quite knows what happens inside.

The next-gen CIO holds both worlds at once. They keep the engineering bar high — quality, security, the technical debt you don’t let rot. And they add what’s most often missing: customer obsession as the north star. Not the customer as a slogan, but as the compass that settles the trade-offs day to day. A classic CIO already knows how to talk to the board and to the developers — that’s not where the difference lies. The difference is that they steer from the user’s problem and the impact created, not from project scope or the budget to hit. Honestly, it’s not a profile you find on every corner, because that kind of obsession can’t be decreed: either it shapes every decision, or it’s just a line in a job description.

What it changes in practice: they don’t think in “projects to deliver” but in “problems to solve” and value created for the user. That’s exactly what I tried to do at Bpifrance, where we shifted a large organization toward a product-led logic centered on user impact — and where having product, tech and data under one shared vision was the precondition for moving fast, not an org-chart detail.

The trap: mistaking intent for structure

Back to my call. The stated intent is good. “More impact for tech,” “business-oriented product teams” — who could be against that?

Except intent does nothing. Structure decides. And the structure I’m being described says the opposite of the intent.

Look at it coldly. You create a CTO reporting to the CEO to give tech more weight. Fine. And in the same move, you detach product from tech, put it under the COO, and pull the POs over to the product side. The result: the CTO is left with a “tech” responsibility amputated of half of what creates impact — defining what gets built and for whom. They become a slightly more prestigious delivery function, not really a strategic engine.

You’ve handed out a nice title and a nice reporting line, and you’ve hollowed out the role through the org chart sitting right next to it. That’s what I call the tectonics of organizations: it isn’t intentions that move the plates, it’s reporting lines, scopes, and who gets to decide what.

“Business-oriented” doesn’t mean “far from tech”

That’s where the core misunderstanding sits. People assume a false equation: for product to be business-oriented, you have to pull it away from tech and closer to operations.

It’s the exact opposite. A business-oriented product is one that genuinely solves a customer problem — fast, well, and profitably. And that plays out at the intersection of product, tech and business — not by building walls between them. When product and tech aren’t aligned, you don’t get more business. You get political trade-offs, priorities crushing each other, and teams spending their time passing the responsibility back and forth.

Putting product under the COO also sends a very clear signal, even if nobody says it out loud: product is operational, it’s coordination, it’s “keeping things running.” Not strategy. But a real Head of Product is someone who decides what to build to create value — it’s a vision function, not a back-office one. By having them report to the COO, you’re politely telling them to stay in their lane.

The real symptom: POs who do delivery

And then there’s that detail that isn’t one. Product Owners who do delivery.

If POs mostly do delivery, they aren’t Product Owners in the strong sense. They’re project managers with a new label. They don’t own the “why,” they manage the “how” and the “when.” And moving those POs from tech to the Head of Product doesn’t create a product organization. It moves a delivery team from one box to another and slaps a “product” sticker on it.

The problem isn’t fixed, just relocated. Worse: you now have delivery on one side of the org chart and tech on the other, separated by a reporting boundary. Anyone who’s read a bit of Team Topologies, or simply lived through Conway’s law, knows what comes next: the product architecture and the fluidity of the teams will end up mirroring that boundary. You’re manufacturing silos — and eighteen months from now you’ll wonder why “it’s not fast enough” and why “product and tech don’t talk to each other.”

What a next-gen CIO would have said in the room

That’s why I say this is exactly the kind of situation where that profile adds real value. Not because they’d have a fancier title. Because they’d have asked the right questions before drawing the org chart.

They’d have started with the problem, not the boxes. What impact do we want, for which customers, measured how? Only then: what organization serves that impact? And at that point they’d probably have said you don’t give tech more weight by cutting it off from product — you do it by bringing product, tech and data under one shared vision, with a real reporting line to the CEO, and by turning POs from delivery conveyor belts into owners of the problem to solve.

I’m not saying there’s only one right setup. It needs to be challenged; it depends on the company’s maturity, its sector, its people. But the reflex of splitting by function and spreading the pieces under different managers “so everyone has their scope” is often the shortest path to no one owning the impact end to end.

And the trap is that all of this starts from good intentions. People want to do the right thing. They want to “give tech more impact.” But they reason in org charts before they reason in value, and the org chart ends up deciding for them.

The question I’ll leave you with

I didn’t take it further, to be transparent. Not out of pride — but stepping into a process whose structure already contradicts its ambition was a bad start.

It did leave me with a question, though: how many companies today are convinced they’re “giving tech more impact” by creating a shiny CTO role… while building, right next to it, the very organization that will stop them?

If you’ve lived through this, on either side of the table, hit reply — I read everything, and those replies tend to spark the best conversations of the week.

Talk soon, Nicolas

PS: if this resonates, feel free to forward it to a leader or peer in the middle of rethinking their tech/product org. These questions are usually worth asking right when the org chart is being redrawn.

Because pretty much everyone uses AI to summarize a doc or rewrite an email, that’s become standard. But actually delegating a task to it, one that runs while you sleep or sit in a meeting, that’s a different story.

Honestly, I asked myself that question a few months ago, and the answer made me move.

Every morning at 7am, my Mac Mini sends me the brief of my day. Which meetings, which emails to prioritize, which follow-ups still pending, which Granola notes to turn into proper minutes. In the evening, it gives me tomorrow’s reminder. And none of it, not a single byte of my outgoing emails, my meeting transcripts, or my todos, ever leaves the house.

I’m not telling you this to flex my tech credentials. I’m telling you this because I think we have a real posture problem on AI at the executive level.

You still see leadership meetings where AI lands on the agenda, where everyone agrees we need to accelerate, that we’re behind, that we need to bring the teams along, and where, around that same table, very few people have actually delegated a task to an AI assistant in their own week. Me first, for a long time. We hand the topic over to “the AI team”, to a consultancy, to a freshly appointed Chief AI Officer. And we wait for results.

Honestly, I think there’s a prerequisite. Before asking your teams to transform their jobs, you need to have transformed a bit of your own. Otherwise you’re talking about something you’ve never really touched, and it shows.

So, over the past few months, I’ve been building my own digital twin. Basic level at first: CV, reference books, papers I like, prompts for context. And step by step, I’ve been scaling it up.

Here’s what runs on my Mac Mini today. A full analysis, syntactic, linguistic and semantic, of my outgoing emails and meeting transcripts, so it learns how I write (and how I speak, which is not the same thing). Cowork prepares draft emails across my different inboxes, through a homemade Gmail MCP server that technically blocks any actual send: not enough trust yet to let it hit “send” on its own. A daily tech watch. The daily recap of my day and the reminder for tomorrow. The pickup of Granola notes to turn meetings into minutes. And each week, a synthesis of all of the above to enrich its general context.

What’s interesting is that almost all of those tasks, summarizing, extracting, rephrasing, classifying, reminding, run perfectly well on the machine itself. You don’t need a model that writes Shakespeare. You need a model that does one thing well, on data that is yours.

That’s exactly the point of an article I came across recently (unix.foo, Local AI Needs to be the Norm): for the vast majority of use cases, local AI should be the norm and the cloud the exception. Not an ideological stance, an engineering argument. Why turn a simple feature into a distributed system dependent on a third-party vendor, when the silicon in your pocket (or on your desk) can already handle it? For my most complex use cases, I still use Claude through the API. But I’ve gained something: I now know why I’m sending a piece of data out, when I do. The rest, it handles on its own.

And here’s what I want to land on: none of this got built in an hour on a Sunday night. You need to count a half-day a week, minimum, to start picking up real speed. It’s a personal investment, and that’s precisely what makes the conversation credible when you take it back to your teams.

Anyway. I don’t know if my setup is the right one. It’s imperfect, I take it apart and rebuild it regularly. But when I talk about AI to people now, I’m talking about something I’ve lived, not a promise I’ve read.

So, fellow executives, where do you stand on this, personally? Before asking your teams to come along, what did you delegate last week?

PS: post written with Claude, of course :)

The visual accompanying these lines delivers a clinical diagnosis. It’s an excerpt from the upcoming third volume of the graphic novel based on The Phoenix Project (by Gene Kim, Kevin Behr, and George Spafford). In it, Bill Palmer and his team face a brutal reality: Phoenix, the company’s flagship project, should never have been greenlit. Why? It was built on distant promises of results—with zero immediate guardrails.

As an executive, you’ve likely felt that cold sweat. That specific moment when quarterly financials look green, yet you sense the engine is seizing up. The uncomfortable truth: most of your KPIs are autopsies. They tell you what the organization died of, not how to keep it alive.

This is my daily mission. To lead a modern tech organization, you must stop looking at the rearview mirror and start cleaning the windshield. In short: shift from lagging indicators to leading indicators.

The Tragedy of Retrospective Data

Revenue, net margin, churn rate... these are vital, but they are mere observations. By the time these figures hit your screen, the window for action has closed. Last month is frozen. Steering solely by these metrics is like driving a sports car with your eyes glued to the rearview mirror: at the first sharp turn, you’re in the ditch.

It’s a psychological trap. Lagging indicators feel safe because they are precise. They look great in an investor deck. But they are passive. Conversely, leading indicators are predictive. They measure the activities and conditions that statistically guarantee future success.

If you’re chasing growth, don’t just stare at the balance sheet. Monitor your pipeline velocity or sales response times. Is user satisfaction your priority? Stop obsessing over churn rate—track weekly engagement on core features instead. The signal is there, hidden in the shadows, long before the financial hit happens.

Conway’s Law and the Architecture of Silence

We often ignore a fundamental law: your team structure dictates your product quality. Tech systems inevitably mirror the communication patterns of the organizations that build them. That’s Conway’s Law. If your departments work in silos, your software will be fragmented, slow, and brittle.

Here, the leading indicator is flow. How much time elapses between an idea and its market launch? If this lead time is stretching, it’s not because your people aren’t working hard—it’s because your organization has become an obstacle. An autonomous team with end-to-end ownership will always out-deliver a group of isolated geniuses. Your company topology is your primary profit lever.

Escaping the Feature Factory

The obsession with shipping features is a costly disease. Welcome to the Feature Factory: a mill churning out volume to create the illusion of progress without ever questioning actual value. We stack options hoping to impress, but we only add technical debt and invisible maintenance costs.

True excellence lies in generating Global Impact. To get there, you must pull strategic levers that turn simple production into a value engine:

• Outcome over Output: Focus on business benefits rather than lines of code.

• Developer Experience (DevX): Remove friction to unlock engineering creativity.

• Design for Failure: Build resilient architectures that survive errors.

• Flow Alignment: Structure the org so nothing slows the path to the customer.

• True Empowerment: Push decision-making to the “edge,” where the technical knowledge lives.

• Operational Efficiency: Ruthlessly hunt the waste slowing your internal processes.

• Cash-Flow Acceleration: Ship tiny increments to generate immediate ROI.

In the Phoenix Project comic, a character drops a hard truth: “We must reduce release sizes to beat the internal rate of return.” It’s math. Every day a piece of value is “done” but not “shipped” is a day you pay interest on invisible debt.

Cognitive Load: The Silent Killer

There is one metric few boards dare to track, yet it defines your viability: the cognitive load of your teams.

An organization where talent is saturated by bureaucracy or overly complex tools stops creating. If your teams spend 60% of their time in “sync meetings,” your flow is dead. The role of a proactive leader is to be an architect of simplicity. This requires the courage to say “no” to a brilliant but resource-heavy idea to protect your overall capacity to innovate.

Towards Signal-Based Governance

Moving to leading indicators requires a radical cultural shift. You must accept a degree of uncertainty regarding final numbers to focus on mastering the initial levers.

A senior leader doesn’t ask, “Why did we miss the goal?” They ask, “What obstacle is blocking movement today?” This shifts leadership from “Controller” to “Value Unblocker.”

Your ideal dashboard should look like a weather station. It should warn you of incoming storms, not send you a postcard after the hurricane has passed. By monitoring precursor signals—intrinsic work quality, resolution speed, boots-on-the-ground satisfaction—you regain control over your economic destiny.

Yesterday, I had a unique experience during a “Paper Cootie Catcher” simulation with the Tech.Rocks community. Having run this pull-flow workshop before, I made a deliberate choice: I didn’t move. I just watched.

Stepping aside changed everything. Watching my peers struggle with their folds revealed the obvious—the kind of friction we always miss in the heat of the moment. You never truly understand a bottleneck until you stop fighting it and start observing it.

That is the heartbeat of the Gemba Walk.

Reality vs. Reports: When the Floor Shatters the Spreadsheet

In complex organizations, we too often lead from a distance. We stay glued to cold KPIs, convinced they tell the whole story. It’s a mirage. The Gemba—the actual place where value is created—is the only antidote to “ivory tower” management. Immersing yourself in the field isn’t a courtesy call; it’s a radical act of confronting theory with raw operational truth.

By staying a spectator, I caught what the players, buried in the work, could not see:

• The tiny, invisible friction born from a single moment of hesitation.

• The rising frustration as “work-in-progress” piles up.

• The heavy silence that almost always signals a quality defect.

Scaling Talent in Digital

A company only truly progresses if it learns while doing. For a Digital Leadership team, this is the foundation. A leader’s job isn’t to pull a miracle solution out of a hat, but to support teams so they can dismantle their own roadblocks.

“Going to see” means hunting down the waste that kills momentum and instilling a culture of continuous improvement. By showing interest in the process—not just the result—you build a resilient framework. That’s how you turn a pile of tasks into a seamless flow.

From Individual Impact to the Big Picture

This outside perspective shows how every micro-decision shapes global impact. Without an authentic presence on the floor, leaders end up making decisions disconnected from the actual engine of the business.

A Gemba Walk isn’t a cold audit. It’s an exchange that fuels cooperation. By observing without interfering, you spot the real levers of agility. You move from theoretical management to boots-on-the-ground leadership.

Leave your desks. Forget your abstract dashboards. Go to where the code is written, where the bugs surface. It is the only path to building a lean company ready for the next industry shift.

In my role as a Director, I make it a point to get out of my bubble and onto the floor two to four times a month. It isn’t lost time; it’s the core of my job. Understanding the pulse of our projects is how we win.

Last quarter, a CEO spent 3 hours dissecting revenue charts that were already 90 days old. Meanwhile, their deployment cycle time had doubled, technical debt was choking innovation, and customer health scores were silently plummeting.

The diagnosis? A pristine rearview mirror... and a completely foggy windshield.

Here’s the uncomfortable truth: most organizations are still confusing reporting with understanding their value stream.

Why Your Financials Tell You What Happened—Not What’s Coming

In most boardrooms, we’re still obsessing over closed numbers—revenue, EBITDA, churn—when there’s virtually nothing left to change about that cycle. We’re analyzing the ship’s wake while the reefs hide in the next links of the flow.

Classic metrics are comforting because they seem indisputable: audited, stable, aligned with P&L. They tell a clean story... after the fact.

But when a quarter deteriorates, the value stream links that broke were often fragile for months:

• Technical debt accumulated on critical systems

• Deployment frequency slowing down

• Teams burning out on bottleneck work

• Progressive misalignment between product and actual usage

Looking only at output metrics is like watching the flow at the end of the chain without seeing the inventory, blockages, and rework loops upstream. You end up suffering domino effects you never saw building.

The shift happens when you accept looking at the entire value stream end-to-end, supported by leading indicators—early signals that connect what teams do today to effects that will propagate tomorrow throughout the flow.

What Actually Makes a Metric “Leading” (and Why Most Aren’t)

We call many things “leading” that really aren’t. To truly transform a value stream, an upstream indicator must meet simple criteria:

✅ Observable early: It moves well before output indicators
✅ Frequent: Tracked at least weekly, often continuously
✅ Causal: Tied to a key flow link via cause → effect relationship
✅ Actionable: A specific team can influence it quickly
✅ Readable: Summarizable in one sentence for any decision-maker

Real-world examples across the value stream:

Go-to-market: Qualification rate evolution between early pipeline stages, core target account share in created opportunities—signals about commercial upstream quality rather than closed deals.

Product: Time-to-value for new users, North Star feature usage depth, 7/14/28-day retention—signals about the solidity of customer “aha moments.”

Delivery/tech: Deployment frequency, cycle time from commit to production, mean time to restore—signals about the software factory’s capacity to regularly irrigate the entire value stream.

People: Team satisfaction, unplanned/planned work ratio, team stability on critical domains—signals about the health of human links in the chain.

These indicators lack P&L precision but offer something essential: the ability to act where the chain weakens, before results break.

Lean Engineering: Making Problems Visible Before They Become Disasters

Lean Engineering, inspired by the Toyota Production System, isn’t about “doing more with less.” Its real ambition is to make problems that matter visible very early, tackle them as they emerge, and treat them at the root—where they occur in the value stream.

In this logic, leading indicators become the company’s nervous system sensors:

Flow: Work In Progress levels, WIP age, flow efficiency. When these signals degrade, they announce exploding wait times, swelling intermediate inventory, and pressure waves propagating between departments.

Quality at source: Proportion of work done right the first time, incident handling time, share of defects detected near origin rather than at chain end. Declining upstream quality mechanically prepares returns, rework, hidden costs, and disappointed customers.

Learning: Problems actually closed each week (identified, analyzed, treated, stabilized), delay between observing dysfunction and deciding on action. The shorter these learning loops, the more robust the value stream becomes.

A story that illustrates this:

With my teams, we tracked a beautifully designed chart of production incident lead time each week. Visually impeccable. Practically useless for decisions:

• We saw individual incidents more or less long

• But couldn’t tell if the overall situation improved or degraded

• Or where to focus efforts

The day we complemented this view with:

• Open incident inventory

• Incoming and outgoing incidents each week

• Median resolution time rather than average

The picture completely changed. We went from decorative curve to genuine leading indicator on incident handling value stream health: we could see if inventory was emptying or filling, if capacity matched demand, and if “normal” incidents resolved faster or slower.

Same technical data, but suddenly a visible value stream.

How Data & AI Change the Game

Technology doesn’t just change data collection speed; it changes how we see the value stream.

Advanced analytics and AI enable:

• Combining weak signals (navigation, support, product usage, market context) to build scores anticipating churn or contract expansion at critical chain points

• Identifying patterns humans wouldn’t imagine—specific customer action sequences systematically preceding upgrades or departures

• Moving from purely descriptive dashboards to indicators directly suggesting intervention points in the flow

Three digital projects illustrate this shift:

Walmart (Distribution): Used near-real-time analytics to cross-reference checkout data, search signals, and web behavior. Predictive inventory indicators at store level enabled reaction before stockouts on certain logistics links, particularly for highly volatile seasonal products. The leading signal sat at local demand level; impact showed later in sales per square foot.

Retail banking: Some banks now track “digital adoption rate” and cloud migration as upstream indicators of service cost and volume absorption capacity. As long as these signals progress, friction points in the processing chain reduce and unit costs stay controlled despite growth.

Starbucks (Physical retail augmented): With its “digital flywheel,” relied on a simple leading indicator: mobile ordering adoption rate and loyalty program member activity. By reinforcing these digital uses at key journey moments, the chain smoothed in-store throughput and secured recurring value flow, well before annual accounts illustrated it.

In all cases, AI and data aren’t window dressing: they enable mapping the value stream differently, revealing bottlenecks, levers, and opportunities that classic metrics don’t show.

Connecting Leading Indicators to Financial Language (Without Losing the Value Stream)

A CEO doesn’t buy continuous deployment charts or developer satisfaction indices; they buy cash flow, reduced risk, and sustainable value from a mastered value stream.

Connecting leading indicators to this grammar is essential:

Cycle time corresponds, on the digital side, to inventory turnover speed in manufacturing. In a factory, sleeping stock immobilizes cash; in software, undelivered backlog immobilizes cash as salaries. Reducing this delay improves product budget internal return and accelerates value rotation in the chain.

Technical debt is hidden liability: the higher the maintenance/new features ratio climbs, the more the organization pays for past choices. A leading indicator like unplanned work ratio visualizes this liability well before market-perceived innovation decline, anticipating where the value stream risks freezing.

Reliability metrics (change failure rate, mean time to restore) proxy reputation risk and value stream interruption as seen by customers.

When you make this link explicit, leading indicators stop being a “tech” or “method” topic: they become a tool to reason about economics, risks, and capital allocation along the value stream.

The “Iceberg” Dashboard: Reassuring While Transforming

The effective balance point resembles an iceberg dashboard centered on the value stream:

Above the waterline: Output indicators—revenue, margin, churn, NPS, cash. They describe how value materialized at chain output.

Below the surface: Leading indicators illuminating what happens inside:

• Digital capabilities (deployment frequency, cycle time, technical debt ratio)

• Customer signals (North Star feature usage, digital channel adoption, health scores on key segments)

• Human signals (team satisfaction, stability on critical domains, learning intensity)

The essential part is explicit links between these two levels:

“Revenue is stable this quarter, but our cycle time is up 15% and unplanned work exceeds 35%. If we don’t invest now in automation and debt reduction, we’re accepting that the value stream will seize up within two quarters.”

An indicator that triggers no decision remains, for me, expensive noise. A relevant leading indicator is a signal that illuminates a concrete value stream link and triggers both discussion and arbitrage.

The Bottom Line

Moving from output indicators alone to leading indicators isn’t a reporting refinement. It’s a structural choice: looking at the value stream in its dynamics, instead of only commenting on its extremities.

An organization that maps its flows, relies on Lean Engineering to see the right problems early, enriches its signals through digital and AI, then connects these indicators to its investment arbitrages, becomes profoundly anticipatory: it sees risks while still solvable and captures opportunities before they close.

You don’t build sustainable advantage with just a perfect rearview mirror. You build it by installing, at the company’s heart, a radar that illuminates the value stream, link by link—and having the discipline to act on these signals.

💬 YOUR TURN: Which leading indicator would change everything in your organization if you started tracking it this week? Hit reply and tell me—I read every response.

The bag alone is worthless. What matters is the infusion—the water quality, temperature, vessel, steeping time, and final taste.

Applied to business, this forces a simple question: Are your digital investments actually steeping into the value stream, or are they trapped in project silos that impress more than they transform?

From a customer or employee perspective, digital is never the goal. What counts is a seamless journey, fast decisions, clear information, and access to the right service at the right moment.

That’s where Lean thinking provides the robust framework to see this reality clearly.

From Projects to Value Streams: Where Lean Meets Digital

Lean management gives us three essential lenses:

• Waste that consumes resources without creating value

• Value streams that connect all steps end-to-end

• Measures that let us steer from facts, not perceptions

At the executive level, this serves two objectives:

1. Concentrate digital efforts where they genuinely shift economic trajectory

2. Structure a system that learns fast and improves decisions over time

Think of Lean as the method to ensure proper infusion. Without it, you’re just adding hot water to a sealed bag.

The Gemba reality check: Go see how work actually happens. Name the specific waste:

• Multiple data re-entries

• Wait times between approvals

• Incomplete files bouncing backward

• Features developed but rarely used

• Constant context-switching for teams

These aren’t technical details. They translate directly into immobilized time, additional risk, and missed opportunities. They consume innovation capacity as much as operational performance.

Making this waste explicit—say, via an A3 synthesis—lets you connect irritants directly to revenue, risk, or margin issues. You’re no longer talking about comfort. You’re talking about performance.

Structuring the Cup: Digital Value Streams & Innovation Capacity

Before touching org charts or technology, look at the cup: the end-to-end value stream.

A Value Stream Mapping exercise on a priority flow reveals:

• Total cycle time for a customer request

• Mandatory checkpoints and associated queues

• Zones where digital genuinely accelerates

• Zones where it mostly adds complexity

This view is critical for innovation. It lets you ask:

• Which customer segment or journey would a breakthrough actually transform?

• Where would radical simplification unlock new services?

• Which partners should we integrate to create a differentiated offering?

A well-designed cup isn’t just a clean process. It’s a framework that makes new value propositions, collaborations, and business models possible.

Organizing the Tea Bag: Product Teams, Lean, and AI in the Flow

Once you’ve observed the water and clarified the cup, you can examine the bag: how you organize teams to steep it all together.

I see this bag as an intentional blend:

Product teams aligned to specific value stream flows, bringing together product, tech, design, data, and business expertise

Lean culture that questions waste, stops what doesn’t deliver value, and stabilizes what works

Technical platforms that reduce friction for innovation (shared tooling, integrated security, accessible data)

AI capability designed into journeys from the start, not bolted on afterward

AI, used seriously, enables you to:

• Filter and route demand, avoiding low-impact work launches

• Automate complete cognitive tasks while keeping humans in command

• Strengthen analysis and decision support with traceable outputs

• Make organizational knowledge accessible in natural language to teams who need it

At this stage, innovation is no longer just digitizing what exists. You genuinely give yourself the ability to rethink pieces of the value stream where economic and customer impact justifies it.

Setting the Temperature: Cadence, Trade-offs, and Visual Management

Even with a good cup and bag, poor temperature yields disappointing results. In transformation, the equivalent is cadence, trade-offs, and piloting visibility.

Three levers I’ve seen work particularly well:

1. Clear cadence for product teams

Short, readable cycles where you regularly ship visible improvements, examine what’s actually used, what’s broken, what deserves to be stopped.

2. Structured trade-offs by value stream

Portfolio management that starts from key value streams and real capacity, rather than demand accumulation. This requires accepting explicit trade-offs and making them visible.

3. Visual management with immediately actionable indicators

Simple dashboards—physical or digital—grouping a few metrics chosen with business partners:

• Real journey time on a flow

• Perceived effort by users

• Volume processed daily or weekly

• Number of incidents and mean time to resolution

• For AI: result quality and human corrections

The key question: If I see this metric move, do I know what decision to make? If not, it’s not a good steering indicator.

Strong visual management lets leadership, business teams, and digital squads synchronize without reporting overhead—and make adjustment decisions earlier.

Measuring to Learn: Innovation as Discipline

Innovation isn’t a constant geyser of ideas. It’s a discipline: start from a well-posed problem, formulate a hypothesis, test at small scale, measure, decide.

In this Lean logic, three measurement families are essential:

Customer-side performance: Real journey time, perceived effort, completion rate

Usage and value: Active adoption, retention, impact on a concrete business metric (e.g., volume processed, risk avoided, average basket)

Learning: Time between an idea and a robust lesson, ability to industrialize what works and decommission what doesn’t deliver

For AI, add specific indicators: result quality, share of responses corrected by humans, potential drift from expectations, compliance with ethical and regulatory frameworks.

The goal isn’t to pile up metrics. It’s to install a shared foundation that lets all levels talk about the same reality. That foundation enables continuous innovation because it gives you permission to stop, redirect, or reinforce.

Practices That Actually Make the Difference

Rather than prescribe actions, I’ll share what I’ve seen work in organizations where digital and AI genuinely changed things—without posturing or excess hype:

Start with one identifiable value stream

Choose a clear journey or segment with strong business stakes. Look at it together through Lean principles: Gemba, waste, simple synthesis. This creates common language between leadership, business, and digital teams.

Give an explicit mandate to a dedicated product team

On that flow, build a cross-functional product team with clear scope, a few readable indicators, shared visual management, and permission to experiment within guardrails. The dynamic difference is often striking.

Introduce AI where it helps you learn faster

For example, on demand qualification, decision support, or knowledge access. Set up security, privacy, quality guardrails and explicit criteria for continue-or-stop decisions upfront. AI becomes a learning accelerator, not a gadget.

These practices are simple in appearance, but they change the conversation. You’re no longer talking about “doing digital” or “launching an AI use case.” You’re talking about transforming a value stream, with an economic compass and tangible proof.

After more than 20 years in digital, I observe a recurring paradox that spans the entire tech ecosystem: companies invest massively in technology only to find themselves, 18 months later, with technical debt, obsolete products, and exhausted teams. This phenomenon affects startups and large corporations alike, regardless of their industry or technological maturity. The problem isn’t budget, talent, or even strategy. It’s our mass production culture applied to technological innovation.

We’ve transposed 20th-century industrial methods to the 21st-century digital economy. Result: we optimize for delivery speed and feature volume, at the expense of intrinsic quality and sustainability.

This approach generates a form of collective amnesia: we no longer know what it means to create something durable—we only know how to deliver.

Each sprint becomes a race against time where the objective is to check boxes in a backlog, not solve real problems. Each added feature accumulates technical debt that we systematically postpone to the “next sprint.” And when real technological disruption arrives—generative AI, cloud transformation, migration to new paradigms—we discover that we’re paralyzed by our own tech stack.

The irony is striking: the more we “deliver,” the less durable value we create. As Sandrine Olivencia emphasizes in “Build to Sell,” the fundamental difference lies in the very conception: creating assets versus creating deliverables. An asset generates value over time; a deliverable consumes resources to be maintained.

Why We Miss the Innovation Trains

This mass production culture explains why so many companies miss major technological transformations. According to a 2024 MIT study, 95% of AI pilots fail not for technical reasons, but for organizational and cultural reasons. Companies attempt to “plug” generative AI onto technical architectures and processes designed for mass production.

The result is predictable: AI amplifies existing dysfunctions. If your code is fragile, AI will generate even more fragile code. If your processes are chaotic, AI will automate chaos. If your culture favors quantity over quality, AI will produce bad solutions faster.

This reality affects all technological revolutions. Cloud transformation, migration to microservices architectures, adoption of DevOps methodologies: each time, the companies that fail are those trying to apply their old paradigms to new technologies.

Craftsmanship at Scale: A Necessary Alternative

Faced with these observations, it’s time to experiment with another model: craftsmanship at scale. This isn’t a romantic return to the past, but a conscious strategic trade-off that combines artisan excellence with modern industry’s deployment capacity.

Craftsmanship at scale rests on a simple principle: every person in the organization develops the ability to deliver quality on the first try. This means prioritizing intrinsic quality, care in execution, and eliminating voluntary technical debt. But unlike traditional craftsmanship, this approach must be designed to function at large scale, with reproducible processes and shared standards.

Concretely, this translates into several fundamental organizational changes. First, a redesign of performance metrics: instead of measuring only velocity (how many features delivered per sprint), we must integrate durable quality indicators that reveal the real health of our systems:

Rework rate: the percentage of code that must be rewritten within 6 months of its delivery

Flaky test rate: the proportion of tests that fail intermittently, revealing architectural fragility

Small change lead time: the time needed to deploy a minor modification to production, an indicator of accumulated complexity

Bug resolution time: the ability to quickly fix dysfunctions

Maintenance ease: the simplicity with which new developers can understand and modify existing code

Adaptability to changes: the system’s resistance to functional evolution

These metrics tell a different story from traditional dashboards. They reveal whether we’re building durable assets or accumulating technical debt disguised as productivity.

Training Craftspeople at Scale: From Production Flow to Learning Flow

But metrics and processes aren’t enough. You don’t scale craftsmanship with KPIs—you scale it by training craftspeople. In this model, the primary asset isn’t velocity but heritage: code, standards, and especially team expertise. This is where the real transformation lies.

The software craftsperson develops five fundamental skills that transcend technologies: real customer sense (starting from usage needs, not the backlog), quality at source (making defects appear early, stopping flow to learn), improvement science (formulating a gap, testing a countermeasure, measuring, standardizing), design for change (prioritizing changeability over completeness), and workshop work (pair programming, living standards, explicit transmission).

This training cannot be delegated to occasional training sessions. It requires structured, cadenced learning, inspired by traditional apprenticeship but adapted to modern constraints. Technical dojos (4-6 week cycles on concrete problems), engineering katas (90-minute weekly sessions to strengthen a precise technical gesture), and rotating pairing become rituals as important as stand-ups.

Mentoring takes on strategic dimension. We must identify our “workshop masters” (leads who guarantee standards), our “journeymen” (who carry daily quality and train), and our “apprentices” (who gain autonomy). This hierarchy isn’t status-based but functional: it organizes knowledge transfer.

More crucially: we must install a continuous learning culture where learning becomes a flow pulled by problems, not an “HR option.” This means protected and cadenced time, retrospectives at source after each incident, and the right to stop production to make a recurring defect visible.

ROA versus ROI: Changing Economic Paradigm

This transformation also requires a change in economic paradigm. We must shift from short-term Return on Investment (ROI) logic to sustainable Return on Assets (ROA) logic. ROI measures the immediate profitability of an investment; ROA measures an asset’s capacity to generate value over time.

A study by Elder Research published in 2024 shows that companies adopting “Return on Adoption” metrics (a variant of ROA applied to innovation) achieve results 40% superior over 3 years compared to those remaining focused on quarterly ROI. These companies invest more in team training, code quality, and system architecture. In the short term, they seem less “efficient.” In the medium term, they become indispensable.

AI as Revealer and Amplifier

The emergence of generative AI makes this transformation even more urgent. AI won’t replace developers, but it will amplify their strengths and weaknesses. A team that masters craftsmanship at scale will use AI to accelerate the creation of durable assets. A team trapped in mass production will use AI to produce technical debt faster.

The first feedback is enlightening. Companies succeeding in their generative AI adoption are those that first invested in their codebase quality, team training, and process clarity. AI then becomes a multiplier of their existing excellence.

In this context, trained craftspeople become essential: they know how to use AI as an exploration and generation tool, while maintaining their critical capacity to validate, refactor, and secure the produced code. They master “AI poka-yoke”: prompt templates, acceptance checklists for generated code, lints and policies that block generated code without safeguards.

A Strategic Leadership Challenge

Implementing craftsmanship at scale isn’t simple. It requires alignment at the strategic level, a complete redesign of incentive systems, and much pedagogy to evolve mindsets. It’s a leadership challenge that requires vision, patience, and the ability to resist short-term pressures.

But the stakes are worth it. In a world where AI will become omnipresent, companies that have developed a culture of technical excellence will have a decisive competitive advantage. They’ll be able to adopt new technologies without fearing amplification of their dysfunctions. They’ll be able to innovate sustainably rather than suffer the planned obsolescence of their own creations.

The Moment of Truth

We’re at a pivotal moment. Companies that will succeed in their transformation over the next 3 years will be those that had the courage to question their mass production culture to adopt craftsmanship at scale. This isn’t just a technical question—it’s a cultural and strategic question that engages the very future of innovation in our organizations.

The challenge is before us. It’s up to us to meet it, with the artisan’s rigor and the industrialist’s ambition.

Sources:

• “Build to Sell: The Lean Secret to Crafting Irresistible Products” - Sandrine Olivencia, Flavian Hautbois, Caroline Besnard (June 2024)

• “Why 95% of AI pilots fail and how to succeed” - LinkedIn/MIT Study (2024)

• “Moving Beyond ROI: Return on Adoption” - Elder Research (2024)

While companies in 2007 were digitizing existing processes, today's organizations are rebuilding their entire organizational architecture. They're grappling with AI-human hybridization, digital sovereignty, distributed tech ecosystems, and regulatory frameworks that didn't exist two decades ago.

If sector-wide failure rates remain stable despite years of experience, it's because challenge complexity has exploded faster than our collective ability to master it. The real problem isn't the failure rate itself—it's the persistent inability to measure and navigate organizational complexity.

Too many organizations still confuse activism with performance. They measure velocity instead of client impact. They multiply initiatives instead of solving structural problems.

Why Banking Crystallizes All Organizational Complexity

As a Digital Factory Director, I witness this complexity explosion daily. Banking institutions carry multiple societal expectations: quality service, absolute trust, maximum security, continuous innovation, positive environmental impact, and digital sovereignty.

Unlike fintechs that can focus on specific segments, traditional banks must simultaneously:

• Maintain critical legacy systems (decades of accumulated technical debt)

• Comply with constantly evolving regulations (KYC, AML, GDPR, DORA)

• Manage complex IT architecture from successive mergers

• Integrate AI while preserving decision explainability

• Ensure service continuity while modernizing infrastructure

McKinsey reveals traditional banks are 40% less productive than digital natives, with 4-6 month deployment cycles versus 2-4 weeks for fintechs. BCG confirms over 60% of banking tech spending goes to "run-the-bank" rather than "change-the-bank."

This complexity explains why traditional change management methods, designed for simpler worlds, reach their limits in our sector.

The Four-Legged Stool Method: Turning Complexity Into Competitive Advantage

Why the stool analogy? It perfectly illustrates organizational complexity management reality. A stool becomes immediately unstable when it loses one leg. With only two legs, it's guaranteed collapse. This absolute interdependence reflects exactly what happens in transformations: neglecting one pillar destabilizes the entire system.

This method, inspired by Toyota Production System fundamentals, doesn't claim to revolutionize sector statistics overnight. It aims for something more pragmatic: transforming organizational complexity into a predictive management system that learns faster, limits potential failure scope, and maximizes value creation even in uncertainty.

Pillar 1 - Lagging Indicators: Obsession with Final Client Value

The first leg revolutionizes metrics relationships in complex environments. Gone are KPIs disconnected from client value—those vanity metrics that reassure committees without creating real impact. In banking, this means measuring outcome rather than output: user adoption vs features deployed, client time-to-value reduction vs completed sprints, compliance experience improvement vs formal conformity.

Instead of counting launched AI projects, we measure client experience improvement through AI. Instead of celebrating completed technical deployments, we track response time reduction and resilience improvement. This approach creates sustainable strategic alignment where priorities constantly change.

Without this first leg, organizations lose direction in growing complexity.

Pillar 2 - Leading Indicators: Anticipation in Uncertainty

The second leg transforms reactive organizations into predictive systems capable of navigating uncertainty. These operational milestones become early warning signals—organizational radar detecting weak signals before they become major crises.

Think Kanban applied at organizational scale: each indicator triggers action at the right moment, avoiding overproduction and waste. In banking, this means anticipating regulatory evolution, detecting team saturation signals, identifying critical system performance drift before client impact.

Companies using predictive indicators multiply their transformation success chances by 7x according to sector studies. More crucially in complex environments: they develop adaptation capacity that helps them bounce back faster after inevitable difficulties.

Without this second leg, organizations suffer complexity instead of anticipating it.

Pillar 3 - Visualization: Collective Intelligence Facing Complexity

The third leg materializes an organizational Andon adapted to banking complexity. Making problems visible to everyone transforms each collaborator into an intelligent performance sensor, capable of detecting weak signals in environments where complexity often masks dysfunctions.

This radical transparency changes the game in traditionally opaque banking: instead of hiding dysfunctions from fear of sanctions, teams expose them to resolve them faster. This translates to real-time dashboards revealing hidden interdependencies, transparency rituals about systemic blockages, organizational health metrics visible to all.

McKinsey confirms organizations with clear objective communication are 3.5x more likely to succeed in transformation. But in complex environments, the challenge exceeds communication: it's about creating collective intelligence capable of understanding and managing systems no one masters individually.

Without this third leg, complexity remains opaque until it generates crises.

Pillar 4 - Collaborative Resolution: Intelligent Distributed Autonomy

The fourth leg embodies Gemba Walks spirit applied to banking complexity: going to see in the field, where value is created and innovative solutions emerge. In banking, this means responses to complex challenges are born from combining field expertise: branches, call centers, development teams, risk managers, compliance officers.

This approach multiplies complex problem-solving capacity without creating bureaucracy. Field teams, who daily experience systemic interdependencies, often develop more relevant solutions than external consultants. 98% of companies adopting collaborative frameworks report significant transparency improvement.

Without this fourth leg, organizations remain paralyzed by centralization facing complexity.

The System Effect: Creating Hybrid Intelligence

This four-legged stool method creates virtuous feedback loops specifically designed for banking complexity. Lagging indicators reveal real impacts in environments where effects are often delayed, Leading indicators anticipate consequence cascades in interdependent systems, Visualization makes complexity intelligible for collective action, and Resolution generates distributed learning that continuously enriches the entire system.

It reconciles apparently irreconcilable tensions of modern banking management: rapid innovation versus regulatory stability, team autonomy versus systemic coherence, economic performance versus public interest mission.

From Sector Activism to Systemic Intelligence

In a sector where statistics show 70% of transformations don't reach their objectives, where challenges complexify faster than collective capacity to master them, this stool method offers an alternative to usual organizational activism observed in the industry.

It doesn't promise to make complexity disappear—that would be illusory. It proposes something more realistic and powerful: transforming an organization into a learning system capable of navigating complexity, leveraging it, and creating sustainable value even in uncertainty.

Institutions succeeding in transformations today aren't those avoiding complexity, but those developing collective intelligence to manage it. This method allows banking institutions to develop this intelligence while maintaining regulatory robustness and public interest mission.

The secret of banking resilience in a complex world isn't in excessive simplification or local optimization. It lies in the capacity to create an environment where everyone contributes to understanding and solving systemic problems, guided by indicators revealing hidden dynamics, in a system that learns and continuously improves.

🚀 CALL-TO-ACTION

Which leg needs strengthening in your organization? Is it measuring real impact, anticipating consequence cascades, visualizing interdependencies, or building distributed collective intelligence?

Share your biggest complexity challenge in banking transformation—I'd love to explore how the four-legged stool method could apply to your specific context.

Here's a brutal truth I learned managing complex product development: A bug caught during design costs $1 to fix. The same bug discovered in production? $100 minimum.

This isn't just about software. It applies to every project, every industry, every team. The real question isn't "How do we avoid problems?" It's "How do we catch them when they're still small and fixable?"

That's where the dynamic duo of macro planning and Kanban reveals its true power.

Why Your Current Planning Is Broken

Most project plans are built on a dangerous assumption: that we can predict the future with certainty. Traditional waterfall planning creates beautiful Gantt charts that become obsolete the moment reality hits.

Lean macro planning flips this script entirely.

Instead of one rigid path, it visualizes multiple scenarios:

• Plan A, B, and C for different contingencies

• Confidence levels for each component (A = validated, B = probable, C = uncertain)

• Decision points where you can pivot between scenarios

The magic happens when anything stays in "C" status too long – it automatically becomes an investigation priority. Your problem radar runs continuously.

Kanban: Your Flow Detective

While macro planning handles the strategic view, Kanban operates as your operational microscope. But here's what most people miss: Kanban isn't task management. It's dysfunction detection.

Every blocked card is a signal. Every overflowing column reveals a bottleneck. Every team member juggling multiple tasks simultaneously shows cognitive overload.

The core principle? Limit work in progress ruthlessly. When problems can't hide behind multitasking chaos, they become immediately visible to everyone.

The Integration That Changes Everything

The real breakthrough happens when these two levels connect:

From macro to micro: Your strategic plan defines the "what" and "when." Teams then "pull" the necessary tasks through their Kanban boards at the right pace and timing.

From micro to macro: Blockages surfaced by Kanban boards continuously inform macro plan adjustments. A delay detected today can trigger an alternative scenario tomorrow.

This rapid feedback loop transforms uncertainty from a threat into a competitive advantage.

The Warning Signs You're Probably Missing

In your current projects, are you noticing these early indicators?

• Kanban columns filling up abnormally

• Cards stuck for multiple days without movement

• Macro scenarios stagnating in "uncertain" status

• Team members context-switching between too many priorities

If these signals fly under your radar, you'll discover the real problems... too late.

The AI Revolution in Visual Management

Modern innovations are amplifying this approach:

• Predictive analytics anticipate bottlenecks before they appear

• Real-time dashboards automatically aggregate weak signals

• Intelligent automation frees managers to focus on anticipation

But remember: technology amplifies method. It doesn't replace it.

Your Implementation Roadmap

Step 1: Create your shared visual space (obeya). Macro plan at the top, team Kanban boards below.

Step 2: Establish A/B/C confidence scaling on your macro plan. Every "C" element needs an action plan.

Step 3: Strictly limit work in progress on your Kanban boards. Maximum one task per person.

Step 4: Ritualize feedback loops. Daily Kanban stand-ups plus weekly macro reviews.

The Ultimate Reality Check

Ask yourself this crucial question: In your projects, do you learn about major problems by reading your dashboards... or by receiving panicked calls on Friday evening?

If the second scenario sounds familiar, these underestimated tools could transform your entire approach.

🚀 CALL-TO-ACTION

The future belongs to organizations that master collective anticipation. Macro planning and Kanban, properly integrated, create this capacity for continuous adaptation without losing strategic direction.

Start with one simple change: limit your team's work in progress to one task per person. Watch how quickly hidden problems surface.

What early warning signals do you use to catch problems before they explode? Hit reply and share your best practices – I read every response.

The key? A setup inspired by Team Topologies:
🔹 Stream-aligned teams focused on business domains with real impact
🔹 A platform treated as a product, built to reduce cognitive load
🔹 Clear interaction modes: X-as-a-Service, Collaboration, Facilitation
🔹 A product-led governance model with usage-based metrics

Subscribe now

💡 The outcome: fewer silos, better complexity management, and a Time-to-Market reduced by 3x, with no compromise on quality.

This is a powerful example of what happens when we build learning, autonomous organizations that structurally reflect their desired product architecture (yes, that’s Conway’s Law — in reverse! 😉).

In a world where speed and complexity are the new normal, redesigning our orgs may be a better bet than trying to “scale agile” with brute force.

Have you led or experienced such a transformation? Would love to hear your thoughts and lessons learned 💬👇

(NB: the linked article is in French)

#TeamTopologies #LeanEngineering #ProductLed #DigitalTransformation #PlatformThinking #TimeToMarket #OrgDesign

Today, we are entering the Cognitive Era—an era where intelligence itself becomes an asset, distributed across humans, platforms, AI agents, and ecosystems.
But let's be careful with oversimplifications.

It's Not About "AI Transformation"—It's About Transformation Through AI

The real challenge is not about adding AI to existing processes or launching isolated AI initiatives.
It's about reimagining our organizations, value chains, decision-making processes, and operating models through the lens of AI.

This requires a mindset shift, far from the usual tech-centric approaches where the journey starts with a model or a use case, hoping to eventually deliver impact.

Lean-AI: A Discipline for Meaningful, Sustainable, and Systemic Change

This is where Lean-AI comes in.
Not as a buzzword, but as a discipline that applies Lean principles (inspired by the Lean Tech Manifesto and Artefact's Lean-AI framework) to the entire AI-powered transformation journey.

Lean-AI means:

• Starting from the business problem, not the algorithm.

• Eliminating the seven specific wastes of AI projects: unnecessary data collection, disconnected models, never-ending PoCs, forgotten industrialization...

• Building frugal, iterative learning loops, where data is useful, contextualized, and minimal from day one.

• Establishing cross-functional governance—blending business, data, tech, compliance, and design stakeholders right from the ideation phase.

• Operationalizing AI from sprint one, ensuring Proof of Value is fast, focused, and directly embedded into business processes.

• Designing AI value chains as Lean value streams—optimized, monitored, continuously improved.

From Tech-Centric Initiatives to Lean-AI Transformations

Lean-AI is not a project methodology.
It is a company-wide discipline.

It forces us to:

• Break silos;

• Demystify AI as the sole territory of data scientists;

• Embed it as a transversal, systemic lever of transformation.

This is how AI becomes not just a technology, but a catalyst for business impact, operational excellence, and sustainable, responsible transformation.

Transformation through AI is not about adding AI to the organization—
It's about reorganizing the company around the new flows, decisions, and customer value that AI enables.

And this transformation must be both progressive (through Lean small steps) and radical (challenging historical organizational patterns and mental models).

My Core Belief: Well-Integrated AI Is a Vector of Collective Empowerment, Not Alienation

This means:

• Making invisible systems visible;

• Embracing organizational discomfort;

• Positioning AI as a lever for simplification, team empowerment, and customer value alignment.

The AI revolution will not be technological.
It will be organizational, cognitive, human, ethical—and Lean.

#HybridIntelligence #AITransformation #LeanThinking #CognitiveEnterprise #ResponsibleAI #HumanCenteredAI #FutureOrganizations #ProductLedGrowth #AIForGood #DigitalLeadership

My answer is simple: neither better nor worse. Just... different 😎

👉 It's not a competition.
👉 It's not a rivalry.
👉 It's not the same context, not the same challenges, not the same metrics.

• DSI is the foundation, industrialization, resilience.

• Digital Factory is about customer impact, fast iterations, usage-driven innovation.

They must coexist intelligently, with adapted operating models, clear interfaces, and strengthened feedback loops.

This has been one of my key battles over the past two years, and it has paid off:
✔ Moving away from opposition mindsets.
✔ Establishing a culture of complementarity.
✔ Creating the right porosities between teams.
✔ Respecting each other's constraints while staying aligned on customer impact.

💡 This approach? Let's call it "reasoned hybridization": orchestrating platforms, organizations, human agents & AI without trying to oversimplify what is... complex.

And if you've been following me for a while, I already talked about this complementarity a few months ago

🔗 For those interested, I share a concrete feedback on this transformation at Bpifrance in the interview 👇

Next time someone talks about competition, remember: it's two sides of the same coin, two energies that, when well-orchestrated, allow our organizations to reinvent themselves.
And by the way, at Bpifrance, this coin has a name: Bpifrance.io

#DigitalLeadership #HybridIntelligence #DSI #DigitalFactory #TeamTopologies #IntelligenceEconomy #NoComparison

"Hey Siri (or Alexa, or any other), I need €300,000 to fund my business growth."
"Of course, Nicolas. Based on your last three years of activity and your upcoming objectives, I’ve arranged €300,000 in financing — 50% from your main bank, and 50% from Bpifrance. Does that sound good to you?"
"Perfect, thank you."
"Very well, the funds are now available in your account."

This exchange may sound futuristic, but it’s getting closer to reality every day.
Not thanks to magic. But thanks to a solid ecosystem of data, APIs, security, fine-tuning, and intelligent agents designed to act — not just answer.

Welcome to the age of AI agents: systems that reason, plan, decide, and interact, in real-time, on our behalf.

🌐 Agents: Autonomous, Yes — But Never Alone

Agent-based systems are emerging as the next evolution of digital experience — not just answering questions, but actually doing things for us.

But here’s the truth: autonomy is an illusion without the right foundation.

• No clean, up-to-date, well-governed data? Your agent is flying blind.

• No secure, documented, scalable APIs? Your agent is powerless.

• No fine-tuned instruction logic? Your agent is unpredictable.

• No access rights management? Your agent is dangerous.

• No feedback loops? Your agent is useless after the first mistake.

In short: by default, an agent is deaf, mute, and blind.
It’s only through a deliberate ecosystem of engineering, governance, and design that it becomes useful — and safe.

🧠 Introducing AX: Agent Experience

We’ve built careers and systems around UX (User Experience).
We’ve learned to care about DX (Developer Experience).

Now we need to talk about AX — Agent Experience.

AX is about designing environments where agents can act reliably, efficiently, and ethically.
It’s the missing piece between technical potential and operational value.

A solid Agent Experience includes:

• Access to structured, secure, versioned APIs

• Clean, governed, context-rich data

• Clear instructions and task boundaries

• Observability and feedback mechanisms

• Escalation logic for ambiguous decisions

• Regular fine-tuning and safety testing

Just like we design for users, we must now design for agents.

🏗️ Agent-Ready by Design: Rethinking Our Organizations

Agentization isn’t just a technical shift — it’s an organizational one.

It impacts how we design teams, workflows, products, and governance.
In this context, the Team Topologies framework is more relevant than ever:

• Stream-Aligned Teams: delivering direct user value and interfacing with agents.

• Platform Teams: building the APIs, data contracts, and services agents will depend on.

• Enabling Teams: driving adoption and experimentation with new agent capabilities.

• Complicated Subsystem Teams: managing deep logic like policy engines, scoring models, or natural language pipelines.

Just as Conway's Law taught us, our system architecture will mirror our team structure. If we want agent-ready systems, we need agent-ready organizations.

⚖️ Power + Responsibility = Long-Term Value

AI agents are not just a shiny new feature.
They change how we build, how we govern, and how we serve users.

At Bpifrance, we’re already witnessing this shift:

• Our platformization strategy allows modular, API-based integration.

• We treat data as a product: owned, documented, accessible.

• We build product-led teams, obsessed with user impact and feedback.

• We ensure ethical oversight, especially around automation, explainability, and data privacy.

Agentization is not a shortcut.
It’s a systemic transformation — and a long-term investment.

🚀 The Real Question Isn’t “Can We Do It?” — It’s “Can We Do It Well?”

The era of agents has begun. The question isn’t whether we’ll use them — it’s how responsibly, how strategically, and how usefully we’ll deploy them.

An agent isn’t a tool. It’s a partner in execution.
And just like a team member, it needs access, instructions, feedback, and trust.

The real revolution won’t be about apps — it will be about organizations that know how to collaborate with intelligent agents.

At first glance, you might think the balloon was eliminated, that the problem was solved. In reality, nothing has changed. The system itself — the waterfall — continues to produce the same effect. The balloon is simply recycled in an endless loop.

This is exactly what happens in our organizations when we fix symptoms without addressing the root causes.

What this metaphor really shows us

Every time we "fix" a problem without deeply understanding its root cause,

• The problem will come back.

• It may return even faster.

• It may come back in an even more costly form.

In Lean, we follow a fundamental principle: Built-in Quality.

Quality is not a final control at the end of the production line, nor a last-minute patch. Quality must be designed, built, and verified at every step. Every operator, every team, every developer is a co-creator of quality.

As soon as an anomaly is detected, it must be:

• Seen through a transparent visual system (Andon, visual management),

• Immediately stopped to prevent the defect from spreading (Jidoka),

• Corrected at the source by finding the root cause (using the "5 Whys", A3 Problem Solving).

Otherwise, we are doomed to endlessly recycle the same mistakes, like that balloon trapped in its waterfall.

Why problems remain invisible without going to the Gemba

The first mistake managers, engineers, and project leaders make is believing they understand problems from their office.

Reality is always found on the ground.

In Lean, we talk about the Gemba: the real place where value is created or lost.

• Go see.

• Truly see.

• Observe without filters.

• Understand the gap between what we believe and what is really happening.

Gemba is the only place where we can perceive systemic dysfunctions. At the Gemba, we see:

• Hidden waste,

• Team overload,

• Process inconsistencies,

• Improvement opportunities that no spreadsheet can reveal.

Without Gemba, we are only guessing the causes. And in 90% of cases, we are wrong. Without Gemba, we treat symptoms and maintain the cycle.

Why Built-in Quality has become non-negotiable

Today, production flows — whether in manufacturing or software development — move so fast that an undetected defect has exponential consequences.

A bug left in a CI/CD pipeline can block an entire delivery chain. A small quality gap in a feature can ruin a user experience and erode trust.

We no longer have the luxury of discovering problems at the end.

In a Built-in Quality culture:

• Every team is responsible for quality at its own level.

• Every anomaly becomes a learning opportunity.

• Every process is designed to prevent errors, not just to fix them afterwards.

This is a profound shift: from after-the-fact control to proactive responsibility at every moment.

Taking action: How to break free from the endless cycle

For our organizations to truly improve, we must:

✅ Make problems visible (visual management, Andon).

✅ Create conditions for immediate problem stopping (Jidoka).

✅ Train every team to reach the root cause (5 Whys, A3).

✅ Design detection and error-proofing systems from the start (Poka-Yoke).

✅ Visit the Gemba frequently to observe with humility.

✅ Encourage experience sharing and regular feedback to fuel continuous improvement.

Quality is not decoration. It is a daily discipline. It starts with the willingness to face reality, to understand, to learn, and to act without delay.

In conclusion:

Don't chase problems. Dry up their source.

This is how we create products, services, and organizations that are truly resilient. Organizations capable of growing without compromising trust or delivered value.

✨ And you, in your projects, do you still see balloons coming back? What are you waiting for to go to the Gemba?

#Lean #BuiltInQuality #Gemba #ProblemSolving #ContinuousImprovement #Leadership

Yesterday, I became a marathon runner.
And it wasn’t just a personal milestone — it was a vivid, physical reminder of what it takes to lead in times of change.

For 5 hours and 12 minutes, I ran through the streets of Paris. 16 weeks of training, 407 kilometers logged, and dozens of early mornings led to that moment. But this race wasn’t just about running. It was about showing up, again and again, even when it’s hard.

Sound familiar? That’s because leading a Digital Factory — or any team in a fast-moving world — often feels like a marathon.

Running, Leading — Same Principles

Here’s what I (re)learned out there:

• Set a vision: Whether it's a race or a roadmap, clarity of purpose pulls you forward.

• Pace yourself: Not everything is a sprint. Sustainability matters.

• Push through the wall: Around kilometer 26, everything hurt. In transformation, the “wall” is that moment where resistance peaks and momentum dips. Leadership is what carries you past it.

• Celebrate progress: Every kilometer, every small win, every milestone — they count. And they’re better when shared.

The Real Finish Line

This marathon was more than a physical achievement. It reactivated something deep: my belief in long-term commitment, in the value of presence through discomfort, and in the strength of the collective.

I couldn't have done it without the support of those around me — just like we never transform alone in business.

To everyone running their own race — whether you're building a product, shifting an organization, or simply trying to lead with intention — keep going. You're doing something great.

See you at the next starting line. 🏁

About twenty years ago, I used to rely on Gantt charts for just about everything. They were my go-to framework for structuring and planning a project: neatly aligned bars, milestones, and deadlines. But the moment you hit “Print,” reality would swoop in, rendering that beautiful diagram obsolete at the first unforeseen constraint.

Since then, we’ve come a long way: we transitioned to Agile, reorganized our teams based on Team Topologies principles, and now depend on Lean Engineering to bring clarity to complex environments. Yet one observation remains: our processes are often built on solutions we’re already familiar with. In today’s ever-evolving world, though, we need to be ready to embrace the unknown.

Processes: Rooted in What We Know, Challenged by What We Don’t

1. We rely on our existing knowledge to build processes
   It’s natural—we leverage past experiences, best practices, and lessons from both successes and failures. That’s the strength of an organization: we don’t start from scratch every time. We draw on what’s proven to work.

2. But today, we operate on shifting ground
   The market, technology, and customer needs change rapidly—often in unpredictable ways. That’s why rigid frameworks, whether Gantt or something else, quickly show their limits. The moment we step out of a “known circuit,” we find ourselves improvising, exploring, and adapting our processes.

3. Agility: A Guide, Not a Magic Bullet
   Being Agile isn’t just about ceremonies (daily stand-ups, reviews, retrospectives) or waving the “Scrum Guide” around. It’s about accepting that each iteration must confront reality. Continuous adaptation also involves testing new ideas, measuring their impact, and adjusting quickly. The cultural foundation is as important as the methods themselves.

4. Team Topologies: Structuring Teams for Value Delivery
   Organizing teams to be autonomous and domain-focused or product-critical reduces handovers, enables faster decision-making, and fosters a closer connection to the end user. The result: more responsiveness and fewer blind spots.

Lean Engineering: Keeping Clarity in the Workflow

If Gantt charts are no longer our static reference, how do we maintain visibility and alignment? For me, the answer lies in Lean Engineering. It’s a comprehensive approach that aims to:

• Identify value for the client (or the end user),

• Eliminate waste in processes,

• Streamline flows from end to end,

• Measure and improve continuously.

Instead of locking down a rigid plan, we strive to make the process sufficiently visible and adaptable so everyone knows what to do, when, and for what purpose. Real-time metrics, collaboration between teams (through short, effective rituals), and the ability to pivot quickly all underpin a living, breathing plan.

Conclusion: From Gantt Experience to Navigating the Unknown

Twenty years after my first Gantt charts, I realize the key isn’t to ban planning but to use it in service of a dynamic, value-centered approach. Processes are naturally built on proven solutions to known problems. But for everything we don’t know at the outset—and there will always be something—Agility, Lean Engineering, and teams organized according to Team Topologies principles let us move forward with more confidence.

Ultimately, what truly makes the difference is our ability to embrace uncertainty without losing sight of our end goal: delivering tangible value. The next time someone hands me a printed Gantt chart, I’ll treat it not as an absolute truth but as a starting point—one that will evolve as we make new discoveries. That’s the essence of Agility and Lean: recognizing that the unknown is the norm and organizing ourselves to leverage it.

That’s how, one day, we move from “Your Gantt Chart Holds True… Until You Print It” to “Your Process Is Sound… Until the Unknown Appears.” So why not be prepared?

Subscribe now

Why do a Gemba Walk in a digital environment?
Because not everything shows up on dashboards. Because listening directly to the teams is worth more than any report.

Gemba Walks are moments of real connection: • With the teams
• With the daily pain points
• With the opportunities to improve together

Not to audit. Not to control.
But to understand, learn, and spark tangible improvements.

And for us, it’s already making a big difference.

What about you—where are you walking?

#Lean #GembaWalks #DigitalFactory #Leadership #ContinuousImprovement #VisualManagement

In large organizations, we often spend our time arbitrating, prioritizing, protecting product vision... and saying "No." A strategic "No," of course. But also a "No" which, if poorly communicated, can generate tension, frustration, and a loss of trust.

What if, paradoxically, the best way to explain a "No" was to start by saying "Yes"?

The Power of the "Strategic Yes"

This idea, shared by Rémi Guyot (former CPO of BlaBlaCar and co-author of Discovery Discipline), is based on a simple principle: 👉 Say "Yes," not to accept everything, but to open a space for exploration, discussion, and learning, so that stakeholders can align around the best decision — which may ultimately be a "No," but a "No" they understand.

In complex environments, where ideas multiply and priorities collide, an immediate "No" can feel like a rejection. The "Strategic Yes" helps avoid this barrier by establishing a mindset of investigation: listen, test, challenge, measure.

It is a posture of humility, support, and pedagogy.

Why Say "Yes" Before Saying "No"?

In real organizational life, this "Yes" is not a firm commitment. It is an exploratory Yes, framed and responsible, allowing ideas to be evaluated objectively before burying or prioritizing them.

Two possible outcomes:

👉 The idea proves real potential: We nurture it, integrate it into the roadmap with an assumed and aligned "Yes."

👉 The idea shows its limits: The facts speak for themselves, stakeholders understand why it won't be pursued.

In both cases, we avoid ego struggles, opinion battles, or political frustration. We create a collective learning process.

The 5 Principles Behind This "Strategic Yes"

This posture is not improvised. It is rooted in a structured approach to product leadership, based on 5 key principles:

1️⃣ Obsession with User Impact and Business Value

A product leader's compass is not personal preference but impact:

• Does the idea serve users?

• Does it create measurable value for the business?

The "exploratory Yes" consists of testing these hypotheses quickly and at low cost: a mini POC, a user test, a limited A/B test...
This is the concrete application of Lean Engineering: minimizing waste, maximizing learning.

2️⃣ Mastering Complexity

In transformational contexts, organizations are overwhelmed by complexity: legacy systems, silos, technical debt, competing priorities.

Too often, the reflex is to say "No" out of fear of adding complexity.

But modern organizations — inspired by Team Topologies — know that complexity can be managed, not avoided.
Structuring teams to enable "Yes" without chaos is a powerful lever.
👉 Agile, modular structures with fast testing environments and autonomous teams allow exploration without breaking things.

3️⃣ Hybridization of Intelligences

This "Yes" also acknowledges the multiple forms of intelligence involved:

• Human intelligence (business intuition, field knowledge)

• Collective intelligence (cross-functional collaboration)

• Algorithmic intelligence (data, AI)

By agreeing to explore an idea, we allow business, tech, data, and design expertise to intersect, challenge, and enrich the initial proposal.
We foster the emergence of stronger, more creative solutions.

4️⃣ Sustainability and Ethics

Saying "Yes" should never mean blind acceptance or compromise.

Each exploration must respect:

• Human sustainability: avoiding team overload and burnout.

• Technical sustainability: testing without degrading quality or adding debt.

• Product ethics: not saying "Yes" to ideas contrary to company values or commitments.

A "Yes" that leads to an argued "No," based on data, user feedback, or identified risks, is far more powerful than an authoritarian refusal.

5️⃣ Learning Organization

Finally, this posture is a cornerstone of a learning organization.

Each "exploratory Yes" becomes an opportunity:

• To collectively improve understanding of the product and the market.

• To involve stakeholders in a discovery process.

• To develop product maturity within teams and decision-makers.

In Lean Engineering, this is called continuous improvement (Kaizen): every decision is a learning cycle.
The "Yes to explain the No" is a large-scale learning tool.

🎨 How to Apply It Practically?

Here are a few ways to move from principle to action:

🔹 Clarify the conditions of the "Yes"
Make it clear from the start that you agree to explore, subject to testing, evaluation, and specific criteria.

🔹 Frame the effort
Don't let exploration turn into an endless project. A MVP, a prototype, or a quick test is often enough to objectify things.

🔹 Equip your teams
Create the right environment: rapid testing tools, autonomous teams, streamlined processes.

🔹 Communicate the learnings
Whether it leads to a "Yes" or a "No," share the outcome of the exploration. Turn every decision into a collective learning moment.

🚀 In Summary

The role of a product leader is not to say "No." It is to guide, nurture, and enlighten.

Saying "Yes" to explain "No" means rejecting defensiveness in favor of pedagogy, experimentation, and alignment.
It means turning tension into cooperation.
It means making "No" a shared learning experience, not an imposed veto.

In the digital realm, the projected decrease (up to 25%) in Google search volumes by 2026 is more than just a statistic: it signals a major shift toward more diverse usage patterns (chatbots, specialized platforms, voice assistants, etc.). At the same time, agent-based AI is emerging, allowing agents to perform tasks on our behalf. The result? Fewer direct interactions with traditional user interfaces (UI) and a growing number of automatic integrations driven by AI.

Toward a 25% Drop in Google Search Volumes: A Powerful Sign of Change

According to Gartner, Google may lose up to 25% of its search volume by 2026. In other words, this channel’s dominance is waning, while new access and discovery points (conversational apps, alternative search engines, vertical platforms) gain ground. This fragmentation of search goes hand in hand with the rise of agent-based AI, which enables many queries and processes to be automated.

In response, businesses must transition from a “Google-centric” SEO strategy to an approach called “Search Everywhere Optimization,” meaning they must optimize their presence across multiple channels, including those powered by AI. This shift profoundly affects digital strategy: instead of relying on a single entry point, organizations now need to ensure a presence on a range of platforms and potential agents.

From UI to AX: A Profound Transformation

Until now, most efforts focused on continuous improvement of user interfaces (UI). But the Agent eXperience (AX) phenomenon is changing the game. Now, a user can submit a request to an AI agent, which in turn accesses our services (via APIs) without ever using the screen we originally designed.

This does not mean the UI disappears entirely: some audiences still prefer a visual, explicit journey. Nevertheless, being “agent-compatible” has become crucial. Put differently, our digital products must be exposed and structured (data, APIs, permissions) so that an AI agent can easily connect.

A Renewed Role for Product/UI Teams

This evolution does not invalidate the importance of Product/UX/UI teams—it expands it. They will:

• Maintain and enhance direct user experiences for those who want or need a traditional interface;

• Design the conditions for smooth interaction with AI: how our services are described, “broken down,” and controlled so an agent can connect reliably.

Ultimately, the business value still lies in our products; only the access method changes. Fluidity, consistency, and reliability of the response (even via an agent) remain at the heart of these teams’ responsibilities.

The Platform Foundation: A Strategic Pillar in the Age of Agent-Based AI

To handle both fragmented search and agent-based usage, organizations must rely on a robust, interoperable platform foundation (architecture, APIs, data, cloud). Key considerations include:

• A growing share of users bypasses Google, turning to other channels or AI integrations;

• AI agents require strong, consistent, and secure APIs with continuously updated data;

• In a fragmented journey, a user might begin their search via a voice assistant and then continue or confirm it through a different engine.

Over time, achieving “Search Everywhere Optimization” means treating our data and services as true internal “products,” exposed via documented APIs that are easy to integrate. In a Lean context, this entails identifying inefficiencies (slowness, redundancy, poor data quality) and continuously pursuing technical excellence, all to support seamless connections to various agents.

Team Topologies and Lean: Keys to a Responsive Organization

This transition toward AX is not just a technical challenge; it also requires organizational agility. Team Topologies and Lean principles play a crucial role here. On one side, “stream-aligned” teams focus on value creation (UI, conversational flows, APIs), while “platform” teams provide shared infrastructure. On the other, Lean principles (continuous improvement, user focus, respect for people) ensure rapid adaptation without causing upheaval.

In practice, close collaboration between Product and Tech speeds adjustments: if the agent struggles with something, the team detects and fixes it. Pull flow and experimentation help refine APIs or user journeys incrementally, rather than attempting a risky big-bang change. Likewise, skill development becomes essential, as orchestrating AI calls for new expertise in conversational API design, permissions management, and multi-channel oversight.

Lean: A Core Value System for Navigating Major Change

Embracing Lean thinking during this pivotal shift brings multiple advantages:

• Quickly identifying user needs and how they evolve (greater AI usage, fewer manual steps);

• Iterating in small increments to test agent compatibility, measure outcomes, then improve;

• Removing barriers (latency, poor data structure, redundant interfaces) to smooth the transition;

• Engaging teams at ground level (Product, Tech, UX, Data) in ongoing improvement cycles.

In a world where everything intertwines (multiple search engines, conversational apps, generative AI), only a Lean-based approach allows fast response, real value delivery, and consistent oversight.

Conclusion: A Paradigm Shift

Ultimately, the possible drop in Google Search (up to 25%) is merely a symptom: search itself is evolving, fragmenting, and sometimes happening invisibly via agents. AX (Agent eXperience) is becoming a channel in its own right, and the role of Product/UI teams is now to design “invisible” experiences for users—activated through AI.

In concrete terms, this calls for:

• Robust platforms and APIs presented via a “productized” model;

• Product/UX teams with AI knowledge, able to craft content or processes consumable by an agent;

• A Lean, modular organization that adjusts priorities based on feedback and emerging opportunities.

This is no longer a mere evolution, but a fundamental change in paradigm. By embracing this dynamic—being present across all touchpoints (classic search engines, AI ecosystems, vertical platforms, conversational interfaces)—those who anticipate and orchestrate “Search Everywhere Optimization” will gain a competitive edge, driving both innovation and relevance in tomorrow’s digital landscape.

Throughout my two decades of experience in the digital realm, I've understood a fundamental truth: an effective leader isn't defined so much by the battles they fight as by those they consciously choose not to engage in.

This particularly intense week reminded me of this lesson with striking clarity. Between deploying new features, technical architecture challenges, and budget arbitrations, opportunities for confrontation were abundant. Yet it's precisely in these moments of intensity that discernment becomes our greatest ally.

Cognitive economy: a precious and limited resource

Our cognitive capacity is a limited and precious resource. As all agile methodologies emphasize, and as Lean pushes forward, isn't the biggest waste for a company to offer products that aren't what the customer actually needs?

This question brings us back to the essentials. Each battle we fight consumes cognitive energy that's no longer available to identify and solve problems that truly bring value to our customers.

Leading a Digital Factory with 300 employees spread across various disciplines (product, tech, cloud, UX, data) as I currently do at Bpifrance means facing a multitude of potential challenges daily. The temptation to optimize everything, perfect everything, control everything is great. But this approach is a trap.

Differentiating signal from noise

One of the most crucial skills I've developed is the ability to distinguish signal from noise - to identify among the multitude of potential problems those that truly deserve our collective attention.

The Lean Tech Manifesto, written by Benoit Charles-Lavauzelle and Fabrice Bernhard, offers an illuminating perspective on this subject. The first pillar it identifies is "Value for the customer as the compass point of all activities." This is the compass that should guide our choice of battles.

In practice, this means that every potential confrontation, every disagreement, every organizational friction must be evaluated through a simple but powerful question: "Will solving this problem create significant value for our users?"

The Team Topologies approach: clarifying responsibilities to avoid unnecessary battles

The Team Topologies model offers a particularly relevant framework for avoiding territorial conflicts that consume so much energy in our organizations.

By clearly defining four types of teams (stream-aligned, platform, complicated-subsystem, and enabling) and their interaction modes (collaboration, X-as-a-service, facilitating), this model helps clarify responsibilities and expectations. I actually discuss this in this article.

I've observed that many "battles" emerge precisely from gray areas where responsibilities overlap without being clearly defined. The Team Topologies approach doesn't eliminate all conflicts, but it makes them more productive by centering them on value delivery rather than territorial issues.

Gemba: seeing the reality on the ground

Another fundamental Lean principle that helps me judiciously choose my battles is Gemba - the idea of directly observing where work happens, where value is created.

Too often, disagreements and tensions between teams arise from divergent perceptions of reality, fueled by abstractions and unverified hypotheses. Going to the field, directly observing users, analyzing real usage data - these practices help bring discussions back to concrete facts rather than opinions.

At the Digital Factory, we've instituted regular "Gemba walk" sessions where product and tech managers together observe users and data. This simple practice has considerably reduced unproductive discussions by creating a common foundation of indisputable facts.

Capitalizing on knowledge: avoiding reinventing the wheel

One of the major types of waste, which encompasses almost all others, is having to reinvent everything repeatedly without properly capitalizing on acquired knowledge.

This observation is particularly relevant to our topic. How many "battles" in our organizations are actually recurring confrontations about problems that have already been encountered and theoretically solved?

Implementing effective mechanisms for knowledge capitalization and sharing is therefore an essential strategy for reducing unnecessary friction. In my teams, we've developed a rigorous discipline of documenting decisions and their justifications, which often allows us to avoid reopening debates that have already been concluded.

The art of Obeya: making visible to avoid conflicts

One of the most powerful tools I've adopted to reduce unproductive friction is Obeya - this Japanese practice of gathering all crucial information about a project in one space.

Obeya allows us to display all the elements on which teams are working. This radical transparency considerably reduces misunderstandings and erroneous hypotheses that are often at the origin of conflicts.

By making our indicators and major ongoing changes visible to everyone, we create a common language that transcends specialties and silos. Discussions cease to be confrontations of opinions and become collective analyses of shared facts.

Redefining our priorities in the face of technological disruptions

The question of which battles to fight takes on a new dimension in an era where AI is profoundly transforming our professions and where consumption patterns of our products are undergoing accelerated mutations.

In this context of transformation, choosing one's battles also becomes an exercise in foresight. Some battles of yesterday, which seemed essential, become secondary in the face of new priorities imposed by these changes.

At Bpifrance, we're finding that the emergence of generative AI is radically transforming the expectations of our users, entrepreneurs, and partners. Features that previously required weeks of development can now be automated. User journeys we thought were optimal are suddenly obsolete in the face of new behaviors.

This reality forces us to constantly reevaluate our portfolio of potential "battles." Projects that seemed priority six months ago may today represent a sub-optimal investment of our limited resources.

The question is no longer just "Which battles are worth fighting?" but also "Which battles will still be relevant in six months, one year, three years?"

Conclusion: the leader as a cultivator of constructive battles

While choosing one's battles is essential, it doesn't mean avoiding all forms of conflict. Some confrontations are necessary and productive - those that push us to question our assumptions, refine our understanding of real needs, and innovate.

As Bpifrance's Group CIO Lionel Chaine often reminds us, there are healthy conflicts - this "abrasion" between teams that, when well channeled, becomes a powerful engine for innovation and improvement. This constructive friction allows for confronting ideas, refining solutions, and strengthening our collective resilience.

The true art of leadership isn't so much about avoiding battles as creating the conditions for them to take place in a constructive framework, centered on value, anchored in facts, and oriented toward collective learning.

As the Lean Tech Manifesto affirms, our ultimate goal is to "enable the organization to learn continuously to develop resilience to change." This capacity for continuous learning is precisely what will allow us to meet the increasingly complex challenges that the digital world holds for us.

I would be very curious to know your own strategies for judiciously choosing your battles in your respective contexts!

#LeanManagement #Leadership #TeamTopologies #DigitalTransformation #ProductStrategy #TechLeadership #ChooseYourBattles #AITransformation