Case Study — Arlo

Clarifying Internal
Workflow Structure Across Teams

Internal workflows existed across teams — but were not consistently defined or understood. The problem wasn't missing tools. It was the absence of shared structure that teams could operate against reliably.

Role
Program Management · Internal Systems
Domain
Internal Platforms · Operations
Scope
Cross-functional · Multi-team
Focus
Workflow Clarity · Usability
01

The Problem

At Arlo, internal workflows across teams were supported by multiple tools and processes — but lacked consistency in how they were defined and used.

This created friction in coordination, inconsistent data visibility, and inefficiencies when teams needed to operate across functions. The issue wasn't that tools were missing. It was that the workflows underneath them weren't clearly or consistently structured.

Different teams required consistent data visibility while maintaining flexibility in how they executed day to day.

Without a shared definition of how workflows should operate, even well-supported systems break at the points where teams interact.

02

What I Did

I led the effort to define shared workflow structures across teams, working through resistance to ensure changes were not just agreed upon, but consistently adopted.

At this point, I had two options: continue managing across domains through coordination and follow-ups, or introduce structure that could reduce reliance on individual effort. I chose to introduce structure, even though it required upfront overhead and added process, because without it, execution would remain inconsistent across priorities.

03

The Key Tradeoff

Consistency vs. flexibility
We introduced clearer workflow definitions despite resistance from teams who viewed it as additional process overhead, because without it, coordination and data inconsistencies persisted across teams.
The approach: standardize core structures and data expectations while allowing teams flexibility in how they executed within those boundaries. We leaned toward stronger consistency, recognizing that shared structure across teams was more critical than preserving individual workflow preferences.
04

Execution

The work focused on making workflows usable and consistent across teams — not just documenting them.

01 Defined workflow requirements — clarified system behavior and expectations across teams so different functions could operate from the same baseline
02 Drove adoption, not just agreement — pushed for workflow changes to be consistently followed in practice, working through resistance from teams that preferred existing ways of operating
03 Improved internal platform workflows — reduced coordination friction in day-to-day operations by reflecting clearer definitions within existing tools
05

Results

→ Improved consistency in workflow execution across teams and functions
→ Made workflow progress and ownership clearer across teams operating in shared systems
→ Reduced friction in cross-functional coordination by clarifying workflow structure and ownership

The impact was less about metrics and more about how teams experienced the system. Teams moved from navigating loosely defined workflows to operating within a clearer structure — where ownership, expectations, and system state were aligned. This made cross-functional coordination more predictable and reduced friction in day-to-day execution.

This reduced execution risk across parallel initiatives, making outcomes less dependent on individual coordination.

06

Reflection

What this taught me

Internal systems often fail not because of missing functionality — but because workflows are not consistently defined or understood across the teams that depend on them.

Even small improvements in clarity and structure can significantly improve coordination and usability at scale. The tool is rarely the problem. The shared understanding of how to use it is.

This experience reinforced a pattern I've seen across different contexts: the work that matters most is often the least visible — defining structure, clarifying ownership, and ensuring that different teams can operate from the same baseline. At Arlo, this showed up at a more executional level — less about system architecture, more about getting teams to actually operate from the same definition.

← Previous
NETGEAR — Aligning Cross-Functional Workflows