How Snowflake’s DevProd team operates

The communication channels, rhythms, and principles that made Snowflake’s DevProd team one of the most trusted teams in the company.

Welcome to the latest issue of Engineering Enablement, a weekly newsletter sharing research and perspectives on developer productivity.

Note: I’m co-hosting a live discussion July 17th on how to measure AI code assistants and agents. We’ll share recommended metrics, discuss topics like how to think about measuring autonomous agents, and more. Register to join the discussion here.

---

On the latest Engineering Enablement podcast, I was joined by returning guests Amy Yuan and Gilad Turbahn, who lead Developer Productivity at Snowflake. Previously on the show, Amy and Gilad shared how their developer productivity initiative came to be and how they approach measurement. This time, we focused on how they actually execute as a team.

Amy and Gilad have codified what it looks like to operate at a high level as a DevProd team—and in doing so, they’ve become one of the most trusted and sought-after teams at Snowflake. Today’s newsletter shares some of the key moments from our conversation, including their operating principles, how they structure their communication and meetings, and how they build strong relationships with their internal customers.

The insights shared by Gilad and Amy may lend inspiration to other Developer Productivity teams looking to level up. Read on for an excerpt from our discussion, or listen to the full conversation here.

---

Last time, we talked about how your Developer Productivity team came to be and how you think about measurement. This time, I want to dig into execution. When you say "operational excellence," what does that actually mean?

Gilad: For us, it starts with trust. That’s the baseline. Developers need to trust that our systems work. I like to say that it’s like electricity—you don’t think about whether it’ll turn on, it just turns on. And if something breaks, you know someone will fix it, and fast. That’s what we aim for as a DevProd team.

So when we talk about operational excellence, we mean treating our internal tools like production-grade products. SLAs, dashboards, post-mortems—the same way you'd run any critical service.

Amy: Exactly. And the whole team has to see developers as real customers, even though they’re not paying customers. That mindset—that we have real customers—has to be in our DNA. It shows up not just in how we run our tools, but in things like documentation too. Everything is treated like it’s customer-facing.

How does that show up in your day-to-day operations?

Gilad: Let me give you one example: help channels. A few months ago, they were a mess. People didn’t know where to go, and our team couldn’t triage things properly. So we standardized everything: #help-ide, #help-pr, #help-wm, etc. We also stopped giving one-off answers and started pointing people to real documentation.

And we always close the loop. If someone files a request, we’ll circle back even if it’s to say, "This is coming in two months." That feedback loop builds trust.

You’re clearly intentional about this work. What are some common challenges you’ve seen other DevProd teams struggle with when it comes to execution?

Amy: Two things always come up: First, getting alignment across teams. If Team A needs something from Team B, and Team B doesn’t think it’s important, nothing moves. Second is adoption. Even when you build a clearly better tool, developers don’t always want to switch. That’s the “baby duck syndrome”—people stick to what they first learned.

Gilad: I’ll add two more. One is lifecycle thinking: early adopters are easy, but at some point, you have to shift tactics to reach laggards. That’s when we bring in more top-down pressure: setting deadlines, looping in directors to make adoption an expectation rather than just an option.

The second is understanding that trust isn’t uniform. Some teams love us, while others might think we’re clueless. That means you have to engage team by team, understand their pain points, and show you’re listening.

So how do you operationalize all of this? What’s in your actual playbook?

Gilad: We start with a simple question: who are our users, and how do we build trust with each of them? Then we tailor communication by group—sometimes Slack is enough, other times we need to show up in person or do a roadshow.

We use Customer Advisory Boards, surveys, interviews, and onsite visits. It’s like playing different drums at different rhythms, depending on the product and audience.

Amy: I'd summarize it into five main rhythms:

1. Weekly newsletter and biweekly product all-hands.

2. Quarterly surveys that feed into planning.

3. Frequent user interviews across levels.

4. Roadshows to individual teams.

5. Targeted adoption efforts, top-down or grassroots, depending on the stage.

The common thread amongst these is to always close the loop. People get tired of hearing us say it, but that’s our team’s mantra.

What do you think would happen if you didn’t do all this?

Amy: Developers would feel abandoned. Especially when you’re deprecating old tools and introducing new ones. If you don’t bring people along, they lose faith that things are improving or that anyone even cares.

Gilad: I’ve seen that shift firsthand. Early on, teams didn’t want to talk to us. Now, we’re getting pulled into new areas. People see the progress and want in. That’s the clearest sign we’ve built trust.

I loved something you shared with me earlier: that you try to plug into existing communication channels, just like you do with developer workflows. What does that look like?

Amy: When we visited Berlin and Warsaw, we realized our U.S.-based updates weren’t reaching those teams. So we tapped into their existing forums, like a Monday office-wide standup in Berlin, for example. That worked way better.

