Alay Vora

🤝 Mentorship in Action After my last post on unlearning old skills to grow as a leader, a few people asked what I did keep through those transitions. For me, the answer is simple — mentorship. It’s been the constant across every stage — and honestly, as much about learning as teaching. It reminds me of sports: even the best athletes have coaches, not because they lack skill, but because great coaching builds perspective and resilience. Mentorship does the same for teams — it brings out their best. Early on, I thought mentorship was about giving answers. Over time, I learned it’s about creating space for others to find their own. Now, seeing someone I’ve coached step into leadership is the most rewarding part of the journey. As my org grew, mentorship evolved into a different kind of conversation — connecting with people several layers away. That’s where skip-levels started changing how I lead. More on that soon. ⸻ #Leadership #Mentorship #Growth #CareerJourney

69

When engineering leaders walk into PE board conversations armed with roadmaps, sprint velocity, and feature delivery timelines, that preparation isn't wrong. It's just incomplete. Boards care about product delivery — but not the way you think. They're not evaluating whether your team ships fast. They're evaluating whether what you're shipping is the right bet, and whether you can defend that in business terms. To a PE board, a roadmap isn't a delivery plan. It's a capital allocation document. Every feature represents a choice — why this, why now, and what are we giving up to build it? Four questions running in the background of every board conversation: 1️⃣ Is this roadmap connected to revenue and retention, or is it floating? Feature velocity means nothing if it isn't tied to business outcomes. 2️⃣ Can you tell me what you're not building, and why? The ability to defend trade-offs signals strategic judgment that a feature list never will. 3️⃣ What's underneath the roadmap? Tech debt, compliance gaps, scalability ceilings — boards want to know you see it and have a plan. Leaders who surface this proactively earn credibility. The ones who don't tend to have it surface at the worst possible moment. 4️⃣ What breaks if we push for more growth? PE firms are in the business of pushing. They want to know you've already stress-tested against that scenario. The language problem: Consider the difference between these two updates: "We shipped fourteen features last quarter and hit 94% of delivery commitments." "We prioritized two initiatives tied directly to enterprise retention over three others further from the revenue line. Churn in that segment is down 8%." Same team. Same quarter. Completely different signal. PE boards aren't anti-roadmap. They're anti-roadmap-as-religion. Stop trying to impress them with what you built and start being genuinely useful about why you built it, what you chose not to build, and what it'll take to keep building at scale. Those are different goals. They require different preparation. What's been your experience translating engineering strategy for board-level conversations? Curious what's landed well and what hasn't.

14

1 Comment

I constantly oscillate between sharing in-progress work and completed work. This means I'm long overdue to share some exciting updates on Wonderment Delivery Promise, our pre-purchase ETAs product. Wonderment now supports Rules for transit estimations and fulfillment estimations to allow you to account for per-product ETA customizations (like embroidery and engraving), warehouse delays, or other events that would impact coming estimates. Here's a quick demo of how you can use them for communicating pre-orders, backorders, and delays: https://lnkd.in/eb88vmcu

36

1 Comment

Scaling managers is harder than scaling engineers. Engineers scale through complexity. Managers scale through ambiguity. The shift happens when a manager stops focusing only on their team’s output and starts thinking about adjacent teams, shared dependencies, and organizational load. The managers who grow fastest in my org are the ones who proactively reduce cross-team friction. They don’t wait to be told there’s tension. They surface it and resolve it early. At that point, they’re not just running a team. They’re shaping the system.

104

10 Comments

If you have multiple teams reporting to you, all of whom are having team gatherings, you often see 2 directions: 1. Mandate an agenda 2. Let every team’s manager run the offsite however they choose to This is basically looking at either rigidity or chaos, but you don’t have to choose between only those options. The move most executive leaders miss: define overarching outcomes, not agendas. Not "everyone must do a vision exercise." More like: every team leaves with clarity on priorities, documented decisions, and at least a few concrete improvements to how they work together. Teams can then get there however works for them, walking away having achieved what actually matters. Consistency doesn't mean uniformity. It means every team gets the support they need to have an experience that actually moves their work forward. Here’s a link to the blog post to read more: https://lnkd.in/eaD5hK5Y #EngineeringLeadership #TeamEffectiveness

10

2 Comments

