ABOUT

From building software to leading the systems around it.

I’m a Technical Program Manager with 15 years of experience across software engineering, technical project leadership and complex cross-functional delivery. My work sits where engineering, delivery and business decisions meet.

THE THREAD

I’ve always been interested in what happens underneath the milestone.

I started my career in software engineering, working across development and support lifecycles, programming languages and technology stacks. That technical foundation still influences how I work today: when a project says “API integration,” “cloud migration,” or “automation,” I want to understand what that actually means for the systems and teams involved.

Over time, my role expanded from building and supporting software to coordinating the work around it — requirements, teams, dependencies, risks, vendors, clients and delivery decisions.

15 yearsTechnology & delivery experience
BE ITGoa University
MBA · HRManagement foundation

HOW THE ROLE EVOLVED

The scope changed. The questions changed with it.

01 · TECHNICAL FOUNDATION

Understand the system.

My engineering background means I’m comfortable getting into technical conversations, asking how components interact and understanding what a change means downstream.

02 · PROGRAM LEADERSHIP

Make the work visible.

As programs became broader, the work became less about one team's output and more about requirements, milestones, dependencies, risks, capacity and cross-functional alignment.

03 · PEOPLE & CHANGE

Help people move with the technology.

Some of the hardest delivery problems have involved change: moving teams toward automation, coordinating vendors, balancing different stakeholders and creating enough context for people to make decisions.

What that looks like today

In my current role, I lead concurrent technical programs across engineering, security, DevOps, documentation and client stakeholders. The work involves turning requirements into milestones, making dependencies and blockers visible, coordinating capacity, and keeping technical progress connected to the outcome the program is trying to achieve.

That includes large-scale CI/CD initiatives, security and compliance work, cloud programs and audit readiness. I’ve learned that the PM’s value is often in connecting pieces that otherwise look unrelated — a technical decision here, a testing dependency there, a security requirement somewhere else.

What I’m curious about now

My current learning focus is increasingly around AI-enabled products: generative AI, AI orchestration and agentic workflows, data quality and evaluation, data governance, responsible AI and the program-management questions that come with them.

I’m interested in the space between technical depth and program leadership — understanding enough to participate meaningfully in the conversation while keeping sight of delivery, users and outcomes.

Why I write

Technology becomes harder to manage when the people responsible for delivery can't see what is happening underneath the feature or milestone.

That is why I created Tech Without the Jargon: a series for people who lead technology without necessarily building every component themselves. Each piece starts with an everyday software experience and works backwards to the systems, handoffs and dependencies underneath it.

Explore Tech Without the Jargon →

Still learning. Still asking questions.

I don't think a PM needs to know everything. I do think a strong technical PM should be comfortable saying, “I don't understand that yet. Walk me through it.”