“Why aren’t we shipping faster with AI?” is the dominant question I’ve seen up-close from 13 (and counting) Boards and Executive Leadership Teams to CTOs of software scale-ups this year.
“If tomorrow we were to go twice as fast with our current setup, we’ll have twice the Sev1 incidents, twice the bugs, and twice the undiscovered security vulnerabilities” is the completely reasonable pushback I see, but turning that pushback into a constructive leadership conversation about resource allocation is what I’m interested in.
I like elevating the red-headed stepchild of OKRs: Engineering Effectiveness metrics (Throughput/Stability etc), and upskilling the broader exec on how this maps to Acquisition/Retention via User Engagement.
If Engineering Effectiveness is new to you (or if you know about it but have never found the time to formalise it), you can have a simple baseline built in under 5 minutes using something like https://dora.dev/quickcheck.
Once we have a baseline, we can set a target. Every team will be different, but one 30m session at our next Retrospective where we ask every engineer the question “If you had 3 days to solve one of those daily/weekly papercuts we’ve lived with for years, what would it be?”. Limit it to a handful of 3-day activities the team picks together. We’re not asking for a 4-month Kubernetes project, we’re fixing lingering issues that impact PR cycle time or Build time.
Are there likely bigger fish to fry? Sure, but if we haven’t previously succeeded when floating those works, why would that fly now? The low resource investment and fast turnaround will help build trust for next step.
We’re less than a week in, and we now have a handful of measures with Baselines and Targets, and a handful of ways to turn these dials that the team are motivated about. So long as these are unlocks for future AI Engineering practices, no need to hyperfocus on AI just yet.
This is all the scaffolding we need to attach “Engineering Velocity” to the high value engineering-initiated works that we never seem to succeed getting prioritised over “new features” during roadmap planning.
At this stage, I like formalising a couple of these through formal OKRs for use in future Roadmap Planning cycles, but don’t get blocked on this; it’ll come soon enough.
Ringfence 15 minutes in our next Exec Leadership meeting and articulate the connection to product velocity and the rapid ROI from this allocation of resources. If your organisation is immature in this space, threading the needle here comes from smaller wins with measurable outcomes to build confidence/trust.
After a few quick wins here, we have a foundation on which to build the case for larger engineering investment items that unlock more aggressive AI Engineering practices in our crusty old brownfield ecosystem.
Remember when communicating that it’s not “tech debt”, it’s “engineering velocity”. Yes, yes, “it’s the same thing”, but the onus is on us to communicate in a way that gets heard.