THE KIND OF PROBLEMS I WORK ON
Technology programs get interesting when people, systems and priorities intersect.
My role is often to make those intersections visible: understand what needs to happen, identify what could get in the way, bring the right people together, and keep the program moving toward an outcome.
Here are a few problems that show how I approach technical delivery.
WHAT I'VE LEARNED FROM LEADING TECHNOLOGY PROGRAMS
Some of the lessons came from moving people, processes and technology forward at the same time.
When you're managing a portfolio, the work is bigger than the individual projects.
At Screenroot, I managed a portfolio of 12+ projects across Finance/Fintech, Education and Healthcare, while working with clients, delivery teams and external vendors.
That experience taught me to look beyond individual project status — at priorities, dependencies, capacity, client expectations and vendor commitments.
What I learned: portfolio management is about knowing where attention, decisions and intervention are needed — not simply tracking more projects.
Design decisions are delivery decisions too.
Working with products where UI/UX was a significant part of the delivery conversation taught me that design doesn't sit neatly before engineering. User experience, requirements, feasibility, development and testing influence one another.
What I learned: the handoff between design and engineering is itself a delivery dependency. A PM needs to understand what a design decision changes downstream.
The hardest part of automation isn't always the automation.
I led a transition from a more manual QA approach toward automation. The team was initially hesitant about the change, but delivery demand made a more automated approach necessary.
We introduced Katalon, including its AI-assisted capabilities, and worked through the change in the team's way of working rather than treating the tool itself as the solution.
What I learned: the move improved our automation score and reinforced something I have seen repeatedly: technical transformation succeeds when people understand the reason for the change and can see how the new approach helps them work.
A vendor dependency is still a delivery dependency.
Working with external vendors taught me that a vendor relationship cannot be treated as a separate coordination track. Their timelines, assumptions, deliverables and communication can directly affect the team's ability to deliver.
What I learned: make external dependencies visible early — before they become internal delivery problems.
WHAT I BRING TO A PROGRAM
Technical context
I can engage in engineering conversations, understand system-level dependencies and translate technical progress and trade-offs into delivery language.
Delivery discipline
Requirements, milestones, dependencies, risks, roadmaps and execution visibility — with enough structure to keep complexity manageable.
Cross-functional leadership
Engineering, QA, product, security, DevOps, documentation, clients and leadership often see different parts of the same program. I work to connect those views.
Curiosity
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.” And then asking the next question.
THE NEXT LAYER