Curriculum Vitae

Professional Resume

I build product software at the intersection of engineering, product, and people. Over the last 15+ years, I've worked across backend systems, platform foundations, product development, and engineering leadership — helping teams turn ambiguity into clear, sustainable execution.

My work combines technical depth, product thinking, and people-first leadership. I'm most effective in environments where I can contribute beyond implementation: shaping ideas early, defining scope, navigating trade-offs, and helping build systems and teams that can evolve without unnecessary complexity.

More recently, I've also been exploring AI-native product development — using AI not just to speed up coding, but to improve the full path from ideation and product definition to technical proposals, scope slicing, implementation, testing, and delivery.

Last updated: April 2026 • PDF format • 3 pages

Download PDFView Online

Current Focus

My work today is organized around three connected areas that reinforce each other in practice.

Product engineering

At seQura, I work in the Merchant Experience team in a 0→1 product engineering role spanning ideation, product definition, technical decisions, and execution. I'm drawn to shaping ideas early, making trade-offs explicit, and turning ambiguous opportunities into useful, maintainable product experiences.

0→1 building

As Co-Founder & Product Engineer at Avenida, I build a product end to end in close collaboration with Product. It's a space where I stay deeply hands-on across architecture, implementation, delivery, and product shaping — where engineering judgment and product thinking live in the same person.

AI-native workflows

A growing part of my work is designing AI-native ways of building products: practical workflows that improve clarity, decision-making, and execution across the full lifecycle — from idea to production. The interest isn't speed alone, but using AI to build with more deliberateness and less noise.

How I Work

I work best where engineering, product, and execution are treated as part of the same system — not as separate concerns handed off between silos.

Start from the problem

I prefer beginning with the problem space, user need, and product context — not just the backlog. Good engineering starts with better framing. I try to align on what success looks like before defining what to build, because that clarity almost always produces better systems downstream.

Make scope and trade-offs explicit

Ambiguity is expensive. I invest in shaping ideas early, reducing uncertainty, and making trade-offs visible — to the team and to stakeholders. Clarity upstream usually creates better systems and healthier delivery downstream.

Build systems that can evolve

I value simplicity, maintainability, and operational clarity. Systems should be robust enough for growth but simple enough to remain understandable by the people maintaining them. Accidental complexity compounds quietly — and it's usually avoidable.

Prefer sustainable execution over heroics

High-performing teams don't need constant intensity. They need clear ownership, good context, strong feedback loops, and ways of working that hold up over time. Sustainable pace is not a concession — it's a precondition for quality.

Use AI as a workflow capability

I'm interested in AI not just as a coding assistant, but as a way to improve how software gets built — across ideation, definition, slicing, implementation, testing, and delivery. The question I keep asking isn't "how fast can I ship?" but "how can I think and decide more clearly?"

Leadership Style

A big part of my career has been about people leadership. I care deeply about creating healthy engineering environments where psychological safety, clear ownership, high standards, and honest communication can coexist. My style is people-first but direct: strong teams do their best work when expectations are clear, trust is real, and execution is sustainable rather than heroic.

I'm especially interested in the kind of leadership that connects product direction, technical judgment, team health, and delivery discipline — not as separate concerns, but as parts of the same operating model.

What this looks like in practice

Intentional remote leadership

  • Clear goals, written context, and transparent decisions so no one is blocked by time zones.
  • Rituals that reinforce alignment: roadmap reviews, architecture forums, and predictable delivery cadences.

Coaching and growth

  • 1:1s as a safe space for development: career paths, feedback, and early signals of burnout or friction.
  • Fair distribution of high-impact work and sponsorship that makes talent visible.

Pragmatic technical leadership

  • Architectures that favor reliability, observability, and maintainability over accidental complexity.
  • Guardrails and standards (ADRs, code review norms, incident/postmortem quality) that balance speed and quality.

Outcome-driven delivery

  • Tight partnership with Product and Design to solve real user problems.
  • Focus on lead time, reliability, and execution clarity — not vanity metrics.

Inclusive by design

  • Diversity as a transversal practice: how we collaborate, give credit, assign projects, and honor different realities.
  • Accessible communication: agendas in advance, notes/recordings, clear language, and organized documentation.

Principles I live by

  • Clarity over control: Set context and constraints; empower teams to decide.
  • Fewer, better systems: Reduce complexity to make reliability repeatable.
  • Feedback as a habit: Make it frequent, specific, and growth-oriented.
  • Consistency > heroics: Reliable processes beat last-minute pushes.
  • Inclusion is operational: Design rituals and communication that welcome, hear, and reflect every voice in decisions.
  • Psychological safety: Enable candid debate, asking for help, and thoughtful risk-taking without fear of blame.

Favorite quote

"Culture eats strategy for breakfast." — Peter Drucker
Great strategies endure only when everyday behaviors make them real.