Same with local team all-hands. Those are much more effective at reaching people than massive company-wide updates. We tailor our message for each group, show relevant adoption data, and always include a call to action.

Gilad: And we customize everything: the message, the data, even the length of the presentation. We’re there to meet people where they are and show them that we know their reality.

Amy: Showing data helps too. We bring metrics from system logs, surveys, and feedback so teams know we understand their journey. That builds confidence.

Gilad: It’s worth emphasizing that being in-person can really make a difference. When you’re on-site, you get a feel for things you’d never notice remotely. Plus, we could tailor our support and comms much more effectively after that trip.

You’ve also talked about using insiders as your messengers. Can you elaborate on that?

Amy: A lot of times, developers have a default higher trust level with people who are on the same team, because they feel like they understand their lived experience, versus someone else like a central team. That’s why we built a Customer Advisory Board. Our CAB members are early adopters who’ve helped shape the tools and now advocate for them inside their teams.

For example, during the two quarters we were improving Cloud Workspaces and CI, we had a lot of volunteers embedded in the work. Later, they told us they gained a much deeper appreciation for how complex things are, both technically and organizationally. That experience made them natural messengers. They could go back to their teams and say, “I worked on this,” or, “I’ve used this and it’s a huge improvement.”

Take our Berlin team as an example. Because of the time zone difference, they can be a bit more disconnected. But they had early adopters too. One of them demoed Cloud Workspaces during their Monday stand-up and showed how it made him 2–3x more productive. After that demo, adoption in that office spiked.

Gilad: And it’s not always formal leaders. Often it’s the person everyone naturally listens to. If we can turn them into supporters, or at least earn their trust, that unlocks the rest of the team.

That’s why, when we visited Berlin, Warsaw, and teams in the U.S., we made a point of identifying those trusted voices and spending real time with them. If we can convert a detractor who’s also an influencer, it can make a huge difference. With that said, not every influencer becomes a superfan. But even if they come to trust us just enough to give us the benefit of the doubt, that’s often all we need to get their team to engage. That’s how we move from early adopters to the early and late majority: by working through the people their peers already trust.

Tell me more about how your Customer Advisory Board works.

Gilad: Sure. The idea of a CAB is pretty common in the industry. Product managers have used them for years. The basic concept is simple: you bring together a diverse group of users to give you feedback, help validate your thinking, and share what’s working or not from their perspective. Once you have that group, you create space for two-way communication—sharing roadmaps, designs, quarterly plans—and asking for input on what’s top of mind for them.

At Snowflake, we’re actually revamping our CAB right now. We hold a 45-minute meeting once a month, usually on the third Thursday, so it’s easy for people to plan around. We also have a dedicated Slack channel where we post updates, share new ideas, and ask for feedback in between meetings. That async communication has been really valuable.

As for how we pick members, there’s no single process. Some people join because they stood out in a customer interview. Others are nominated by their directors, especially if they’re seen as strong influencers or great communicators. We’re looking for people who care, who want to make things better, and who will engage honestly.

Importantly, the CAB is informal. We don’t require people to attend every meeting. It’s a group of engaged volunteers who get early access to what we’re working on and help shape where we go. For example, we’re currently experimenting with an LLM-powered doc assistant, and CAB members are helping us figure out what works and what doesn’t. They’re deeply involved. That’s the kind of hands-on input we’re looking for.

How do you set goals and roadmaps?

Gilad: We plan quarterly and annually. Quarterly is more tactical—what themes we’re investing in, what metrics we’re moving. Annual is more strategic—what we’re saying yes and no to.

We’re trying something called thematic prioritization. Instead of just listing projects, teams pick 2–3 themes and commit to moving a metric tied to each. It helps avoid spreading ourselves too thin.

Amy: And we balance short-term wins with long-term bets. For example, we’re rebuilding CI, which is a long effort, but we make sure developers see incremental progress each quarter.

Then, once plans are set, we communicate them broadly. Exec reviews, company-wide updates, team-level roadshows. We repeat the message often, in different formats.

Gilad: And we keep it two-way. We collect feedback through CABs, TL forums, surveys… Plans can evolve. What matters is that we’re thoughtful, transparent, and always focused on customer impact.

---

Who’s hiring right now

This week’s featured DevProd & Platform job openings. See more open roles here.

• Dropbox is hiring multiple Infrastructure and AI Dev Tools roles | US (Remote)

• Atlassian Williams Racing is hiring a Software Engineer - Engineering Acceleration | Grove, UK

• ScalePad is hiring a Head of AI Engineering & Enablement | Canada (Remote or in-office)

• Lyft is hiring a Senior Software Engineer - Developer Experience | Toronto, ON

---

That’s it for this week. Thanks for reading.

-Abi