In Episode 192 of the AI After Work (AIAW) Podcast , we’re joined by Serge de Gosson de Varennes, Ph.D, VP of Data, Analytics & AI at Paradox Interactive, for a conversation that exposes a weakness in how organisations judge AI progress: people can become dramatically faster while the business gains very little.
A developer produces more code. An analyst generates more reports. A marketing team creates more content. Each improvement looks convincing on its own. Yet someone must still review the code, interpret the reports, approve the content, and turn those outputs into something customers value. If those activities remain unchanged, the organisation may simply accumulate work faster.
Serge describes this through a familiar image: a traffic jam moved further down the road. The obstruction has changed location. The journey has barely improved.
For leaders trying to move beyond AI experimentation, this observation changes the agenda. Transformation requires examining how work travels through the organisation, where decisions happen, how capabilities spread, and what people do with the capacity technology releases.
What makes Serge’s perspective particularly useful is its setting. Paradox is already a technology business. This discussion concerns skilled developers, analysts, and creative teams working inside a software company. Technical competence gives them powerful tools, but it does not automatically solve the organisational problem of using those tools together.
Across the conversation, a deeper argument emerges: lasting AI value depends on the company’s ability to convert individual capability into collective performance. That requires a more demanding definition of progress than adoption dashboards usually provide. 
When Faster Work Creates a Slower System
Consider Serge’s example of AI-assisted development. Generating substantially more code can feel like an obvious productivity breakthrough. However, if review capacity remains fixed, the queue grows. Developers spend more time evaluating contributions, integration becomes harder, and the organisation may ship no faster.
The useful unit of measurement therefore expands from a task to the complete journey from request to delivery. Generation speed matters within that journey, alongside testing, review, release, and maintenance. Improving one stage creates business value when the surrounding system can absorb and use the improvement.
DORA’s 2025 research provides relevant context. It describes AI as an amplifier of existing organisational strengths and weaknesses, arguing that returns depend heavily on the underlying organisational system. Better tools increase the importance of sound delivery practices.
This suggests a practical shift in executive questioning. Alongside asking how much faster a team works, leaders should investigate what happens next. Has customer delivery accelerated? Has rework increased? Are decisions becoming easier, or are people facing a larger volume of material to evaluate?
These questions also change accountability. A department can achieve its local productivity target while increasing the burden elsewhere. If every team reports its own gains separately, the organisation can celebrate improvements that disappear at the handoffs.
My reading of Serge’s argument is that AI transformation needs shared responsibility for the complete outcome. Otherwise, the company rewards the creation of work more reliably than its completion. The emerging bottleneck may be coordination, judgment, or approval capacity, even when the original intervention focused entirely on production.
Useful Information Has an Expiry Date
One of the most concrete examples concerns reporting after a game release. Serge explains that a report arriving after 30 days can miss the period when a studio could act. By the time the analysis is ready, attention and resources have moved to the next development priority.
The data may be accurate. The report may be well designed. Its opportunity to influence the relevant decision has passed.
He describes automating reporting so that teams can receive an initial view on the first day when needed, followed by reports at seven, fifteen, and thirty days. The earliest report cannot contain everything the later report will know. Its advantage is arriving while action remains possible. The workflow generates material that people review before distribution.
This illustrates a dimension of data value that deserves more attention: the relationship between information quality and the remaining opportunity to act. More complete information delivered late can be less useful than a qualified early signal delivered within the decision window.
That does not justify careless reporting. Early findings need clear limits, appropriate interpretation, and subsequent revision. It does mean that timeliness belongs in the definition of quality.
For a data leader, the implication is significant. Asking how quickly a report can be produced is only part of the problem. The stronger starting point is understanding when the recipient must make a decision and what evidence would improve it.
That moves analytics closer to the operating rhythm of the business. It also makes the consequences of delay visible: missed interventions, repeated mistakes, and opportunities that expire while information is still being prepared.
The Most Valuable Dashboard May Be the One You Retire
Serge applies a similarly direct test to existing analytics: is it useful, and will anyone act on it? If the answer is no, he sees little reason to keep producing it.
This sounds straightforward, yet it challenges an uncomfortable organisational habit. Reports become recurring obligations. Dashboards acquire owners, pipelines, and maintenance routines. Their continued existence begins to substitute for evidence of their usefulness.
He describes examining which dashboards people view and then asking the harder question of what people actually do with them. A view count indicates attention. It provides limited evidence of impact.
The larger change at Paradox, in his account, is positioning analytics as a business partner. Analysts participate in conversations about features, campaigns, and decisions, developing an understanding of the problem before deciding what to produce.
That relationship matters because stakeholders cannot always specify the right analytical intervention. They may request a familiar format because they lack the language to describe a different possibility. An analyst who understands the context can help reformulate the request.
With AI, this becomes more consequential. When generating another dashboard becomes easy, the supply of dashboards can expand without improving decision-making. Cheap production can conceal the continued cost of attention, interpretation, and maintenance.
The leadership opportunity is to make retirement part of the operating model. Removing an unused report releases capacity and reduces distraction. It also reinforces a valuable principle: analytical work earns its place through the decisions it supports. A growing inventory of outputs should never become the default evidence that the function is succeeding.
Governance That Makes Local Innovation Travel
Serge’s approach to governance addresses a tension many enterprises experience. Teams understand their own problems and need freedom to experiment. The organisation also needs security, visibility, and some consistency in how solutions develop.
His example is ten teams solving the same problem in ten different ways. Each initiative may make sense locally. Together, they create duplication, incompatible approaches, and a maintenance burden that nobody intended.
His response combines local agency with shared capabilities. Teams identify and solve problems close to their work. Common standards, reusable skills, and the supporting controls around agents help those solutions become useful beyond their original setting.
He describes an initiative registry, an AI steering group, and an innovation forum. The steering group’s involvement is deliberately limited, with intervention focused on economic and security risks. The aim is to provide direction and visibility while preserving room for teams to build.
The distinctive insight is that governance can increase the distance an innovation travels. A useful solution becomes more valuable when another team can discover, understand, and reuse it without recreating the surrounding foundations.
That gives governance a constructive purpose. Alongside managing exposure, it helps the organisation retain the benefits of experimentation.
My interpretation is that reuse deserves a place in transformation measurement. How often does one team’s work reduce another team’s effort? How quickly can a proven approach spread? Where does a local success remain trapped because nobody can operate it elsewhere?
Those questions reveal whether the enterprise is becoming collectively more capable or simply hosting an expanding collection of individual experiments.
The distinction matters as successful experiments multiply. Each new tool introduces an obligation to support it, explain it, and decide when it should change. Shared capabilities allow teams to distribute some of that effort. They also make improvements cumulative: a better control, clearer instruction, or proven integration can benefit several applications. This is how the learning from one experiment starts to reduce the cost and uncertainty of the next.
Saved Time Needs a Destination
Serge raises a question that often disappears from AI business cases: where does the saved time go?
An employee completing a task faster creates potential capacity. The business benefits when that capacity improves something it values: delivery, customer service, experimentation, quality, or growth. The link needs to be made explicit.
This is especially important when organisations translate estimated hours saved directly into financial returns. Time can be released in small fragments, absorbed by coordination, or spent producing additional work that creates little benefit. An estimated saving is an input to a business case, rather than sufficient proof of the result.
Research on developer productivity also shows why measurement requires care. METR’s early-2025 study found that experienced open-source developers took 19% longer with the AI tools tested. Its February 2026 update judged that developers were likely benefiting more from newer tools, while explaining that selection effects made the follow-up estimates unreliable. The evidence concerns particular settings and tools; it resists a universal productivity multiplier.
For leaders, the practical response is to connect released capacity to a deliberate operating choice. If preparation takes less time, will people speak with more customers? If testing becomes easier, will the team explore more failure scenarios? If analysis accelerates, will decisions improve before the opportunity closes?
This is a management responsibility. Employees need priorities, authority, and room to use the capacity well. Otherwise, a company can purchase powerful assistance while leaving the organisation’s allocation of attention almost entirely unchanged.
Cheap Experiments Make It Easier to Stop
One of the conversation’s most interesting observations concerns the value of abandoning an idea.
Serge explains that conventional development can require substantial investment before a concept becomes tangible. By the time people can judge it properly, money has been spent, teams have committed effort, and expectations have formed. Stopping becomes difficult.
Rapid prototyping changes that sequence. A working demonstration can expose weaknesses earlier, before organisational commitment hardens around the project. The benefit includes testing more ideas and discarding unsuitable ones sooner.
This is a richer account of innovation productivity than simply accelerating implementation. The company improves its ability to decide what deserves implementation at all.
However, Serge also distinguishes between something that works on a laptop and something ready for production. A convincing demonstration does not settle questions of reliability, security, scale, support, or maintenance.
The distinction creates two separate leadership tests. First, does the experiment provide enough evidence to justify further investment? Second, what additional work is necessary to operate the solution responsibly?
My conclusion is that faster prototyping should strengthen investment discipline. It gives leaders an opportunity to demand evidence earlier and withdraw support with less waste. That opportunity disappears if every successful demonstration automatically becomes a permanent commitment.
There is also a cultural requirement. Teams need permission to stop after learning something useful. If abandoning an experiment is treated as failure, cheaper development may simply generate a larger portfolio of projects nobody wants to close. The organisation gains most when it makes both exploration and termination easier.
Why Slowing Juniors Down Can Be the Right Investment
The discussion becomes particularly revealing when Serge describes recruitment. He continues to hire juniors and sees their development as an investment in the company’s future expertise.
He encourages them to use AI. At the beginning, however, he expects them to explain every line of the code they produce. He acknowledges that this slows development. The purpose is to ensure that they learn to recognise what the system has done and understand how it works.
This creates an apparent contradiction with the productivity argument. Why preserve a slower process when tools can generate the answer? Because delivery and learning have different objectives. A task can be completed successfully while the person completing it develops very little understanding.
Anthropic’s January 2026 study offers relevant evidence. In a randomised experiment involving 52 mostly junior engineers learning a Python library, the AI group averaged 50% on a subsequent quiz, compared with 67% for the group coding without AI. The speed difference was not statistically significant. Participants’ approaches also mattered: using AI to seek explanations and build comprehension was associated with stronger mastery than simply delegating the work. These findings concern a specific learning exercise, rather than every form of AI-assisted development.
Serge’s practice addresses precisely this tension. He wants the immediate benefits of assistance alongside the development of independent judgment.
For enterprises, this suggests a second form of debt to watch: a future shortage of expertise caused by removing the experiences through which expertise develops. Senior judgment must be replenished. A company that automates junior tasks needs an intentional alternative route for juniors to learn architecture, dependencies, debugging, and consequences.
Expertise Moves Towards Intent, Context, and Validation
The conversation about coding also reveals how professional contribution can change. As implementation becomes easier to delegate, more attention can move towards defining the problem, supplying context, establishing constraints, and evaluating whether the result works.
Serge describes a similar shift for data scientists. Time previously spent writing code or producing dashboards can support data modelling, semantic layers, platform understanding, and validation of analyses created by others.
These activities become particularly important when more employees can build. A polished analytical application may still rely on an unsuitable comparison, a misunderstood metric, or an incorrect interpretation. Accessibility increases the need for clear definitions and proportionate validation.
Henrik introduces the idea that everyone becomes a builder. Serge’s contribution is to connect that ambition to the tools and supporting conditions people need. Building at different levels still requires coordination between domain knowledge and deeper technical expertise.
This has implications for how leaders recognise performance. Visible output is easy to count. Preventing an architectural mistake or correcting a misleading assumption can be harder to observe, even when it saves substantial downstream effort.
The organisation therefore needs a broader understanding of contribution. Expert work includes making constraints explicit, setting useful acceptance criteria, identifying failure modes, and helping others build safely.
My reading is that cheaper implementation increases the importance of choosing the right work. A detailed specification for a poorly understood problem still takes the company in the wrong direction. Professional judgment remains central because someone must connect what can be built with what the business should actually pursue.
AI Maturity Includes Knowing When Simpler Code Is Enough
Serge resists the idea that becoming AI native means putting generative AI into every task. His example is financial reporting. If deterministic Python code can calculate the required numbers reliably, introducing a language model into that calculation needs a clear justification.
AI may still help write the code, investigate an unexpected change, or assist with interpretation. Different parts of the workflow can require different mechanisms.
This distinction avoids an expensive category error: assuming that because AI helped create a system, AI must also perform every operation inside it. The business needs dependable outcomes, and the architecture should reflect the nature of each task.
Anthropic’s guidance on building agents supports this principle. It recommends starting with the simplest workable solution and increasing complexity when the task warrants it, recognising the associated trade-offs in cost and latency.
Serge’s wider position is equally important. He advocates examining work consistently across the organisation while allowing an honest conclusion that a particular task does not need AI. Serious engagement requires the competence to judge where the technology helps.
That is a stronger standard than measuring how widely a tool appears in workflows. It requires understanding the process well enough to distinguish calculation, interpretation, judgment, and action.
It also protects credibility. Leaders asking for transformation need teams to surface limits and unsuitable applications. If every assessment must conclude that more AI is necessary, the exercise becomes a justification process. The company loses the very judgment it needs to deploy the technology well.
Transformation Has to Survive Its Own Success
Near the end of the conversation, Serge argues that enterprise AI should be understood as a system: models interacting with tools, data, other agents, and the environments in which they operate. The business question becomes what behaviour that complete system can reliably deliver towards a defined objective.
That perspective brings the organisational and technical arguments together. A stronger model cannot independently fix missing context, unclear ownership, incompatible processes, or incentives that reward the wrong outputs.
It also explains why leadership must fund more than isolated use cases. Serge distinguishes immediate returns from the shared foundations that enable future applications. He stresses honest accounting for development, maintenance, and downstream costs. A platform investment becomes persuasive when leaders can explain which subsequent work it makes easier and how those benefits will be assessed.
He also describes forums and town halls where practitioners demonstrate their work. This makes transformation tangible through colleagues’ experience and gives local learning a route into the wider organisation.
The most useful lesson from Episode 192 is that AI progress creates new responsibilities as quickly as it removes old constraints. More output needs better selection. More builders need shared foundations. More automation needs deliberate learning. Faster tasks need a system capable of turning speed into value.
That is the standard leaders should apply to an AI transformation programme: can the company deliver useful outcomes sooner, carry learning between teams, and strengthen the expertise required to keep improving?
When those capabilities advance together, individual productivity gains have somewhere to go. They become part of how the business grows.
*This article was enhanced with the help of AI tools, drawing on the podcast transcript and complementary online research. To go deeper into the source material, I encourage you to listen to the full episode and make your own learnings.
Listen and see the full episode.
