Coaching, mentoring, and growing high performing teams and individuals.

I give autonomy early because watching how someone handles real decisions tells me more than a generic management playbook ever could.

When I take on a new team or inherit a new person, I don't walk in with a set playbook. I listen. I get to know them, their background, their products, their world. I ask what's working, and what isn't. I observe how they operate in different scenarios — meetings, when making decisions, handling ambiguity, when faced with pressure. I look at their work. I talk to the people around them and ask the same questions: what's working, what isn't, what would you change. I give autonomy early, deliberately, and appropriately, because I need to see what happens naturally before I decide what kind of support someone actually needs. The diagnosis comes from watching, not assuming.

Strong judgment, confidence, validation discipline, and self-direction are different needs. Each requires different support.

I currently manage three direct reports at different levels and mentor two people outside my reporting line. Each person gets something different from me because they all have different needs. I've managed an individual who has great judgment, but hesitated to act until he had all the answers. He led with questions while already having a point of view, even when the move was to act quickly. I sensed he was uncomfortable with ambiguity and getting it wrong, while I knew he had sound judgment and was extremely capable. His withholding POV in group settings had left a few colleagues doubting his knowledge or ability to make decisions, while the truth was he optimized for consensus from the room for what he already knew to be the best course of action. So the correction there was to change the frame and put his opinion forward THEN follow with the ask, demonstrating thought leadership while also giving the room something to react to, rather than start from a blank slate. I also managed someone with the opposite issue. She was decisive and had strong conviction, yet was quick to move without market evidence, which left her flat footed when her decisions were challenged by stakeholders. The move for her was to slow down and collect competitive intel or voice of customer before presenting the plan to stakeholders because confidence and high personal conviction alone doesn't make every case. When working with a technical resource who was tasked with producing client facing deliverables, a long lead time with high autonomy was not the answer. When the explicit assignment volume was low, the delivery times lagged as he wasn't self-directed enough to see the bigger picture of all the support the teams need. He needed explicit deadlines, structured accountability, and a larger backlog of explicit requests in order to succeed. In this case, the larger the backlog, the better he performed.

All this to say that there is no universal management style that works, nor does every individual need the same tools. The way I lead best is by paying attention to each person's unique needs and providing the appropriate support in order to grow the team into well rounded individuals.

Micromanagement produces dependence. Experience, followed by a thoughtful debrief, produces judgment.

Strong product teams are forged in environments when they have the ability to act independently, think creativity, make decisions. I like to give opportunities to act and do. Lessons will resonate more from a message poorly delivered to a difficult stakeholder in low-stakes conditions than from a lecture about how to do it right before they even try. I let them run the meeting, own the stakeholder conversation, make the call.

Afterward, we debrief. How did it feel? What worked? What would they change? Course correct together. Experience is what builds strong product people and I have to trust people enough to let them try, while being present enough to catch them when they stumble.

Shared context and clear decision rights changes a disengaged delivery group into a team with real ownership.

I took over a team that was operating as a ticket factory. Various levels of engagement, most of it low. No decisions from the tech lead. Finger-pointing. People waiting to be told how to think by product rather than owning anything themselves. I spent 30 days observing and asking questions and determined that the team needed a reset. I did a level-setting session with everyone — Product, Development, QA — and started with the baseline definitions that we all know: here are the roles, here's how decisions get made, here's what is expected, and here is how we support each other.

The real shift was in the core message: we were a team. Engineering also has decision rights. We don't want them blindly following bad decisions — we want their feedback, their pushback, their ideas for how to do it better. And we committed to always setting the frame so everyone understood what we were building and why. Shared understanding. Shared ownership. Celebrating wins together. Praising often. We win together or we lose together, product and tech are not at odds, but working together. And this changed the game entirely

Influence starts by understanding what each stakeholder needs in order to make—or carry—the decision.

I learn my stakeholders the way I learn my users. What matters to them, how they communicate, what language they think in. Then I talk to them in that language. For executive leadership, that means leading with the ask, following with the evidence: what decision needs to be made, what are the risks, what will it cost, and what's the expected value. For engineering leads, it means framing the why before the what so they're making informed decisions, not taking orders. For peers competing for the same resources, it means showing the mutual benefit rather than arguing priority.

I loop people in early. I address concerns before they become objections. I don't deliver surprises. I always have a plan B and C — contingencies that show I've thought beyond the optimistic path. When something is changing, I don't just communicate it — I deliver the tools other people need to socialize it within their own teams. Influence isn't about being persuasive in a meeting. It's about making it easy for other people to say yes because you've already addressed what would have made them say no.

I know when to push, when to build the evidence, and when to let an idea become familiar before the organization must act on it.

Not every message is ready to be received, so I mix socializing early, finding allies, and managing up with patience and positioning. I give ideas the appropriate time to marinate. I plant seeds and wait. I pitched a platform re-architecture before the org was ready to adopt. I had the buy in from my leader, but there were other priorities, and some stakeholders needed more time with the concept — it was deferred. In the meanwhile, teams started building with a rearchitected platform mentality, and knew the time wasn't right to push harder. I let it marinate. When the burning platform arrived as I had predicted, the framework was already familiar and the solution was ready.

When I escalate, I escalate with evidence, not emotion. When evaluating the case for rearchitecting an API model and adopting a new commercialization strategy to increase revenue capture, I scoped the problem with data, and brought a structured case up the chain. By the time I was in the room making the ask, the case was already made. I don't like surprises in either direction — not for my team, not for senior leaders. I flag what matters to the people it matters to, I lead with honesty, and I never blue-sky a situation that has real risks attached to it.