How to Turn User Feedback into Dev Team Ownership and Action?
Most teams treat software development as a pipeline. Datadog treats it more as a loop.
That shift changes everything - how feedback is handled, how ownership is distributed, and how teams make decisions.
In a conversation with Simon Boudrias (Director of Engineering at Datadog) and Jon Kern (co-author of the Agile Manifesto), one idea kept coming back:
The effectiveness of a system is not defined by how well it executes — but by how well it learns.
To get a quick sense of the discussion, watch this 10-minute recap video. You can find the full session here.
This article explores how Datadog turns user feedback into developer ownership and action — not through a single practice, but through a system designed to keep the loop alive.
User value should be both the starting point and the goal of a team’s work. - Jon
Software development is often described as a process of delivering outputs - features shipped, tickets closed, releases completed. But this framing might be misleading. If both the beginning and the end of the work are anchored in user value, then what we are dealing with is not a straight line, but a loop - a continuous movement between users and developers and back, where each iteration informs the next.
Software development is a continuous cycle between users and developers - where experience on one side shapes what happens on the other. - Jon
At Datadog, this becomes explicit in how teams approach change. The focus is not on controlling outcomes directly, but on shaping the system that produces them:
Sometimes we focus too much on the outcome. But what you can actually change are the inputs. Working a funnel and trying to influence what happens further down is hard to connect - so in the end, you often have to take bets. - Simon
In a pipeline, outputs are expected results of predefined steps. In a loop, outcomes emerge from the system. Improving results means improving inputs — feedback, interactions, and understanding.
In this model, feedback is not something that happens at the end. It is embedded within the work itself. It shapes how problems are understood, how decisions are made, and how solutions evolve.
When someone comes to you, they usually have a problem they’re trying to solve. You might disagree with their solution, but if they felt strongly enough to bring it up, there’s very likely a real problem there. The key is to go back to first principles - peel away the proposed solution and focus on understanding the problem first - Simon
This is what a real feedback loop looks like in practice. It is not about collecting ideas and prioritizing them in a backlog. It is about continuously refining understanding - separating signal from noise, problem from proposed solution, and using that clarity to guide action.
Most conversations should involve multiple people so it really feels like a shared agreement. It also makes it easier to have difficult conversations - because different perspectives come in, and you can find paths forward you might not have considered on your own - Simon
Progress does not happen through handoffs, passing work along a chain, but from aligning perspectives within a network, through shared understanding. The loop is not just technical, it is deeply social.
Otherwise, people might start to feel a bit hopeless when they run into issues - thinking, ‘they don’t have time to help me, so I’m not going to fix this.’ And that’s not what we want. - Simon
Loops rarely fail dramatically. They decay through disconnection and disengagement - when people stop contributing, stop fixing, and stop seeing the impact of their work. Feedback stops flowing, ownership declines, and small issues accumulate into systemic problems.
If you lose the connection to user value, it becomes very hard to know whether you’re making progress at all. - Jon
What makes Datadog’s approach powerful is that the loop is sustained not only through systems, but through behavior.
For example, if someone reports a bug, it’s simple, just say thank you. Make sure you always acknowledge it. That alone makes people feel better. And when people bring ideas, even if not all of them are great, the important thing is to keep the conversation constructive. - Simon
These small interactions - acknowledging input, engaging with ideas, keeping conversations constructive - are what keep the loop alive at scale. They ensure that feedback is not only given, but continues to be given.
Ownership at Datadog did not start as a cultural initiative. It started as a structural decision.
The moment that really cemented the frontend community was when we separated the frontend code from the backend into its own monorepo. That’s when the community truly took ownership of their developer tooling. At the time, there was no dedicated DevEx team - just a few staff engineers stepping up and taking the lead. - Simon
This created the conditions for ownership to emerge naturally. Instead of relying on a central team, developers became directly responsible for the tools they used every day. The loop between problem and solution became shorter, more immediate, and more personal.
Those engineers stepped up and said, ‘we need to build this.’ And from there, they started creating opportunities for the community to connect - to meet, talk, and build relationships. - Simon
This is a critical shift. Ownership is not distributed by mandate. It emerges when people have both the ability and the space to act. By creating an environment where developers could shape their own experience, Datadog enabled a self-reinforcing loop: the more people contributed, the stronger the sense of ownership became.
We have fishbowl meetings - a monthly Zoom session where people share what’s happening in the repo, what they’ve shipped, and what’s going on in their world. It’s very open-ended, focused on sharing knowledge. We also have a frontend summit - a yearly, two-day event where everyone gets together in person to spend time together, talk shop, and talk tech - Simon
These moments are less about coordination and more about cohesion. They create visibility, shared identity, understanding and a sense that people are building something together.
As organizations grow, what once worked organically becomes harder to sustain.
As we grow, it becomes harder to find people who have time to work on developer experience. At a certain point, you need a dedicated team - people who can focus on it full time and take care of the day-to-day issues, the small paper cuts in developer tooling. - Simon
But introducing a DevEx team creates a risk:
When you introduce a DevEx team, it’s important to keep the community engaged and not make people feel like this team is going to do everything. It still needs to be a collective effort. - Simon
Ownership is not just structural. It is psychological.
People need to feel ownership of the tools they use every day. Otherwise, when they run into issues, they can start to feel hopeless - thinking, ‘no one has time to help me, so I’m not going to fix this’. - Simon
If developers begin to feel that “someone else owns this,” the feedback loop weakens. Problems stop being fixed at the source. Contributions decline. And gradually, the system shifts from participation to dependency. Datadog maintains a balance: the DevEx team enables, but does not replace, the community.
If structure creates the possibility of ownership, culture determines whether it actually happens. At Datadog, one of the defining cultural traits is the absence of silos. Frontend code is not treated as territory, but as a shared asset, something the entire community is responsible for and can contribute to. This not as an accident, but as a deliberate norm:
There are no silos in the frontend. People aren’t protective of their code - it’s not ‘this is mine, don’t touch it.’ We regularly work on projects that impact the entire codebase, and that’s not only accepted, it’s encouraged. - Simon
Ownership is shared. Code is collective.
This mindset fundamentally changes how feedback flows. In many organizations, even when issues are visible, they are blocked by ownership boundaries — “this isn’t my area,” “that’s another team’s responsibility.” At Datadog, those boundaries are intentionally softened. The expectation is not just that you can contribute across the system, but that you should.
This openness becomes especially visible during large initiatives - refactors, tooling changes, or new architectural directions. Instead of being driven by a small group in isolation, these efforts are brought into the open and shaped collectively.
When we work on large projects - like major refactors or introducing new tools or ways of working - it’s important to do it with the community. Be open, communicate, share updates, create spaces for discussion, and make sure people know what’s happening. - Simon
Feedback is built into the process, not added afterward.
It is built into the process from the beginning. By making work visible and inviting participation, the system creates continuous opportunities for input, alignment, and course correction.
People will bring ideas - and not every idea will be great. And that’s fine. What matters is keeping the conversation constructive. Engage with the idea, show interest, and try to understand the goal behind it - why they believe it’s a good one. - Simon
Disagreement becomes a path to understanding, not a barrier.
This approach reframes disagreement from rejection to exploration. Instead of shutting down ideas, teams use them as entry points into deeper understanding. This not only improves decisions, but also ensures that contributors remain engaged, even when their ideas are not adopted.
If culture enables feedback to flow, the next challenge is understanding what that feedback actually means.
At Datadog, developers are also users. They experience the same tools and workflows they build.
Problems are not reported, they are felt.
A feedback loop depends on signals. But not all signals are equally valuable. It is easy to collect data. It is much harder to collect signals that reflect real experience.
Meaningful signals are those that reveal what it feels like to work within the system, not just how the system performs on paper.
Understanding experience requires going beyond surface-level metrics and building a richer, more nuanced view of developer experience. Datadog combines multiple layers:
This layered approach ensures that no single signal is taken at face value. Instead, signals are interpreted in relation to one another, creating a more complete picture of the system, and again - deeper understanding.
Engineering metrics, such as DORA, provide a quantitative view of how the system performs. They capture outcomes - how quickly code moves through the pipeline, how often deployments happen, or how stable releases are over time.
This makes them valuable as directional signals. They help teams understand whether changes are improving performance and allow them to track progress at scale.
DORA and high-level metrics usually show the output of the process. They’re a good indication of the direction we’re going, but there are so many factors that go into them that they don’t make good targets. - Simon
At the same time, these metrics operate at a distance from the actual experience of developers. They reflect the result of many underlying factors - tooling, workflows, collaboration, handoffs, and decision-making - without revealing which of these elements is responsible for the outcome.
Engineering metrics show what is happening, but not why. They indicate direction, but not cause.
Developer Experience surveys capture how the system is perceived by the people working within it. They reflect lived experience - whether tools feel reliable, workflows are smooth, and day-to-day work is effective or frustrating.
This makes surveys a critical complement to quantitative data. They surface patterns in sentiment across the organization and different stages of the delivery process. With them, you can identify input factors and areas where experience may be improving or deteriorating - where time is lost and frustration increases not only due to tooling but also due to a lack of clarity, understanding, or collaboration.
I stay closely engaged with survey feedback - for me, that means reading all the comments. - Simon
Comments connect data to reality. They turn signals into insight. Rather than treating them as secondary data, Datadog treats comments as a primary source of understanding - the place where signals gain meaning.
Comments reveal nuance. They surface edge cases, explain frustrations, and highlight the specific moments where the system breaks down. They connect abstract signals to real situations.
This is where feedback becomes actionable - not just measurable.
Even detailed feedback has limits. Some aspects of developer experience cannot be fully captured in words - they need to be experienced.
We have a cross-team embed process. The default duration is about two weeks - we keep it short on purpose, because it makes it much easier to adopt and has less impact on a team’s roadmap. The idea is that someone from one team will go and sit with another team, work with them directly, and experience their workflow, their challenges, and their constraints. It’s really about creating that human-to-human connection and making sure people understand what others are going through - not just through feedback, but through actual experience. - Simon
Short effort. Deep understanding. Assumptions are replaced with direct insight, and abstract signals become concrete.
We use donut meetings - it’s a random match between two or three people. It gives them a chance to connect, talk about what they’re working on, and share context. It’s very lightweight and informal, but it helps build connections across teams. - Simon
Minimal effort. No coordination, no preparation, and no disruption to team workflows - yet over time, they build a dense network of relationships across the organization.
Continuous connection. These small interactions create what might otherwise be missing at scale: familiarity. They make it easier to ask questions, share feedback, and reach out across boundaries. Instead of feedback having to travel through formal channels, it can flow directly between people.
What emerges from this approach is not just a collection of signals, but a system of understanding.
Together they create understanding. Signals are not just collected - they are interpreted, connected, and grounded in both lived experience and human relationships.
Understanding the system is not enough. A feedback loop only works if it leads to action.
Taking action, and communicating it, is essential to keep feedback coming. People need to see there’s a reason to give it. - Simon
Visibility creates trust. Action sustains the loop.
Autonomy is what turns insight into movement. It is the point where developers decide what matters, how to respond, and how to balance competing priorities in real time.
User signals are how teams know whether they’re getting warmer or colder - whether they’re moving closer to real value or drifting away from it. - Jon
Autonomy is where signals turn into decisions. It’s about creating the right environment for local decision-making, which requires:
Without it, feedback becomes noise.
Not everything can be addressed. But everything should be acknowledged. At Datadog, users are not just heard, they are invited into the solution.
Rather than treating feedback as a passive input, teams encourage contributors to take part in the process itself - whether by submitting pull requests, joining discussions, or even embedding temporarily with the team to work on improvements firsthand.
This fundamentally changes the nature of the loop. Users are no longer external to the system; they become active participants in shaping it.
What Datadog shows is not a set of practices, but a system. A system where:
Ownership is distributed, not centralized. Developers are not just consumers of tools and processes - they are responsible for shaping them.
Feedback is actively welcomed. It is acknowledged, explored, and treated as a valuable signal, not as noise or interruption.
Signals lead to action. Input is not collected for its own sake, but used to inform decisions and drive change.
And most importantly, the loop is always closed. Decisions are communicated back, outcomes are shared, and contributors can see the impact of their input.
That’s when feedback becomes part of development. And the system starts to learn.It only works if you keep it alive.
