If I were a CTO in 2025, I’d be focused on building a high-impact tech organization that moves quickly without burning out. The tools, mindset, and systems to do this exist today—it’s just a matter of putting them together with intention.
Planning as Our Superpower
One of my greatest advantages wouldn’t just be the tech stack or AI tools—it would be how we plan and operate. Planning would be our ultimate superpower. I’m not talking about fake Agile or bloated rituals, but deeply integrated, disciplined Agile that works for engineers, not against them.
I’d have a real Scrum Master—not someone running rote standups or checking boxes in Jira, but a strategic operator who removes blockers before engineers even notice them. Someone deeply embedded in the team, living inside our tools, and always scanning for friction. This person would be the communication router, the shield from chaos, and the glue between product and engineering. Engineers should never chase down answers, coordinate across teams, or mediate roadmap confusion—that’s the Scrum Master’s job. Their success metric? Engineer flow state time.
Nothing would get built unless it’s been through a process that’s clean, clear, and deliberate. Feature requests would start with a stakeholder need, then be translated into a spec using AI tools that help shape the user story, identify dependencies, and mock the UX if needed. Before anything hits the backlog, it must be reviewed and approved by relevant stakeholders—Product, Design, Engineering, even Compliance if needed. The goal is zero ambiguity once something is ready to build. Engineers should open a ticket and know exactly what to do, why it matters, and what done looks like.
AI-First Culture
Everything would start with an AI-first culture. Not just sprinkling in ChatGPT for writing emails, but embedding AI into how we operate. Every team would be expected to use AI tools not just to assist, but to accelerate. Engineers would pair with Copilot, Cursor, or Cody to write, refactor, and debug faster. Product Managers would prototype interactive versions of their ideas using tools like V0 or Figma AI before engineering gets involved. If you can’t test an idea in a few days, it’s too slow.
Every PM would also get fluent in AI-assisted coding. I don’t need full-stack devs in product, but I want people who can talk architecture, understand trade-offs, and build small experiments themselves. That’s the bar.
Onboarding would be powered by AI too. New hires would get their own custom-trained GPT that understands our codebase, documentation, processes, and culture. No more guessing or waiting around. Ramp-up would happen in days, not weeks.
Lean Operations
Operationally, I’d keep things ruthlessly lean. We’d have automated infrastructure audits running constantly. If we’re paying for an EC2 instance and no one can tell me why, it’s gone. Same with SaaS—I’d implement usage-based reviews to cut or consolidate tools collecting dust. Internal tools would be built on no-code or low-code wherever possible. Zapier, Make, and Retool would be our best friends. We wouldn’t waste engineering cycles where we don’t have to.
Backlogs wouldn’t be dumping grounds. They’d be prioritized, tight, and curated monthly by a product owner who is engaged, accountable, and empowered. No mystery items. No legacy tickets collecting dust. Every single item would have a clear link to business value. And that same product owner would be involved in grooming, prioritization, and tradeoff conversations—not just sending Jira tickets over the fence.
Sprints wouldn’t be frantic bursts of activity—they’d be calm, focused execution blocks with clearly scoped deliverables. Retros would be honest, action-oriented, and tied back to metrics we care about: velocity, quality, lead time, escaped defects, and feature adoption. Engineers wouldn’t just ship code—they’d understand the impact.
Communication and Focus
Communication would default to asynchronous. No endless meetings. No status updates that could’ve been a Notion doc or a Loom video. We’d run on Slack bots, slash commands, and solid documentation. Engineers need time to think, build, and focus. I’d protect that like a hawk.
Every week, we’d ship out a “Dev Digest”—short, clear, honest updates on what’s moving, what’s blocked, and what we’ve learned. We’d hire in two zones: close to clients for velocity, and in key offshore hubs for follow-the-sun development and cost leverage. I’d support a fully remote setup with tools and rituals that make it work—not just tolerate it.
Security and Quality
Security and reliability wouldn’t be an afterthought. We’d enforce zero-trust principles with automated provisioning and immediate deprovisioning. Core systems would be monitored with real-time dashboards and alerting via Sentry, Datadog, and PagerDuty. Every deployment would pass through automated tests for security and quality. Every engineer would understand how to design for resilience, not just speed.
Tech debt wouldn’t be something we whisper about during 1:1s. It’d be on the roadmap, visible, scheduled, and owned. Every quarter, we’d run a dedicated tech debt sprint to clean up architectural shortcuts, pay down complexity, and improve dev experience. We’d measure it too: time to onboard, time to run a local dev environment, number of flaky tests, time from pull request to merge. These are the quiet killers of velocity, and I’d treat them like they matter—because they do.
Measuring What Matters
I’d define engineering North Stars that track our velocity, quality, and impact: deploy frequency per team per week, time to first production commit for new engineers, mean time to recovery when incidents happen, change failure rate, bug-to-feature ratio in retros, and most importantly, lead time from idea to customer value. These metrics don’t just track engineering health—they show how aligned we are to the business.
I’d also keep a close eye on time spent firefighting versus building. You want to know how healthy your platform is? Ask your engineers what percentage of their week is spent putting out fires versus shipping new value. If that number’s off, it’s not a resourcing issue—it’s a systems issue.
Building the Team
The team itself? That’s everything. I’d build a high-performing culture grounded in trust, autonomy, and radical transparency. I’d encourage team members to be visible leaders in their communities—speaking at meetups, writing posts, sharing learnings. The best people want to be part of something that’s both elite and outward-facing.
This is how you build an org that moves with confidence and clarity. Engineers are protected to do their best work. Product has real visibility and leverage. Leadership gets predictability and outcomes. It all comes down to structure, not micromanagement.
You want speed? It starts with clarity. You want quality? It starts with alignment. You want retention? It starts with removing chaos. The best engineering orgs aren’t the ones doing the most—they’re the ones doing the right things without thrashing.
That’s the kind of org I’d build. AI-native. Async-first. Scalable without bloat. Tight culture. High output. Relentlessly focused on business value. We have all the tools we need to build this today. The only question is—who’s bold enough to actually do it?
Discover more from AJB Blog
Subscribe to get the latest posts sent to your email.
