Leaders are heavily investing in helping their teams become more productive.
Yet very few can explain what’s actually slowing them down.
The quest for improved enterprise productivity typically includes purchasing productivity tools, updating operating models, hiring consultants and, of course, AI. Despite the investment, the problem remains unsolved and it’s felt from the boardroom to the water cooler.
Meanwhile, one part of the organization has figured out how to deliver higher-quality work faster. Software teams are some of the most efficient teams in the world. Not because they’re smarter or more technical, but because they’ve learned to design the way work happens, not just the work itself.
Developer experience (DevEx) provides a blueprint for how the enterprise can operate with more clarity and deliver higher-quality outcomes faster.
The experience of work
Across most organizations, you’ll find the same patterns repeated:
- Teams lack clarity on priorities, causing wasted effort on the wrong things
- Work is coordinated through meetings, making progress slow and tedious
- Information is locked in emails, people’s heads or private channels
- Tools aren’t integrated, leaving it to humans to translate and re-create information in multiple places
- Leaders lack data to make informed decisions
These are examples of friction built into an organization’s system of work; they’re employee experience issues.
These challenges appear everywhere, but software teams have responded to them by redesigning the experience of work, not just the process.
DevEx emerged as a response to the buildup of friction faced by software developers. Its objective is to reduce unnecessary friction and make it easier for developers to do high-quality work with less cognitive load.
DevEx wasn’t born from engineering culture; it was born from engineering constraints.
The same principles apply to every team.
What DevEx really solves
DevEx is commonly misunderstood as pandering to developers, giving them ping pong tables and pizza to lure them into working harder. It’s not.
When you strip things back, DevEx addresses the same universal problems that slow down every knowledge worker.
Purpose & context
Developers can’t effectively build software without understanding what’s important, why it matters and what success looks like. It’s an input to a good developer experience. Marketing, HR and finance teams all deal with the same ambiguity.
Work visibility and coordination
Software teams create shared visibility of work, so work progresses with fewer handovers and real-time interactions. It reduces back-and-forth, meetings, unnecessary dependencies and waiting time. These problems are worse for business-oriented teams as they don’t have shared tooling like engineering teams do.
Knowledge availability and access
Software teams invest heavily in documentation, decision logs and self-service of information. This is critical to speed, group learning and innovation; without this, teams drown in information debt. It’s one of the biggest performance killers in most organizations.
When you look at the ways that focusing on DevEx helps software teams, it becomes obvious: DevEx is a blueprint for enterprise performance. Software teams just adopted it first.
Scaling DevEx principles to the enterprise
A focus on improving DevEx works because it optimizes how work happens for the teams delivering the work. Four flows determine how effectively any organization performs:
- Purpose flow — teams know what matters, why, and how their work connects to outcomes.
- Work flow — teams experience minimal friction when moving work from idea to completion.
- Knowledge flow — teams have access to the information they need, when they need it, without asking someone else for it.
- Intelligence flow — AI is used to reduce low-value tasks and friction.
Engineering has explicit rituals and systems that support these flows; most business teams don’t. Ironically, that’s one of the reasons the intersection between technology and business teams can be a source of friction.
We see the benefit of these rituals and systems at Atlassian every day. When teams have shared context and open knowledge by default, coordination overhead drops. Decisions are made faster, quality improves and teams don’t rely on meetings to stay aligned. This isn’t unique to engineering; it’s a universal pattern of high performance.
One universal truth about consistent high performance
Across all the companies I’ve worked with, from banks to tech companies and now motor racing, one shared truth remains: when the system of work grows organically, friction grows with it.
I first saw this clearly years ago while working at a large bank. I was accountable for a system of work redesign with the objective of improving speed and quality of software delivery.
The job of the software teams was simple in theory: take an idea, turn it into code and move that code safely into production. But the software teams didn’t operate in isolation. They had to navigate requirements provided by governance teams responsible for cyber security, financial crimes, risk, change management and architecture, each with legitimate outcomes they were trying to optimize for.
Over time, as new regulations and requirements were introduced, each governance team added its own checkpoints and reviews into the delivery path. Individually, every requirement made perfect sense. Collectively, they created a system of work no one would have designed intentionally. Every team was optimizing for their own outcome, not the system’s outcome.
As a result, priorities became unclear, work slowed to a crawl and everyone spent more time in meetings navigating processes than delivering the work.
It wasn’t a people problem, it was the accumulation of well-intended rules that made work harder for everyone. It was a system problem.
During our redesign, we moved away from accidental complexity and toward intentionally designed flows. We made the experience of software teams a priority and created a clear set of principles for how work should happen. Governance didn’t disappear; we intentionally integrated it and created transparency rather than reactively layering requirements.
When we treated the system of work as something that needed to be designed, not inherited, everything began to accelerate. Teams had increased clarity, there were fewer handoffs and teams finally had the space to focus on what mattered. To keep the system operating well, we constantly reviewed our system of work for opportunities to improve outcomes.
This experience has shaped the way I view enterprise productivity today.
Since then, I have worked with marketing teams racing to publish content, HR teams building employee experiences, finance teams navigating planning cycles and operations teams handling complex delivery. Every team wants to move faster. Every type of team hits the same systemic barriers. It’s never the people, it’s the design of how work happens.
Consistently high-performing teams don’t need to beat the system; they rely on intentionally designed systems of work.
Improve your system of work
Improving your system of work doesn’t always require a formally planned transformation project. Small interventions can have outsized impacts on the four flows of organizational performance.
Here are four bite sized actions you can take to start improving your system of work:
- Understand your current system of work — ask teams how you can improve the way work happens. No one understands what gets in the way of work more than the people trying to do the work. Understand how work flows today so you can improve it tomorrow.
- Reduce cognitive load — simplify and connect tools and processes. Most teams working in an enterprise organization are dealing with unnecessary steps, context switching and decision tax.
- Unlock knowledge — move from being meeting and email driven to establishing a culture of shared and self-service knowledge. Being able to access the information you need, when you need it and without asking someone else for it, is foundational to high performance.
- Treat AI as a teammate — AI creates additional capacity and reduces manual work. Embed it in your system of work instead of bolting it on as an afterthought.
DevEx was the starting point
DevEx showed us what’s possible when we designed the experience of work deliberately. The next frontier is applying these same principles across the entire enterprise.
Productivity isn’t an operating model problem, it’s a system problem. DevEx gives us the blueprint to fix it. The organizations that win won’t be the ones with the hardest working employees, they’ll be the ones that design work the best.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?
