Creating Datadog Campaigns for cross-team initiatives

_YEAR
2025
_{PROJECT TEAM}
1 designer
1 product manager
2 engineers

---

The Scorecards feature in Datadog’s Internal Developer Portal (IDP) helps platform teams define engineering standards and evaluate whether services, repositories, and other entities meet them.

But platform, security, and reliability teams also run time-bound initiatives that require coordination across multiple teams, such as upgrading Kubernetes, fixing dependency issues, reducing cloud costs, or addressing security findings.

Scorecards could show whether teams met ongoing standards, but it wasn’t designed to manage these initiatives. Teams needed a way to define who was responsible, which services and teams were involved, when the work was due, and how much progress had been made.

Through customer calls and feedback from internal users, I identified recurring challenges teams faced when coordinating time-bound initiatives across multiple teams. Ownership, progress updates, and follow-up actions were often scattered across tools like Jira, Slack, and team docs.

This made it difficult to see who was responsible, how much progress had been made, and what needed to happen next. Teams lacked a single place to understand the status of an initiative and take action on the work that remained.

---

No clear ownership
It’s unclear who owns each task, making delegation and accountability difficult

---

No visibility into progress
Updates are scattered across tools, making it hard to see what’s done and what’s left

---

Risk of rework and delays
Lack of coordination leads to duplicated efforts or missed deadlines

Our goal was to help teams create and run time-bound initiatives with clear ownership, visibility into progress, and a clear path to completing the work on time.



Rather than starting from scratch, we built on the Scorecard rules users already had. By adding scope, participating teams, ownership, and a timeline around those rules, we could turn ongoing standards into actionable initiatives with clear goals and accountability.

This goal led us to create a new product called Campaigns. It gives teams a shared place to define an initiative, identify the teams and services involved, assign ownership, and track progress toward a deadline.

By building on the data and workflows already in Datadog, Campaigns reduces the need to coordinate work across spreadsheets and other tools. The goal was to turn an initiative into clear, actionable work that teams could understand, own, and complete together.

Campaigns has two main user groups. Platform engineers need to create and manage campaigns. Developers need to know which of their services are included and what work they have to do.

The needs of these two main user groups led us to focus on three core areas: creating, running, and managing campaigns.

The creation flow would let users define a campaign’s purpose, scope, rules, ownership, and deadline. Once a campaign was running, users needed a place to understand the initiative, take action, and track progress. They also needed a way to manage campaigns over time, including viewing active campaigns, updating their status, and archiving completed work.

_{CAMPAIGN CONFIGURATION} I started with campaign creation, which would primarily be handled by platform teams. They needed to define the campaign’s purpose, choose the relevant Scorecard rules, set ownership and a timeline, determine which teams and services were in scope, and provide clear guidance on what participating teams needed to do.

I organized the creation flow into three parts: defining the campaign and its purpose, setting ownership and a timeline, and defining the scope with a preview of the teams and services involved.

I translated this flow into an initial wireframe. The form on the left guides users through defining the campaign, while the preview on the right shows which entities and teams are in scope, along with their evaluation results.As the design evolved, I added a dedicated step for guidance and consolidated the earlier steps to keep the overall flow to three steps.

I initially explored structured action items, but each initiative required different types of guidance. We chose a Markdown editor instead, giving campaign owners the flexibility to provide instructions, images, and links without being limited to a fixed format.


I then focused on making the preview more useful. I explored different ways to show the campaign scope, participating teams, selected rules, and current evaluation results, along with contextual setup guidance.

Rather than simply repeating what users entered in the form, the preview showed what those choices meant in practice. This helped owners understand the campaign’s impact and catch unexpected entities or evaluation results before launching it.

The campaign detail page is the center of the experience. It needs to give everyone a shared view of the campaign while helping each person focus on what matters to their role.



Campaign owners need to see overall progress, team status, ownership, and deadlines, with ways to follow up when needed. Developers need to quickly find their own entities, see which rules they still needed to meet, and understand what actions to take.

I organized the page from a high-level summary down to more detailed information.

The header showed the campaign name, owner, timeline, description, and key actions.

Below that was an overview of the campaign’s progress, followed by individual entities where users could see how much of the required work had been completed.

This hierarchy was designed around the needs of different users. Shared campaign information came first, while the more detailed entity-level information that developers would use more often came below.

As I moved into high-fidelity design, I explored different ways to organize the information. I focused on what to prioritize, how much information to show at once, and how to make important details easy to find.

---

_{CAMPAIGN MANAGEMENT PAGE}

The management page needs to give platform engineers a place to step back and see multiple campaigns at once, track their status, timelines, and completion rates, and make changes when needed.

I created the wireframe to bring all campaigns into one view, with navigation and filters to help users focus on what was most relevant to them. Each campaign showed key information such as its name, status, scope, timeline, and overall score.

This made it easier to review progress, spot campaigns that needed attention, and take the next step, whether that was viewing details, editing a campaign, or updating its status.

As I moved into high-fidelity design, I explored several layouts, including tables, standard cards, and horizontal cards. I compared how well each option helped users scan key campaign information and compare progress across multiple campaigns.

I also considered how the layout could give Campaigns its own visual identity while clearly distinguishing it from the existing Scorecards experience.

The final Campaigns experience brings initiative setup, guidance, and progress tracking into one place.

Campaign owners can define the scope, assign ownership, set a timeline, select rules, and provide clear guidance for participating teams. Before launching, they can preview who and what is affected. Once the campaign is running, teams can see what they need to do, take action, and track progress toward the deadline.

By bringing ownership, progress, and action together in Datadog, Campaigns gives teams a shared view of the initiative and reduces the need to coordinate work across spreadsheets, Slack, and other tools.

In the first three months after launch, 46 organizations created 89 campaigns, showing early adoption of the new experience.

Customer feedback also reinforced the value of bringing this work into Datadog. One customer used Campaigns to track security initiatives that had previously been managed in spreadsheets. Another expected it to save significant time compared with their existing process. A third used it to coordinate upgrades and retire outdated functionality across the organization while maintaining service maturity standards.

These early adoption signals and customer feedback suggested that Campaigns was addressing a real need for a shared way to track and coordinate cross-team initiatives.

Building Campaigns also gave me a few lessons that shaped how I approach product design. Here are three that stood out.

1. Progress is meaningful only 
when it leads to action
Progress needs to connect to ownership, deadlines, and the work that remains.

2. Different roles need different
levels of information
Campaign owners need to identify teams that are blocked, while developers need clear next steps for the services they own.

3. Communication is part of 
coordination
Making work visible wasn’t enough. 
Campaign owners also needed ways to notify teams and follow up.