April 2, 2026

Someone asked me how we maintain such a close relationship between product/eng on our Code Security team at Datadog to execute and drive strong results. This is a cleaner representation of what I shared with them.

All of the below first assumes that we have the right people on the bus. We do.

• PM/EM are two peas in a pod. (IMO there should always be two peas (leads) to one pod (product area), even if there isn’t a clean team structure). My engineering counterpart is Julien Delange. Julien and I are almost always on the same page, and if we aren’t, we resolve it quickly and with honesty. The fact that we are crystal clear on The Plan makes team alignment (between me and other EMs, between me and other ICs, and eng w/ other PMs on our team) much easier. Being located in the same office helps a lot.
• PM/EM lead by example. Anything we ask our team to do, we do ourselves. Julien asks the team to join customer calls because he does this himself. I ask the team to respond to support questions because I do this myself. Trust is earned by example, otherwise words are just words.
• Leads constantly bring product/business value context to conversations. In 1:1s, sprint planning, and team-wide meetings, we talk about: how would this feature actually bring value to the customer? What could they do now that they couldn’t do before? What would they have to do instead if they didn’t have this feature? What deal does this unblock? How much revenue depends on this feature? How does this help the goals of the product overall? The portfolio overall? If EM doesn’t know this, they should. This is important because the default level of thinking for an IC engineer is at the implementation level - the altitudes are different, and PM/EM each have a responsibility to switch altitudes and bridge the gap.
• Leads overcommunicate on product/business value. Sounds dumb, but I’ve learned that most things PMs think are obvious when it comes to product/business value are not obvious to the engineering team. PMs spend all day hearing and thinking about customer stories, their pain, what the ideal solution to solve that pain should look like, and how to frame a narrative around that solution. Engineers do not. Also, as a general principle, you need to say something more than once for it to stick with someone.
• Engineers viscerally understand customer pain. A core element of our team is sharing feedback from PMs' customer interactions with engineers, and doing this often and in depth. By in depth, I mean that I have shared recordings of calls where customers said things like “your UI is not worth paying for” to my face, watched them with the team, discussed the product feedback as a group. It reinforces the truths that 1) just because you shipped something does not mean it’s good, and 2) the customer is the only arbiter of what has value. Having rituals for this is great - for us, this has looked like biweekly customer call watch parties, monthly session replay reviews, inviting engineers on customer calls, and sharing call snippets and meeting notes on Slack.
• Our MVPs are almost embarrassing. This is a big lesson I have learned from Julien. Shipping scrappy MVPs allows us to get something into the hands of customers as fast as possible and iterate from there. The product feedback we get from shipping early is always worth the “well this was kind of wonky when I tried it at first but now it seems to work” remarks from customers.
• We focus. A fast-moving, iterative approach does not mean we respond to every piece of feedback with a PR. It does not mean we expand the scope of the product unnecessarily. We’ve seen this in other teams, and it can result in a lack of focus, which can affect execution quality and/or delivery of customer value. The only way we have executed somewhat to our expectations is to do one thing at a time, not 100 things at a time. One engineer shipping one solid feature from start to finish in a sprint is way better than that person half-assing 3 different features in the same sprint. EM needs to hold each IC engineer accountable to this.
• Engineers have ownership over the same part of the product across sprints or even quarters, as opposed to picking up random tickets for unrelated features. [redacted] is our AI-native SAST person. [redacted] is our false positives person. This makes it easier for the team to maintain focus and understand product/business value. Within this model, we’ve seen engineers start to have a real sense of end-to-end ownership, and they’ve developed opinions over time on what the user experience should be and what future improvements can look like, which is awesome. Someone who is always context switching between projects would likely feel less bought in the impact of the projects they work on.
• Communication happens out in the open. People love private Slack DMs. Part of this is because it can be scary to share opinions or ask questions in public channels. This started to be a pattern on the team a little while back, but we pushed everyone to use public channels, because open communication gives everyone more visibility about ongoing initiatives. Nobody wants to feel like they’re out of the loop or learn about some new project that’s been happening for a while… on their own team! Having public backroom channels on Code Security also allows other teams to stay up to date on what we’re working on and ask us questions. It has been greatly beneficial for x-team alignment.
• Wins are shared openly and often. Deal closed? Slack post. Blog published? Slack post. Engineer helped to troubleshoot a customer setup during a trial? Slack post. Customer said they liked a feature? Slack post. This is not only helpful for team morale, but helps the team see the impact of their work. You can’t have enough of this (just make sure it’s always grounded in reality 😉). Thank you’s go a long way, because it truly does take a village.
• We operate lean. We don’t hire when we don’t need to. Scaling human collaboration is one of the hardest problems period, why would we invite more complexity without a strong need to?
• We optimize for intellectual honesty. We do not focus on optics or politics. We do not optimize for looking good to leadership. We own our mistakes (and we’ve made a ton of them). We are honest with ourselves and everyone. What we say within the team, is what we say to sister teams, is what we say to sales, is what we say to marketing, is what we say to customers, is what we say to middle management, is what we say to executive leadership. Of course, there is a level of tact involved, but I truly believe that when this starts to break down too much between groups, you start to spend more time framing the right narratives to the right people than focusing on what actually matters: listening to customers and building the right things. Everything else is noise.