AI in the engineering team

From measuring the team’s activity to measuring the effect for the recipient.

What an Engineering Manager should change in how the team works when engineers use AI and results do not improve: working standards, people, measures of effect, bottlenecks.

Live training, in-company6 h + breaksYour team

For whom: engineering managers and engineering team leads

Ask about a date A version for your organisation

How the training runs

Training plan

Live, on your real cases. We tune the day’s rhythm to the team in the room.

120 min

The business case and a first transformation map

An engineering department in a regulated company: within a year the workload doubles, recruitment is frozen, and costs may grow by no more than a fifth.

a first transformation map
the traps with their warning signals
showing on the map where a technical redesign breaks without the people side, and the reverse

The scenario

You lead an engineering department or team in a global company operating in a regulated industry. Your teams of software developers, business analysts, product managers and quality engineers are organized around a portfolio of products.

Within twelve months, your department takes over the work of a similar department in another location that is being reduced. You are also expected to deliver your own products faster. Your department’s workload effectively doubles. Recruitment is frozen, and operating costs may grow by no more than 20%, AI investment included. Quality, security, regulatory compliance and operational stability must be maintained.

Introducing individual AI assistants is unlikely to be enough. Your mandate is to transform the department into one where people and AI agents work together across the delivery lifecycle, while delivery continues and your teams go through the change with you.

The case will develop during the training. After each block you will receive new information about the department and make one decision. At the end, you will put these decisions together into one transformation plan.

15 minBreak

30 min

Diagnosing how the team uses AI

Recognise the team’s problem, tell activity apart from effect, and name the decision that belongs to the EM.

Opening case: around 80% of pull requests supported by AI, with little improvement in delivery. What questions should the EM ask then?
Four stages of the change: access, standards, scaling, value. Checking which stage your own team is at.
Telling apart: tool usage, completed work, shipped change, and the effect for the recipient.
Scope of responsibility: the EM agrees expectations, learning conditions and the review of results; product decisions are made with the Product Manager, technical solutions with the relevant engineers. The exact split depends on the organisation.
A shared example: one team under pressure from a larger scope of work. What can the EM change alone, and what needs agreement or escalation?
Exercise: Diagnosis of the problem and of the EM’s scope of influence, on a shared example → section 1 of the card. Discussion 20 min, exercise 10 min.

45 min

Expectations and the team’s working standards

Agree two working standards, how they will be reviewed, and a realistic commitment from the team.

Small tasks and pull requests, prompt code reviews and limited waiting. The EM picks the rules together with the team, against the actual problem.
Standards need support: access to tools, time to learn, ownership of reviews and of handling exceptions.
An example expectation: shorter delivery time for comparable changes while quality holds. An AI usage rate is not an outcome goal in itself.
From the trainer’s practice: targets of −40% PR time and +30% PRs and tickets; reported results: PR time 50 → 23 h, ticket time 85 → 25 h, PRs +33% and tickets +35% per engineer year on year.
Reading the results: allowing for task size, team composition and the simultaneous change in how people work. The results of one case are not a promise for another team.
The EM’s rhythm: a regular review of blockers and a monthly assessment of effects together with the team.
Exercise: Participants formulate two standards, the support needed and the EM’s message to the team → section 2 of the card. Discussion 25 min, exercise 20 min.

15 minBreak

40 min

Developing people and rolling out new ways of working

Identify the cause of the difficulty, hold the conversation with an engineer, and plan a development action that can be checked.

Diagnosis in conversation: missing skill, insufficient context, the wrong tool, concern about quality, or no time to learn?
Shared expectations cover the quality of the work and ownership of the result; how AI is used may depend on the task and on the engineer’s experience.
From the trainer’s practice: experience-sharing sessions, workshops on building agents, and shared instructions. The EM sets aside time for them and checks what changed in the work.
A short example of an agent analysing a failing test: who reviews the proposal, what permissions it has, and when do we go back to manual work? n8n as a public illustration; other platforms in the supplementary materials.
The development conversation ends with a specific task, the support for it, and a date to check the result.
Exercise: Discussion 20 min, agent example 5 min, paired role-play 15 min: conversation 5 min, swap roles 5 min, feedback and an entry in section 3 of the card 5 min. Result: a development action, the support for it, and the criterion for assessing it.

35 min

Assessing outcomes, quality and cost

Choose measures of the team’s outcome and run a review of effects that accounts for quality, cost and the context of the work.

Assessing delivery time, quality and cost together; a baseline and the same scope of work across the periods compared.
Targets from the trainer’s experience: holding SLOs, 30% fewer customer-visible defects per engineer year on year, and an average cost below X USD per pull request. These are example targets, not thresholds for every organisation.
Traps: artificially splitting pull requests, differing task difficulty, and changes in team composition; per-engineer data is not a standalone ranking of people.
Tool cost is topped up with the time spent on review, fixes and maintaining agents. The cost of a pull request is not the full cost of a delivered feature.
Each participant picks one measure of the effect for the recipient, for example the time from a customer reporting a problem to the fix being shipped, plus a measure of quality and of cost. Shipping alone confirms neither use nor value of the change.
A conversation about individual contribution accounts for task difficulty, collaboration, reviews and support given to others; flow metrics help diagnose the team’s process.
Exercise: Choosing a measure of the effect for the recipient, of quality and of cost, together with a baseline → section 4 of the card. Discussion 20 min, exercise 15 min.

15 minBreak

45 min

Delivery priorities and bottlenecks

Pick one constraint to remove and justify what that decision costs the team’s current plan.

Finished code can wait for review, for tests or for release. The EM looks at the whole flow before raising expectations on implementation.
From the trainer’s case: a monolith, weekly releases, flaky tests; migrating tests to Playwright and stabilising them with AI support. Reported result: build and test processes 40% faster, the first teams on continuous delivery.
The EM’s decision: work on a feature, improve the tests, shorten the queue, or hand a task to an agent? The choice follows the constraint and the opportunity cost.
Agreeing with the Product Manager: how much time goes to the experiment, what gets deferred, and what evidence would let us change commitments. Time freed up can go to scope, to quality or to deferred improvements.
When the constraint sits in another team, the EM presents the dependency and the decision needed. They do not promise to improve the whole process on their own.
Keeping test fixes honest: disabling a test or weakening an assertion does not count as evidence that a defect is gone.
Exercise: Choosing one intervention and preparing a proposal for the Product Manager: the benefit, the team’s time, the work deferred and the dependencies → update of sections 2 and 5. Discussion 25 min, exercise 20 min.

45 min

The EM’s plan for their own team

Prepare a plan for one experiment in your own team and test whether it is feasible in conversation with another EM.

Carrying the conclusions from the shared case over to your own team: the problem, two working rules, support for people, and one intervention.
First week: a conversation with the team and the Product Manager, gathering the missing data, naming the person responsible.
30 days: a baseline and the conditions of the experiment; 60 days: an assessment of the first results; 90 days: a decision to continue, correct or stop.
Three measures: the effect for the recipient, quality and cost; the team’s time budget and the way the AI output is checked.
The plan covers actions within the EM’s scope of influence and, separately, the agreements needed. The result of a pilot is not yet grounds for promising to double the team’s capacity.
Exercise: Introduction 5 min, individual plan for your own team 15 min, peer review in pairs 10 min, discussion of selected conclusions and the first step 15 min. Result: your own SDLC Experiment Card. Criteria: the problem, support for people, measures, time cost and the EM’s scope of influence.

Ask about a date or a version for your organisation

We tailor in-company programs to your processes and systems. Tell us who will be in the room — we’ll advise on scope and setup.

Ask about a date