You have 1 article left to read this month before you need to register a free LeadDev.com account.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
Estimated reading time: 8 minutes
Knowing how far to lean into hype cycles and industry trends – or whether to lean into them at all – can make for happier developers.
One of the hardest questions engineering managers face today is where to invest. Should you double down on AI-powered coding tools? Build out a platform engineering function? Or take a step back and think about developer experience (DX) more holistically?
These aren’t just trendy buzzwords: they’re strategic decisions that affect how your team ships software and how your organization scales. And the stakes are high: budgets are limited, and teams can only focus on so many things at once.
In today’s climate, engineering leaders are grappling with big challenges: reducing technical debt, improving cross-functional collaboration, increasing delivery velocity, and improving software quality.
But here’s the catch: these problems rarely have a one-size-fits-all solution. Technical debt might stem from years of poor design decisions, or it might be caused by missing documentation and knowledge silos. Velocity might suffer due to inefficient tooling or simply unclear ownership.
What does it actually mean to invest in AI, platform engineering, and DX? And what frameworks can you use to evaluate which lever to pull based on your team’s unique pain points and priorities?
Investing in AI coding tools
Recent pushes for the adoption of AI coding tools are mostly rooted in a desire to boost delivery velocity.
It’s an understandable move. Tools like GitHub Copilot can accelerate code generation and testing, with a McKinsey study showing that developers can complete tasks up to twice as fast using generative AI.
AI excels when it’s used to unblock repetitive work: writing boilerplate code, generating first drafts, optimizing code, or ramping up quickly on unfamiliar frameworks. But every experienced engineer knows the uncomfortable truth: writing the code is often the easy part.
The hard part is understanding what to build, why it matters, and whether it should be built at all.
As software engineer Kelsey Hightower puts it: “Coding is an activity. Solving problems is an outcome. You can solve a lot of problems without writing a single line of code.”
Time savings from AI vary widely depending on developer experience, task complexity, and team maturity. So before you place all your bets on Copilot or its cousins, ask yourself:
- Will AI coding tools help your organization stay competitive? Absolutely.
- Will they alone move the needle on velocity? Unlikely.
Software development is a constantly evolving field, and programming is changing radically with the introduction of AI coding tools. If you want your organization to remain ahead of the curve, you want your engineering teams trained and proficient in this new tech.
However, AI won’t magically fix technical debt, misaligned teams, or poor system visibility. If your organization is already struggling with collaboration breakdowns or brittle architectures, AI might help you write code faster, but also ship bugs, inconsistencies, and duplicated logic faster as well.
Instead, treat AI as one piece of a broader developer experience strategy. Equip teams with training on prompt engineering, establish clear use cases, and define when AI is useful and when it’s a distraction.
The orgs that thrive won’t be the ones that blindly adopt AI. They’ll be the ones that integrate it with care, help their engineers master it, and use the time it saves to tackle harder, more meaningful problems.
Investing in platform engineering
Platform engineering has emerged as a fast-growing trend in software development, centered on building internal self-service platforms that streamline workflows, improve developer productivity, and reduce friction. These often take the form of internal developer platforms (IDPs) or developer portals.
At KubeCon + CloudNativeCon Europe, the platform engineering track was one of the most crowded and high-energy parts of the entire event – and for good reason. Platform engineering is evolving rapidly as a complement to DevOps practices, aiming to address developer-specific needs with self-service tools and well-paved paths.
While DevOps emphasizes collaboration between development and operations, platform engineering focuses on building and maintaining reliable, reusable infrastructure that abstracts complexity and lets developers focus on shipping.
For large engineering organizations, the value is obvious: unify tools, reduce repetition, increase consistency, and unlock developer efficiency.
But the biggest challenge is knowing where to start.
It’s tempting to jump straight into building an IDP with a golden path and full-service automation. And while the promise of an IDP is compelling – faster deployments, reduced cognitive load, better reliability – the reality is that the most effective platforms are the ones that are shaped directly by the real, validated pain points of their users.
Before hiring a platform team or rolling out another tool, pause and ask: Where is your team struggling the most today?
Is it deployment friction? Slow feedback loops? Inconsistent environments? Endless debugging marathons? These are all different problems, and they don’t all require a full-blown platform to fix.
Start with a discovery process:
- Survey your developers. Run structured surveys or interviews to find out what’s slowing them down and what tools they feel are missing.
- Spot high-friction areas. Onboarding, testing, and debugging are common culprits. Often, these are where lightweight tooling or automation can have the biggest positive impact.
- Quantify before you build. Look for patterns in support tickets, incident post-mortems, or PR cycle times – anything that helps quantify bottlenecks.
Platform engineering doesn’t have to be expensive or overbuilt from day one. It can start with practical, incremental changes: simplifying CI/CD pipelines, improving documentation, standardizing APIs, or just removing unused tooling.
Small steps can compound quickly and build the case for a broader platform investment grounded in real developer needs.
More like this
Investing in developer experience
DX is a broad, evolving discipline that encompasses the tools, workflows, and culture shaping how engineers get work done. Prioritizing DX can create a virtuous cycle: empowered developers build better software, and this in turn improves retention, morale, and business outcomes.
Today, developer productivity is becoming a key driver of company performance. Organizations that invest in DX see long-term gains like faster onboarding, reduced burnout, more reliable delivery, and higher team engagement.
In my own experience as a CTO, I’ve seen the biggest DX gains come from seemingly simple changes – clearer documentation, better internal tooling, more thoughtful onboarding. These aren’t always high-profile initiatives, but they’re the ones that eliminate friction engineers deal with every single day.
A comprehensive DX strategy touches every stage of the developer journey – from onboarding to deployment – and often intersects with investments in AI tooling and platform engineering. In fact, a good DX program provides the foundation to determine whether and when those investments make sense.
While every team’s DX journey looks different, certain practices tend to benefit almost everyone. Reliable build/test/release pipelines can be a saving grace, for example, shortened feedback loops and reduced friction in daily work. Supporting tooling adoption – through training, documentation, and thoughtful rollout – ensures new tools become habits, not hurdles.
Perhaps most critically, DX improves when developers can understand the system they’re working on. Real-time system visibility helps engineers build, debug, and refactor with confidence. Similarly, capturing institutional knowledge – like design decisions and architectural context – prevents information silos and reduces the risk of “tribal knowledge” bottlenecks.
Why it’s difficult to get buy-in
So why doesn’t every team have a dedicated DX function?
Because it’s a long game.
Unlike a shiny new tool or a platform team with a roadmap, a DX program is a cultural and operational shift. It’s an ongoing process of eliminating friction, improving feedback loops, and ensuring engineers have the right context, autonomy, and tools.
And while the impact of bad DX is easy to spot – think flaky builds, inconsistent environments, and undocumented APIs – quantifying the ROI of good DX is notoriously tricky. Improvements often require investing in new tools, evolving processes, or even rethinking architecture. And because DX work tends to expose new friction points along the way, progress unfolds iteratively, making timelines and cost estimates hard to pin down.
You can (and should) track impact on clear, near-term metrics like onboarding time, incident mean time to resolution (MTTR), or developer satisfaction in surveys. But evaluating the ROI of a holistic DX strategy is harder: its effects are distributed across workflows, teams, and tools, and the payoff compounds gradually, measured in months or quarters, not days.
Still, the compounding payoff is real. DX is what ties everything together. It’s what ensures your AI tools are used effectively, your platform investments are adopted, and your developers stay focused on solving problems.
London • June 16 & 17, 2025
Speakers Gergely Orosz, Camille Fournier and Lara Hogan confirmed.
Managing expectations on ROI
The hard part is quantifying ROI on AI, platform engineering, or DX to leadership.
A pragmatic way to approach this is to estimate the cost of developer inefficiencies. Ideally, you’d base this on internal surveys and workflow data. But external benchmarks can also paint a useful picture.
According to Atlassian’s 2024 Developer Experience Report, engineers lose over 8 hours per week to inefficiencies like tech debt, poor docs, and broken tooling. Stack Overflow’s salary survey puts the global average back-end developer salary at $67,227 a year. That’s $13,445 per developer per year lost to avoidable friction. For a team of 10, you’re effectively paying for two full-time engineers to do nothing but fix inefficiencies. For a team of 400, you’re leaving $5.3M on the table every year.
In other words, even small DX wins can unlock major ROI.
Final thoughts
Choosing where to invest, whether it’s AI tools, platform engineering, or a broader developer experience strategy, isn’t about chasing the latest trend. It’s about understanding what’s holding your team back and addressing those bottlenecks with the right level of focus and investment.
In the end, the right investment is the one that makes your developers more effective, your systems more resilient, and your team more aligned. And that starts with listening: not to industry hype, but to your engineers.
