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

My role was to translate ambiguous workflows into clearer definitions that teams could operate against consistently — working across product, engineering, and operations to define requirements, align stakeholders, and improve how workflows were structured within existing tools.

03

The Key Tradeoff

Consistency vs. flexibility
The key decision was how to improve consistency in workflows without introducing rigidity that would reduce usability for different teams — each of which had legitimate operational differences.
In practice, there was resistance to introducing more structure. Additional definition was seen as adding process overhead and slowing down execution.
We chose to introduce clearer workflow definitions anyway, because without a shared structure, coordination issues would continue to persist 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. Some teams viewed the added structure as process overhead, but without it, inconsistencies in execution and data would have continued to persist.
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.

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