Your résumé, read honestly
What a recruiter actually sees in the first eight seconds, which lines are doing nothing, and what to cut. I'll be straight with you rather than kind about it.
Students · Early careerTechnical Program Manager. I run the programs with too many moving parts, too many stakeholders, and a date that isn't moving. The messier it gets, the more useful I am.
How a program actually moves
Programs delivered end to end — onboarding and lending
Partner platforms and institutions integrated with
Years running cross-functional delivery
Regulated domains — bank account onboarding and lending
A full business lending journey, committed to a date before the requirements were stable. I negotiated scope directly with the client, ran the build across product, engineering, risk and several external vendors, and absorbed a mid-build policy change without moving the launch. The hard part was never the software — it was holding four parties to one sequence.
A consumer lending program running on third-party services no single team owned — when one degraded, everyone agreed it was bad and nobody owned fixing it. I set vendor SLAs, built the escalation path, and tied downtime to lost business so it stopped being an engineering complaint and became a number someone had to answer for.
What it actually took to turn "make me a website" into a page built for two different readers at once — and where the honest version of that process included redoing the same section three times before it was right.
“He handled escalations independently and effectively — managing complex client concerns with diplomacy and professionalism, rarely requiring my intervention.”Kevin Thomas · Manager, Signzy Technologies
I started as an engineer, moved to translating business requirements into things teams could actually build, and now run delivery end to end. It means I know what a vague requirement costs downstream, because I've been the one receiving it.
Own delivery of personal and business lending journeys for an enterprise client end to end — scope, vendors, engineering, risk and the client relationship — including taking those journeys live inside three major consumer platforms. The work lives or dies on dependencies nobody controls, which is the part I'm there for.
Owning deliveryOwned current-account onboarding programs for three of India's large banks and a major payments platform — translating what each client said they wanted into specifications engineering could build against, then staying with it through delivery.
Learning to specifyBuilt and shipped software on large enterprise systems, and spent the period shadowing a product owner — which is where I first saw how a requirement becomes a build plan, and how much gets lost between the two.
Learning to buildI'm the person a program gets handed to when it has too many owners, a hard date, and a client watching. Plans are easy. Landing them through other people's teams, vendors and priorities is the actual job.
I started as an engineer, moved into writing the requirements engineering builds from, and now own whether the thing actually lands. Each step taught me what the previous one was getting wrong — and the pattern I keep finding is that programs rarely fail on the technical problem. They fail on the decision nobody wants to make.
I like the deadline pressure and I like the last-minute problems — the vendor that fails three days out, the requirement that changes after sign-off. That's usually when I'm most useful to a team.
What I want next is more of the hard version of this: regulated, multi-party programs where the date is real, the dependencies aren't mine to control, and shipping it requires getting a lot of people to agree on a sequence.
I didn't have someone to ask when I had no idea what I was doing. I had to work it out on my own, slower than it needed to be. So I keep a few hours aside every week for students and early-career folks — mostly the ones who don't have anyone in their family or network already doing this work.
This sits completely apart from my consulting work. Nothing is being sold here, there's no signup and no waiting list. You write to me, I write back, we talk.
What a recruiter actually sees in the first eight seconds, which lines are doing nothing, and what to cut. I'll be straight with you rather than kind about it.
Students · Early careerHow PM and TPM roles actually differ, what the interviews really test, and how to build proof you can point at before anyone gives you the title.
Career switchersMock rounds on product sense, metrics and execution — and turning what you've already done into stories that land instead of ramble.
Actively interviewingWhich offer to take. Whether to switch. How to handle a manager. How to stop feeling stuck. Not every question is a career question, and that's fine.
AnyoneTell me where you are and what you're stuck on. One honest paragraph is enough — I'd rather hear from someone unsure whether to write than have them talk themselves out of it.
Write to me →