Recognize and Celebrate as All TPMs Should One of the most underrated habits for any Technical Program Manager is celebrating wins. Not just the big launches, but the small moments of progress that often slip by unnoticed. We spend so much time tracking blockers and dependencies that we forget to pause and say, “hey, that was awesome.” Recognition doesn’t have to be fancy. A quick shoutout in a team channel, a moment in a sync to appreciate collaboration, or even a post-mortem that highlights what went right can change the tone of the entire team. When you consistently celebrate people, you build psychological safety. Teams start to feel that their effort is seen, not just their output. It keeps motivation high during tough phases of a program and reminds everyone that progress is cumulative. TPMs who make celebration a ritual see stronger engagement and less burnout over time. It’s also contagious. When you model gratitude and recognition, others follow. Engineers start appreciating each other’s work, designers call out helpful feedback, and soon you have a culture where wins are noticed and shared. That kind of energy becomes a quiet but powerful multiplier for execution. #TechnicalProgramManagement #Leadership #TeamCulture #GratitudeAtWork #TPM #Productivity

4

Here's what I get from it: - big tech companies are literally burning billions on "A.I." without any clear ROI plan - organic "A.I." adoption is abysmally low by their own employees because it simply doesn't work as promised, which is hypocritically embarassing for them, so now they're desperately trying to mandate its usage to prop up their reputational bubble a bit longer - CEOs still don't understand how their own sausage gets made and still don't care about producing quality products that will delight the true customers (the end users) - we have passed "peak A.I." (as all the big tech companies are starting to panic at the realization they have vastly overextended themselves by vastly overinvesting in "A.I.") and are now beginning to coast down the other side of the roller coaster track

5

Most escalations are design failures. When everything gets escalated, something is wrong. Either: - Ownership is unclear - Decision rights are fuzzy - Or incentives are misaligned Healthy teams resolve 90% of issues without going up the chain. If your calendar is full of escalations, you don’t have a people problem. You have a system problem.

6

Just like Deepesh, for the past five years, I haven’t written a single line of code. Like many engineering leaders, my world shifted to strategy, org design, business alignment, and scaling teams. Coding became something I used to do. Then Claude Code was rolled out across our engineering org. We have an upcoming project to build an agent, and almost playfully, I thought: Why not? Let me ask Claude to write it. A few months ago, I had built something similar as a side project. It took real time and effort. This time? It was done in minutes. That was an eye-opener. Was the code production-ready? Maybe. Maybe not. But that wasn’t the point. The point was this: the constraints just changed. The friction between idea and implementation is collapsing. The cost of experimentation is approaching zero. I may not go back to “coding” in the traditional sense — and that’s okay. The world will still be full of strategy, architecture, and business conversations. But now, those conversations are backed by the ability to prototype, test, and explore at a speed that felt impossible not long ago. The real opportunity isn’t just writing code faster. It’s reimagining what we dare to build. We’re only getting started.

9

2 Comments

Most engineers think there's one way to be a Staff Engineer. There isn't. Will Larson identified four archetypes: Tech Lead — drives a single team's technical direction and execution Architect — owns technical vision across a broader domain Solver — drops into the hardest, most ambiguous problems wherever they are Right Hand — extends a senior leader's reach into areas they can't personally cover Most engineers default to chasing "Solver" because it scratches the itch that got them into programming in the first place. But your fastest path to Staff is the archetype that matches your strengths AND your org's needs. If your company is scaling fast, they need Tech Leads. If they're drowning in cross-cutting technical debt, they need a Solver. If a VP is stretched too thin, they need a Right Hand. Match the archetype to the opportunity. Don't force the one that sounds best on paper. More about navigating the path to Staff at https://www.evalx.dev

18

Inspired by "Arunachalam" movie, this week's leadership principle highlights two key lessons: detach from rewards and recognition (R&R) and prioritize long-term benefits over short-term gains. While R&R can be tempting, true leaders build lasting products, improve customer lives, and create wealth for all stakeholders. R&R is merely "good to have," not essential. Leaders, like the movie's protagonist, must sometimes sacrifice immediate gratification for long-term commitments, focusing on valuable products over MVPs for sustained growth. Visionary leaders look years ahead, ensuring short-term sacrifices contribute to the company's enduring success and impact. #leadership #detachment #growth More details https://lnkd.in/gEpEeXbd

3