Your AI Is Only As Good As Your Engineering Culture
Subjects AI adoption, Engineering culture
Speaking
This page is for whoever is putting a programme together. What I want to talk to engineering audiences about is the part of AI adoption nobody puts on a slide: the delivery system underneath it. Most of what stalls an AI rollout was already slowing the organisation down before anyone bought a licence.
Below are the subjects, the talks I have already given, and the two ways to reach me. If you need a bio, a headshot or a photograph in a particular size, ask and you will have it the same week.
what I talk about
One subject, several ways into it: why engineering organisations stop delivering what they could, and what AI does to that once the licences are paid for. Four I have shaped recently are below. They are examples, not a menu. Tell me the audience, the length of the slot and what you want people to leave with, and I will write to that instead.
-
Why AI pilots stall in engineering organisations
What actually blocks an AI rollout once the licences are paid for: review queues, unclear ownership, and a delivery system that was already the constraint. Where the return really comes from, and how to tell whether you are measuring it or measuring activity.
Written for CTOs and VPs of Engineering who bought the tools and cannot yet show what they returned.
Related writing AI Didn't Change Coding. It Changed Software Engineering.
-
Where delivery loses its time
Reading delivery data as a system instead of as a scoreboard. Cycle time, queues and constraints, why most developer productivity metrics measure the half of the problem that is easiest to count, and what to do on the Monday after the dashboard goes up.
Written for Engineering leaders whose teams are busy and whose delivery is still slow.
Related writing Metrics Lie: How to Make Better Delivery Decisions Instead of Polishing Slides
-
Systems over heroes
Why organisations keep rewarding the rescue and never fix what needed rescuing, and what changes when a leader starts treating recurring firefighting as a design defect. Ownership, on-call, and the quiet cost of depending on the person who always saves it.
Written for Engineering Managers and technical leads growing into the job.
Related writing Why Every Engineering Leader Should Build Something Alone
-
Stop splitting software into business and IT
The split survives every reorganisation because it is comfortable for both sides. What it costs in delivery terms, how it shows up in a roadmap, and the practical moves that cross the wires again.
Written for Leadership teams where product and engineering have stopped arguing, which is worse.
Related writing Stop Splitting Software Into "Business" and "IT"
talks given
Every talk below was delivered. Where slides or notes survive, they are linked; for the more recent ones there is nothing public to link yet, and I would rather list the talk than pad it out.
-
-
50m², 8 osób i mało snu. Co może pójść nie tak?
Given in Polish.
Subjects Team dynamics, Engineering leadership
-
Między młotem a kowadłem. 8 narzędzi lidera pomagających nie zwariować
Given in Polish.
Subjects Engineering leadership, Management practice
-
Narzędzia i biblioteki przydatne w codziennej pracy z Xamarin
Given in Polish.
Subjects Mobile engineering, Developer tooling
-
Narzędzia i biblioteki przydatne w codziennej pracy z Xamarin
Given in Polish.
Subjects Mobile engineering, Developer tooling
organising something?
Tell me the event, the audience and roughly when. If the audience is engineering leadership and the slot is real, the answer is usually yes, and I will say so within a couple of days.