Leadership

This is how I think about technical leadership. I’ve developed these principles through experience—some from things that worked, more from things that didn’t. They’re not universal truths; they’re what I’ve found effective in the contexts I’ve worked in.

Core Principles

Own the Architecture

I believe technical leaders should own architectural decisions, which means being accountable for the reasoning, the tradeoffs, and the outcomes—not just the diagrams.

What this looks like in practice: I draft the first version of architecture documents and keep them grounded in operational reality. I explicitly name constraints and tradeoffs rather than hiding them behind optimistic assumptions. When decisions turn out to be wrong, I revisit them openly rather than defending them past their usefulness.

Why this matters: Architecture decisions have long tails. A decision made today creates constraints for months or years. If no one owns those decisions—if they emerge from consensus without accountability—bad decisions persist because no one feels empowered to revisit them.

Reduce Operational Load

I design systems and processes that reduce the cognitive load on operators. This means automation, guardrails, and sensible defaults—infrastructure that does the right thing by default and makes the wrong thing hard.

What this looks like in practice: I invest in self-service platforms where teams can deploy without filing tickets. I build guardrails that prevent common mistakes rather than relying on documentation that nobody reads. I automate repetitive tasks even when the first automation takes longer than doing it manually, because it pays off on the second and third iteration.

Why this matters: Operational toil doesn’t scale. Every manual process is a bottleneck. Teams that spend their time fighting infrastructure don’t have time to build products.

Make Decisions Measurable

I attach architectural decisions to concrete questions and measurement plans. This turns “I think this will work” into “we’ll know this works when X metric shows Y.”

What this looks like in practice: When I propose a shared data pipeline, I also define what “noisy neighbor” would look like in metrics and how we’d detect it. When I estimate capacity, I instrument the system so we’ll know whether the estimate was accurate.

Why this matters: Without measurement, architectural decisions become debates about assumptions. With measurement, they become hypotheses that we can validate or invalidate. The learning note on observability and architecture explores this further.

Raise Developer Experience Without Compromising Security

Security that blocks developers creates shadow IT. Developers find workarounds, and those workarounds are usually less secure than the official path. I prefer security that’s built into the platform—guardrails that developers don’t have to think about because they’re just how things work.

What this looks like in practice: I build platforms where the easy path is also the secure path. Credentials come from secret stores, not environment variables pasted into configs. Network policies default to restrictive. Audit logging happens automatically.

Why this matters: The goal is security outcomes, not security friction. Friction creates incentives to circumvent controls.

How This Shows Up

As a Technical Contributor

• I draft architecture proposals and decision records
• I build the platforms and tooling that teams depend on
• I pair roadmap goals with observability so progress is measurable

As a Leader

• I establish templates and paved paths so teams can move fast with fewer sharp edges
• I coach teams toward outcomes, not just output
• I create clear ownership and decision records so that decisions are traceable

Leading Distributed Teams

I’ve been working remotely across geographically distributed teams since 2011, when I joined a Hong Kong-based team from the US. By 2014 I was managing direct reports in Hong Kong across a 12-hour time zone gap, and every role since has been fully remote. Over 15 years of distributed work has shaped how I think about communication and collaboration:

• Async by default, sync when it matters. Most communication should be written and asynchronous. I reserve synchronous time for decisions that benefit from real-time discussion, not for status updates that could be a message.
• Decisions in writing. When team members are spread across time zones, undocumented decisions are invisible decisions. I capture reasoning and context alongside conclusions so that someone waking up 12 hours later has full context without needing to schedule a meeting.
• Intentional overlap. With a 12-hour time zone gap, overlap windows are precious. I structure them around high-value interactions—architecture discussions, problem-solving, feedback—not standups.

Collaboration Style

• Clear ownership: Someone owns each decision and can explain the reasoning
• Short feedback loops: Real data from production, not just quarterly reviews
• Transparent tradeoffs: We name what we’re giving up, not just what we’re gaining
• Cost awareness: We consider operational costs alongside feature development

Where This Shows Up in My Work

• Platform architecture ownership — I designed and built the Kubernetes platform, owning the architectural decisions and their consequences.

• Security platform design — I led the architecture for multi-tenant security systems with explicit tradeoffs around isolation approaches.

• Operational visibility — I built observability systems that answer operational questions, not just generate dashboards.

• Current role — Where I practice these principles daily, balancing hands-on architecture work with team leadership.

What I’m Still Learning

Leadership is a practice, not a destination. Things I’m actively working on:

• Delegating effectively while staying connected enough to make good decisions
• Balancing building things myself versus enabling others to build
• Communicating technical decisions to non-technical stakeholders without losing precision

Related

• Work History — My current and past roles
• Portfolio — Systems I’ve designed and built
• Skills — Technical capabilities I bring to leadership