Atlassian | 2023-2025

Lego platform

LEGO Shared Capabilities is a platform-level initiative I led to establish a reusable, scalable foundation for admin data movement across Atlassian Cloud.

By defining a capabilities-first model, I enabled Data Portability teams to design and ship customer-facing experiences using shared, composable building blocks, reducing duplication, accelerating time-to-market, and improving consistency across multiple data movement admin features.

Scope

Multi-year 0→1 platform foundationOngoing 1→many adoption across DaPo initiatives

Focus areas

Capability definition, composability, admin & customer-facing patterns, system consistency

My role

Platform UX ownership, cross-team alignment, capability design, design system & platform collaboration

4+

capabilities built

84%

adoption rate across teams

33%

reduction in delivery time

Problem

Within the admin cloud ecosystem, multiple teams were independently designing and shipping similar system-level components, each packaged differently for specific features. While the underlying problems were related, teams were:

  • Designing similar workflows repeatedly
  • Solving the same edge cases in parallel
  • Creating experiences that were hard to combine later
  • Accumulating UX and technical debt with every new launch

The platform needed to scale, not just in features, but in how capabilities were designed, composed, and consistently reused.

The challenge: A multi-year 0→1 and 1→many platform initiative that required aligning multiple teams to abstract shared system capabilities from feature-specific implementations like balancing architectural constraints, extensibility, and product velocity while creating a foundation that could scale across current and future admin cloud experiences.

A platform-first strategic bet

  • As admin data movement scaled across multiple features, we chose to stop optimizing for feature-by-feature delivery and instead invest in a shared capabilities platform.
  • The bet was that abstracting the most common and complex parts of data movement into reusable, product-agnostic capabilities would reduce duplication, improve experience consistency, and enable faster delivery as adoption increased without constraining feature-level innovation.
  • We intentionally centralized repeatable system concerns while leaving differentiation at the edges, trading short-term velocity for long-term system health and scale.

Principles

This project required navigating deep technical and organizational constraints:

Build to scale, not for a single use case

Only solutions that could extend across current and future data portability experiences qualified as shared capabilities; feature-specific abstractions stayed local.

Centralize the repeatable, preserve flexibility at the edges

We abstracted the highest-cost, common system concerns while allowing teams to compose and extend capabilities without rigid workflows.

Adoption through collaboration, not governance

Capabilities earned adoption by being easier to use and evolve than bespoke solutions, driven through partnership rather than mandate.

Reliability, performance, and iteration are non-negotiable

Shared capabilities were held to a higher bar for stability and observability and shipped incrementally to evolve through real usage.

Lego anatomy (how this works)

Each LEGO capability was designed as a layered system that balanced standardization with flexibility. Rather than shipping fixed end-to-end flows, we defined a clear progression—from opinionated foundations to extensible implementations—that teams could adopt and evolve based on their needs.

A shared interaction model across the data movement features

While capabilities abstracted the technical and architectural layer, we also standardized the end-to-end interaction model for how admins configure, run, and evolve data movement operations that largely remains the primary technical task performed across these features.

Every capability followed a consistent lifecycle:

  1. Configure (fist-time setup)

Admins select scope, validate inputs, and define operational rules through a structured, predictable setup flow.

  1. Execute (Run operation)

Predefined configurations can be executed safely, with confirmation and guardrails to prevent errors.

  1. Monitor (Edit configuration)

Admins can review details, adjust scope, and evolve operations without rebuilding workflows from scratch.

A shared interaction model across the data movement features

It transformed from feature-owned, duplicated implementations with divergent UX and isolated improvements to a shared capabilities platform where core system logic was centralized, experiences became composable, and improvements scaled across features.

Atlassian | 2023-2025

Lego platform

LEGO Shared Capabilities is a platform-level initiative I led to establish a reusable, scalable foundation for admin data movement across Atlassian Cloud.

By defining a capabilities-first model, I enabled Data Portability teams to design and ship customer-facing experiences using shared, composable building blocks, reducing duplication, accelerating time-to-market, and improving consistency across multiple data movement admin features.

Scope

Multi-year 0→1 platform foundationOngoing 1→many adoption across DaPo initiatives

Focus areas

Capability definition, composability, admin & customer-facing patterns, system consistency

My role

Platform UX ownership, cross-team alignment, capability design, design system & platform collaboration

4+

capabilities built

84%

adoption rate across teams

33%

reduction in delivery time

Problem

Within the admin cloud ecosystem, multiple teams were independently designing and shipping similar system-level components, each packaged differently for specific features. While the underlying problems were related, teams were:

  • Designing similar workflows repeatedly
  • Solving the same edge cases in parallel
  • Creating experiences that were hard to combine later
  • Accumulating UX and technical debt with every new launch

The platform needed to scale, not just in features, but in how capabilities were designed, composed, and consistently reused.

The challenge: A multi-year 0→1 and 1→many platform initiative that required aligning multiple teams to abstract shared system capabilities from feature-specific implementations like balancing architectural constraints, extensibility, and product velocity while creating a foundation that could scale across current and future admin cloud experiences.

A platform-first strategic bet

  • As admin data movement scaled across multiple features, we chose to stop optimizing for feature-by-feature delivery and instead invest in a shared capabilities platform.
  • The bet was that abstracting the most common and complex parts of data movement into reusable, product-agnostic capabilities would reduce duplication, improve experience consistency, and enable faster delivery as adoption increased without constraining feature-level innovation.
  • We intentionally centralized repeatable system concerns while leaving differentiation at the edges, trading short-term velocity for long-term system health and scale.

Principles

This project required navigating deep technical and organizational constraints:

Build to scale, not for a single use case

Only solutions that could extend across current and future data portability experiences qualified as shared capabilities; feature-specific abstractions stayed local.

Centralize the repeatable, preserve flexibility at the edges

We abstracted the highest-cost, common system concerns while allowing teams to compose and extend capabilities without rigid workflows.

Adoption through collaboration, not governance

Capabilities earned adoption by being easier to use and evolve than bespoke solutions, driven through partnership rather than mandate.

Reliability, performance, and iteration are non-negotiable

Shared capabilities were held to a higher bar for stability and observability and shipped incrementally to evolve through real usage.

Lego anatomy (how this works)

Each LEGO capability was designed as a layered system that balanced standardization with flexibility. Rather than shipping fixed end-to-end flows, we defined a clear progression—from opinionated foundations to extensible implementations—that teams could adopt and evolve based on their needs.

A shared interaction model across the data movement features

While capabilities abstracted the technical and architectural layer, we also standardized the end-to-end interaction model for how admins configure, run, and evolve data movement operations that largely remains the primary technical task performed across these features.

Every capability followed a consistent lifecycle:

  1. Configure (fist-time setup)

Admins select scope, validate inputs, and define operational rules through a structured, predictable setup flow.

  1. Execute (Run operation)

Predefined configurations can be executed safely, with confirmation and guardrails to prevent errors.

  1. Monitor (Edit configuration)

Admins can review details, adjust scope, and evolve operations without rebuilding workflows from scratch.

A shared interaction model across the data movement features

It transformed from feature-owned, duplicated implementations with divergent UX and isolated improvements to a shared capabilities platform where core system logic was centralized, experiences became composable, and improvements scaled across features.