Tech teams in the AI era
Decide, frame, bring on board
2-day training for CTOs, tech leads and technical team leaders: take a position on AI in your organization, set a usage framework, and bring a divided team on board.
The symptom
"They do it with 4 developers. We have 11."
The message arrived on a Saturday night. A link to an article, and that sentence.
You open your laptop on Monday knowing the conversation will happen on Thursday, and you take stock of what you actually have in front of you.
Two developers are producing three times as much as before. Nobody seriously reviews what they ship anymore, because the volume has outgrown the team's review capacity. Three refuse to use any of it, and they have arguments you can't quite refute. A junior who joined eight months ago has never had to debug alone, and you're starting to wonder what they'll be able to do in two years. The other five are using it quietly, without mentioning it in meetings.
You have no numbers, no rules, no position.
On Thursday, you'll be asked why you're not moving three times faster. And the only answer you have today starts with "it's more complicated than that."
The cost of inaction
What it's actually costing you
You're facing a demand you can't objectify.
You can neither confirm the claimed gains, nor refute them, nor say what they cost elsewhere. On that ground, the conversation with leadership always ends badly.
Your team is splitting in silence.
Two camps form, nobody talks about it openly, and the tension shifts into code reviews, estimates and retrospectives. These conflicts become very hard to address once they've settled into another shape.
You lose visibility into what's being produced.
More code ships, and a growing share of it has never been deeply understood by anyone. The consequence doesn't show up this quarter. It shows up the day of a serious incident.
Your juniors stop learning the same way.
The classic path went through struggle, error and debugging. That path has changed, nobody has replaced it, and it's the senior generation of 2030 at stake here.
You decide by default.
Deciding nothing is still a decision, and it's the one that costs you control over your team's practices.
What changes
What you gain
A defensible position in front of your leadership.
Documented, sized to an order of magnitude, with what's actually gained, what isn't, and what the gain costs elsewhere in the chain.
A team that talks about the topic.
The skeptics' objections get put on the table and treated for what they are, which is often fair objections. That's the condition for avoiding a lasting split.
An explicit usage framework.
What can be delegated, what never is, what needs review and how, what never leaves the company. Written, discussed, revisable.
A learning model for juniors.
Adapted to the current context, one that preserves the reflexes the machine doesn't build.
Up-to-date hiring criteria.
Because the profile that creates value in a technical team today isn't quite the one your interview grids evaluate anymore.
An organization that absorbs the next wave.
The topic will keep moving. What's passed on here is a decision-making method, not a state of the art that will be outdated in six months.
Profile
Who it's for
Also freelance CTOs and fractional CTOs who need to set this framework at their clients, often within a few weeks and without hierarchical authority.
You need to hold responsibility, even informal, over a development team's practices, and real experience of software development.
This isn't for you if
you're looking for prompt engineering training, a comparative tour of tools, or hands-on practice with coding assistants. Here, we work on the decision, the framework, and change management.
The method
The main steps
The basics you need to decide
What these systems do, what they don't, and why. The level of understanding targeted is the one that lets you arbitrate, not the one that lets you build: real capabilities and failure modes, confidentiality and code ownership, cost structure, and above all what shifts every quarter versus what stays stable for years.
What actually changes in the work
We go through the full cycle: scoping, design, writing, review, testing, debugging, documentation, maintenance. The gain is dramatic at some stages and nil at others: it shifts the bottleneck rather than removing it. Knowing where it shifted for you is what makes your case credible.
The transformation of the developer role
When producing code loses relative value, value shifts toward judgment, trade-offs and verification. We work through the concrete consequences: which skills gain value, which lose it, what seniority becomes, and what that forces you to change in your interview grids.
Bringing a divided team on board
The heart of the training. The three postures you systematically encounter (the enthusiast, the skeptic, the silent one) and what each one needs. How to address the underlying objections, which deserve a real answer. Why top-down adoption fails, and the particular case of the respected senior who refuses.
Setting the usage framework
The written rule that replaces the fog: what gets delegated and under what conditions, what never leaves the company, who's responsible if something goes wrong. We also work on how to build this framework with the team rather than against it.
Steering and reporting
What to watch to know if it's working, and which indicators to avoid. How to lead the conversation with a leader expecting a 3x factor, and evolve the framework without starting from a blank page every time.
Putting it into practice
The training's exercise
You leave with two things produced during the training, on your real context.
Your team's usage policy, written and argued, ready to be put up for discussion internally: the group challenges it by playing out your own developers' objections. And the conversation with your leader, simulated with the expected-productivity question: you play it, get feedback from the group, and play it again.
It's the most demanding part of the training, and the one participants say changes their following week the most.
Deliverables
What you leave with
Pricing
Format and pricing
2 days
€1,800 excl. VAT
The full journey: basics, transformation of the work and the role, change management, usage framework, steering.
3 days
€2,700 excl. VAT
An extra day of deep hands-on practice on participants' real situations: diagnosing their own team, building a six-month rollout plan, simulating difficult conversations with both developers and leadership.
Deliberately practical teaching: short inputs, work on your own team, role-play, producing your own materials, and group feedback.
Frequently asked questions
Questions we get asked
"It's more complicated than that."
"The gain is clear on scoping and writing, I can document it. On review, we've taken back part of it, and here's why. Here are our rules, what would actually unblock speed, and my recommendation on headcount."
The same topic. A conversation you steer, instead of one you absorb.