Upgrade To Paid - 20% OFF Annual Plans

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

🧭 Road to Staff+ TPM is my premium series on becoming the TPM your organization turns to when the playbook no longer works. We’ll explore the judgment, systems thinking, influence, and leadership required to thrive in increasingly ambiguous environments - one practical lesson at a time.

Do Androids Dream Of Estimating How Long It Will Take To Count Electric Sheeps?1

Estimating software has always been a bit of a strange exercise.

It’s part science, part experience, and, if we’re being honest, sprinkled with a healthy dose of irrational optimism.

As TPMs, one of our most fundamental responsibilities is turning a product idea into a realistic execution plan. We sit down with our engineering partners, break a large problem into smaller pieces, estimate how long those pieces might take, and then stitch them together into a roadmap, a Gantt chart, or whatever planning tool your team happens to use.

The funny thing is, despite decades of software development, nobody has discovered a formula that produces perfectly accurate estimates. At best, we’re making informed bets with the information we have today.

To make those bets a little more consistent, we’ve invented ways to measure work. Most TPMs have used some combination of:

• T-shirt sizes (S, M, L, XL...)

• Engineering days or weeks

• Story points

None of these are measuring the work itself. They’re measuring our best guess at how long a human will take to do the work. And that’s the assumption I can’t stop thinking about.

What happens when the person doing the work isn’t entirely human anymore?

As AI starts writing code, generating tests, reviewing pull requests, and even proposing designs, the foundations of how we estimate begin to shift. I don’t think we’ve fully appreciated what that means yet.

It’s a question I’ve been wrestling with quite a bit, and I suspect it’s one every TPM, especially those operating at the Staff+ level, where you’re coordinating large, multi-team initiatives, will eventually have to answer.

So, to help bring one perspective to this, I asked Dylan Thomas to help share his thoughts on the subject. Dylan has had a storied career; he has led teams at Github, Google, and Esri. He was the head of the TPM team at GitHub before taking time off on a sabbatical. He has spent more time thinking on this subject then I have and everything he is about to share is worth its wait in gold.

Over to you, Dylan…

End of Estimation?

Guest post by Dylan Thomas. Dylan is an engineering leader who has run teams at GitHub, Google, and Esri. He writes at bitsby.me. He has been a fan and user of &mdash for 20 years. This piece condenses arguments from two longer essays: Estimation at Multiple Levels and Capacity at Multiple Levels.

I spent years as a consultant on software-based system integration projects, where estimating work up front to write a proposal was both a dark art and the standard operating procedure. The truth is that my experience delivering similar work was my superpower: I had done this work before, and where I hadn’t, I padded a lot. Then threw on 20% because (a) the business likes a profit, and (b) we probably needed a cushion. In situations where you have to provide an estimate, like a consulting proposal, that’s still a thing. But in most cases (and, I’d argue, even in consulting proposals) there are better ways.

AI made delivery data unstable and discovery cheap

It gets better. As of 2023-ish for most technologists, you can toss in a little AI uncertainty. Now we really have to think about it differently. The shift is in the means of production.

For the entire history of software estimation, the unit being estimated was human labor: an engineer-hour, at a roughly stable cost. Increasingly, with AI in the mix, the unit is the LLM token.

The theory and the calculation are unchanged (how much production capacity does this scope require?) but the values in the equation are entirely different: labor cost becomes token usage and how efficiently your agents turn those tokens into shipped work. Those token usage values are changing monthly or get faster and cheaper.

The delivery data shows the churn. The 2024 DORA report found roughly 75% of respondents reporting individual productivity gains from AI, while at the system level a 25% increase in AI adoption correlated with a 7.2% drop in delivery stability and a 1.5% dip in throughput. A year later, the 2025 DORA report showed the throughput correlation turning positive (teams using AI shipped faster) while the stability penalty persisted. The picture changed between two annual surveys, and we are more than halfway through 2026 with the toolchain still moving.

No organization can currently say how AI has changed its ability to estimate: an engineer’s intuition was calibrated against a toolchain that no longer exists, and a claimed speedup (”that’s a two-day job now”) is a belief, not a measurement. The defensible move is to measure what the team actually delivers, not to keep guessing what it might.

Discovery is also cheap now. An agent can produce most of a working implementation for a bounded, well-specified problem in hours, so a spike that used to cost a week of a senior engineer’s time often runs in a day or two. When building a working slice of the risky part costs less than the meeting to size it, test the hypothesis instead of refining the guess.

Estimates provide false confidence

Estimation has been a dirty word in software for decades. Sean Goedecke calls it a “polite fiction”: the industry agrees to pretend that a skilled team, given time and effort, can learn how long work will take, while every experienced engineer knows it mostly can’t.

What an estimate actually provides is false confidence: a precise-looking number wrapped around a guess. Most of what looks like bad estimation in large organizations is the fallout of working around that gap.

The goal is not a better estimation methodology. It is to invest the right amount of effort in estimation—which, for most work, is less than you currently spend—and to replace guesswork with observed behavior everywhere else.

When to estimate, and what to do instead

Here’s the short list of situations that usually involve estimates, along with a non-estimation strategy:

• Ask what decision the estimate informs before producing one. Estimate only for the short list: external commitment decisions, genuine infeasibility, high cost of being wrong, new domains. Everything else runs on scope, throughput, and a dependency map.

• When delivery history exists, forecast from it. Monte Carlo over a recent window, operated as continuous target-driven kanban against the team’s own service-level targets. This is the one planning instrument that measures AI’s actual effect on your delivery.

• When history doesn’t exist, set an appetite. Fix the timebox, let scope flex, and spend the first days testing the riskiest hypothesis with code, cheaper now than the meeting to size it.

• Spend the recovered effort on dependencies. Manage the critical chain with a single shared buffer, track buffer burn instead of estimate variance, and name the constraint (often a single specialist) on the map.

Let’s dig in using some statements that I hold to be (often) true, along with some guidance.

Estimate only when it’s critical

Before running a sizing session, ask: what decision does this estimate inform, and does it need this level of precision? Most sprint planning, backlog grooming, and quarterly roadmapping fails that test. Those activities need clear scope, a team with known throughput, a dependency map that surfaces blockers early, and an honest distinction between what is a commitment and what is a guess.

Estimates genuinely matter in four situations:

• When someone outside engineering needs to make a staffing or commitment decision. A sales leader telling a customer when a feature will ship, or a VP deciding whether to staff a project, needs order-of-magnitude signal. The decision changes between “two weeks” and “six months.” It doesn’t change between “eleven days” and “fourteen days”—so getting the exact number right isn’t where the effort should go.

• When the work might be genuinely infeasible. Engineering rarely gets a formal veto over a project the business wants. What it gets is the estimate. And sometimes the only honest answer to “how long will this take?” is a number so large it functions as a no. An eighteen-month estimate on a feature the business wanted in a quarter kills or reshapes the project as effectively as any veto, without anyone having to say the word. The mechanism only works if it’s rare: a team that inflates every estimate gets every estimate discounted, including the one that mattered. The ability to say “this is infeasible” is, as Goedecke puts it, earned by “making pragmatic estimates the rest of the time.” Note this is different from “we don’t know”: that case gets a timeboxed spike, not a big number.

• When the cost of being wrong is high. Contracted dates, regulatory deadlines, dependencies with another company. These warrant honest scrutiny of the riskiest unknowns before committing, not more task breakdowns. Use the cheap spike here: answer “can the auth system support this?” with two days of code rather than a sizing debate.

• When a team is new to a domain. More investigation before committing, but timeboxed: two days answering a specific question, not open-ended weeks of “research.”

⚠️ Everything else is a candidate for skipping the estimate, doesn’t matter if you use AI Agents or not; the next three sections are what you do instead.

When you have delivery history: forecast from actual behavior

If your teams have been delivering consistently for several quarters, you have better forecasting data than any estimate: your actual history. The method comes from Daniel Vacanti’s flow-metrics work: rather than estimating the size of future work, sample from the distribution of how long past work actually took, run that distribution through thousands of Monte Carlo simulations, and express the result as probabilities: “85% probability of completing this scope within twelve weeks.” flowmetrics, a tool I built, computes these forecasts directly from GitHub PR or Jira data:

Read more

Upgrade To Paid - 20% OFF Annual Plans

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

🧭 Road to Staff+ TPM is my premium series on becoming the TPM your organization turns to when the playbook no longer works. We’ll explore the judgment, systems thinking, influence, and leadership required to thrive in increasingly ambiguous environments - one practical lesson at a time.

One Project. Three Different TPMs.

Every phase of a project asks you to become a different version of yourself.

The TPM I need during planning is completely different from the TPM I need three months later, and different again from the TPM I need closer to launch. Yet most of us try to operate exactly the same way from kickoff to launch.

We cling to our process playbooks and stay rigid. When the pressure becomes too much, cracks begin to appear and things go pear-shaped.

• We run the same meetings.

• Ask the same questions.

• Escalate the same way.

• Manage risk the same way.

• And then wonder why a project suddenly feels harder than it should.

The project did not suddenly become something else. The environment changed, the expectations changed, the challenges changed. And when the environment changes the TPM must change with it.

This has become one of the biggest distinctions I notice between experienced TPMs and Staff+ TPMs. The latter aren’t just executing a project. They’re constantly changing how they lead it. As the project lifecycle progresses, they find opportunities to stay nimble, stay focused, stay on top of things by constantly switching their mindset.

TPM isn’t just a skill.

It’s an operating system. I used to think becoming a better TPM meant collecting more tools.

• Better templates.

• Better dashboards.

• Better planning docs.

You wouldn’t be at fault thinking this way because the beginning portion of your TPM career as you acquire new skills and capabilities does come in the shape of these tools. But, climbing beyond mid-level TPM means, something different. Eventually I realized something: Two TPMs can use the exact same framework and produce completely different outcomes.

Why? Because frameworks don’t make things happen alone. Mindsets do.

Your mindset determines

• what you pay attention to

• what you ignore

• how quickly you move

• how much uncertainty you tolerate

• what signals you amplify for the team

The methodology is often the least interesting part. The operating system underneath matters far more. As I often tell new TPMs that the Art of Doing Technical Program Management is:

• Part knowledge.

• Part application.

• Part experience.

• But almost entirely mindset.

The challenge is that most of us never consciously change our mindset. We simply carry yesterday’s operating system into today’s environment.

Staff+ TPMs don’t.

They recognize that every phase of a project demands something different from them. Here’s the simple framework I use.

I’ll walk through each phase, explain why the environment changes, and more importantly, how your mindset should change with it.

Phase 1 - Planning

This phase has an environment that is uncertain, ambiguous, filled with incomplete information.

Read more

Upgrade To Paid - 20% OFF Annual Plans

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

A few weeks ago I started building an AI agent to generate a morning briefing. The idea sounded straightforward. Every morning it would read the documents I cared about, summarize my Slack channels, look at my meetings, and tell me what deserved my attention.

As I started wiring everything together, I created a spreadsheet listing every input the agent would need. Every recurring meeting, Slack channel, document, dashboard, JIRA project. This is sage advice everyone has about building agents. Halfway through building it, I stopped.

The spreadsheet wasn’t revealing what my AI agent needed. It was revealing how complicated my work had quietly become.

• There were too many meetings.

• Too many Slack channels.

• Too many places where information could live.

It suddenly hit me. I didn’t have an AI problem. I had an organizational design problem. Classic problems, same old same old. Instead of making the agent more sophisticated, I started asking different questions.

• Which meetings could disappear?

• Which Slack channels should be consolidated?

• Where should the single source of truth actually live?

• What were the expectations for where different kinds of information belonged?

The AI project ended up improving the system long before the AI agent was finished. That experience changed the way I think about AI. Not because it taught me a better prompt. Because it reminded me that good judgment beats good prompts.

AI is getting remarkably good at execution. It can summarize meetings, draft status updates, build project plans, write documentation, and analyze risks faster than ever before. But none of those answer the question that matters most: Should we be doing this in the first place? That’s a judgment call. And I think that’s where TPMs become even more valuable - making good judgement.

AI doesn’t eliminate the need for judgment. It changes where judgment gets applied. The pattern I’ve started noticing is this.

Someone asks, “Can AI do this?” and the immediate response is to build an agent, write a prompt, or automate the workflow.

Sometimes that’s exactly the right answer. But I think the better question is: Should AI do this?

More often than not, that’s a judgment call, not a technical one. Looking back at my morning briefing project, I realized something. The AI agent wasn’t the solution. It was the flashlight. It exposed complexity I had slowly become accustomed to.

Instead of helping me automate a messy system, it helped me see that the system itself needed redesigning. Sometimes AI isn’t the solution. Sometimes it’s the flashlight. It exposes unnecessary complexity that good judgment can eliminate.

One thing that worries me about an AI-first world - learning through mistakes. It has become incredibly easy to outsource not just the work… but the thinking behind the work. Judgment isn’t downloaded after reading a book. It’s earned through repetition. Every escalation you handled well. Every roadmap discussion where you pushed back. Every meeting you scheduled at the wrong time. Every mistake that taught you something. Those experiences slowly calibrate your internal compass. That’s how judgment develops.

The danger isn’t that AI replaces our work. It’s that AI replaces our practice. If AI makes every difficult judgment call for you, you might become more productive today… while becoming less capable tomorrow.

That brings me to something I’ve been thinking about recently. We talk a lot about technical debt. I think AI introduces another kind of debt: Judgment debt.

Judgment debt accumulates when AI repeatedly makes decisions you should have learned to make yourself. The tricky part is that it feels like progress. Your emails are polished. Your project plans are better. Your stakeholder updates are clearer. Everything looks more efficient.

But judgment debt doesn’t show up while AI is available. It shows up when a senior leader unexpectedly asks, “What do you think we should do?”. There’s no time to engineer the perfect prompt. That’s when your accumulated judgment becomes visible.

The good news is that judgment is a skill. Like every other skill, it can be developed deliberately. Honing it will take time but there are things you can start doing today that will help you on your journey to get better at good judgement.

🔐 For paid subscribers, here’s the 2-step framework I use to sharpen judgment as a TPM and something you can start today.

1. Ask Better Questions Before You Ask AI

Whenever someone asks, “Can AI do this?” Pause and ask three questions first:

Read more

Subscribe now

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

It’s become the default advice for anyone impacted by layoffs, workforce reductions, or uncertainty about the future. I’ve seen it repeated so often that it feels almost unquestioned. In some ways it reminds me of previous waves.

In 2008 it was “go learn how to build apps.” A few years later it became “go learn cloud.” Today, it’s “go learn AI”.

On the surface the advice seems obvious. AI is changing jobs. AI is replacing parts of jobs. AI is creating entirely new ways of working. Heck everyone from CEO to Customer Support is under pressure to “use AI”. So naturally, people should learn AI. But every time I hear this advice, I find myself wondering what it actually means.

What exactly is a laid-off TPM supposed to do on Monday morning?

Do they just:

• Open ChatGPT?

• Build an agent?

• Create a calorie-tracking application?

• Watch a few prompt engineering videos.

• Start collecting hundreds of prompts in a GitHub repository?

The advice sounds actionable until you ask for specifics. And that’s where I think it starts to break down for me.

Most people giving this advice also can’t clearly explain what role someone should be preparing for. Remember, jobs are going to change and roles will disappear. We are told that many of today’s roles may not even exist in their current form a few years from now. So, we’re asking people to acquire skills for jobs we can’t clearly define. That feels like incomplete advice.

The common rebuttal is that learning AI isn’t about the next role. It’s about transforming your current role. I think that’s directionally correct. The problem is that most hiring processes aren’t evaluating for that. Plus how does someone laid off even do that; they are unfortunately on the outside trying together back in to make that change.

Recruiters rarely ask: “How would you redesign this role if AI could do half the work?”

Most interviews still focus on how candidates performed the role as it exists today. This creates a strange disconnect. We’re telling candidates to reinvent the future while evaluating them against the past.

Then there is the advice to go experiment.

• Build apps.

• Create agents.

• Ship something.

I don’t think that’s bad advice. I just don’t think it’s enough.

Historically, valuable skills were difficult to acquire. That difficulty created separation. Not everyone could become an expert software engineer. Not everyone could become a cloud architect. Not everyone could build distributed systems. AI is different.

The barrier to experimentation has collapsed. Millions of people can build small applications, agents, automations, and prototypes. That’s incredible, don’t get me wrong. But it also means simply building something is no longer a strong signal. Literally everyone is a “builder”.

A recruiter looking at a hundred resumes filled with AI side projects and 100 prompt deep git repos face a different problem: How do you identify who actually stands out?

Maybe the answer isn’t who can use AI. Maybe it’s who understands how AI changes systems. That feels like a much rarer skill. For TPMs, I don’t think the advice should be “go learn AI.” I think it should be “go learn how AI works”.

Go beyond prompting. Learn how models are trained. Understand context windows. Learn where hallucinations happen and why. Understand the tradeoffs between different model providers. Every frontier lab is publishing free resources.

The deeper understanding matters because it informs judgment. And judgment may become the most valuable skill in the room. Not everything needs an agent. Not every workflow should be automated. Not every problem benefits from AI.

The challenge is no longer building solutions. The challenge is deciding which solutions are worth building. That’s systems thinking. That’s process design. That’s organizational design. Ironically, those are many of the skills TPMs have spent years developing.

I also wonder if recruiters need to evolve how they evaluate candidates. “How do you use AI?” is becoming a weak interview question. Everyone has an answer. Most answers sound something like: “I use ChatGPT to summarize Slack threads.”

That’s useful. It’s also not particularly differentiating. A more interesting question might be: “Tell me about a workflow, process, or aspect of your day to day that no longer exists because of something you built with AI.”

Now we’re evaluating leverage. Now we’re evaluating judgment. Now we’re evaluating whether someone fundamentally changed how work gets done.

There’s a big difference between: “I use AI to summarize meetings.”

And:

“I eliminated a recurring meeting because an AI-driven workflow made the meeting unnecessary.”

One is task optimization. The other is system redesign.

I suspect the second category is where the future value lives. When I think about TPMs navigating the next few years, I don’t think the winners will be the people with the most prompts. I think they’ll be the people who understand where work is changing, where coordination is becoming cheaper, where information is becoming abundant, and where human judgment becomes more important.

The future may belong less to AI operators and more to organizational system designers. Maybe that’s the better advice.

• Don’t just learn AI.

• Learn how AI can change the systems around you the people and processes.

• Double down on Core fundamentals of Great Technical Program Management.

• Maybe your resume doesn’t need a list of AI courses you have taken but also examples of how you optimized systems.

• Maybe use judgement to have a handful prompts in that GitHub repo instead of 30.

I don’t know… this feels to me to be slightly more useful advice than “just go learn AI” or “learn how to build agents”; a little more purpose and directional than, just be a “builder”.

Until next time.

-Aadil

Upgrade To Paid - 20% OFF Annual Plans

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

What and why to design a TPM career

Most careers in technology are not designed.

They simply unfold.

We take the job that seems interesting at the time, work hard, gain experience, and trust that the next opportunity will appear when we need it. For a long time, that approach worked reasonably well for everyone especially Technical Program Managers. Companies were growing, programs were becoming more complex, and TPM roles naturally expanded alongside them.

But over the past year, many conversations I’ve had with fellow TPMs have started to sound different.

Some are experienced TPMs trying to figure out their next move in a market that suddenly feels smaller. Others are TPMs who were recently laid off and struggling to land their next role. And some are early in their careers asking a question that didn’t feel urgent just a few years ago: Is TPM actually a long-term career?

Layer on top of that the rise of AI tools, shifting expectations inside engineering organizations, and companies reconsidering the structure of program management roles, and it’s understandable why many TPMs are feeling uncertain.

These are uncomfortable questions. But they are also useful ones.

Because when the environment around you becomes uncertain, it forces you to think more intentionally about something many of us previously left to chance: How your career is actually designed.

This post is my attempt to share how I think about designing a TPM career; not as a rigid framework or step-by-step playbook, but as a set of questions that helped me better understand my own path.

• What Does a Fulfilling TPM Career Look Like for You?

• Do You Want to Be an Individual Contributor or a People Manager?

• Do You Actually Enjoy Ambiguity or Do You Just Tolerate It?

• Do You Want to Be a Generalist or a Specialist?

• What Size Problems Do You Want to Work On?

• What Career Taxes Are You Willing to Pay?

• Why Would Someone Hire You in an AI-Native World?

• If the TPM Title Disappeared Tomorrow, What Roles Could You Step Into?

• What Kind of Recognition Actually Matters to You?

• What Kind of Career Regret Are You Trying to Avoid?

• What Do You Want People to Say When a Tough Program Appears?

• Bonus: Three Career Traps Many TPMs Fall Into

Think of what follows less as advice and more as a guided reflection. Now, let me walk you through what each of these questions hold in terms of key to your career.

How Should You Use These Questions?

The questions in this post are not meant to be skimmed quickly or answered in your head while reading. Their real value comes from slowing down and reflecting on them honestly.

• If possible, write your answers down, even if they feel incomplete or messy at first.

• Treat these questions less like a checklist and more like prompts for a conversation with yourself about the kind of career you want to build.

• The goal is not to arrive at perfect answers immediately. The goal is clarity. Clarity about what energizes you, what tradeoffs you are willing to make, and what kind of reputation you want to build over time.

• Once you have that clarity, these answers become something much more useful: a personal decision-making framework.

• Whenever a new role, opportunity, or career move appears, you can use that framework to ask whether it actually aligns with the career you want to design.

Careers rarely unfold in straight lines. But having a framework for how you think about your career makes navigating those twists far more intentional.

Lets get started…

What Does a Fulfilling TPM Career Look Like for You?

Before thinking about promotions, companies, or titles, it’s worth asking a deeper question:

What does a fulfilling TPM career actually look like for you?

For some TPMs, fulfillment comes from operating in deeply ambiguous environments, working on cutting-edge technology, navigating messy cross-functional problems, and bringing clarity where none exists. For others, fulfillment comes from building and nurturing teams of TPMs while shaping how organizations operate.

For many people, the answer is unclear, especially early in their careers.

Our definition of fulfillment evolves over time. It is shaped by the companies we work at, the teams we collaborate with, and the tradeoffs we make as our lives outside of work change.

For me, a fulfilling TPM career looks something like this: working on complex cross-functional programs at the frontier of technology, surrounded by smart collaborators, where my impact comes from bringing clarity to chaos. At the same time, I want that work to coexist with the rest of my life, particularly the time I get to spend with my family.

That is my answer. Yours may look very different.

➡️ But even attempting to define it will anchor many of the decisions you make later.

Do You Want to Be an Individual Contributor or a People Manager?

Early in my career, I assumed that the only path forward was people management.

Promotions seemed to reinforce that idea. The organizational ladder appeared to move naturally from individual contributor to manager to senior leader.

But over time, I realized something important: people management is not simply the next level of the same job. It is a fundamentally different job.

Managing people means your primary source of satisfaction comes from growing individuals, mentoring TPMs, shaping careers, and building strong teams. Running programs becomes secondary.

For some people, that shift is incredibly fulfilling.

For me, the moments that feel most meaningful are when we ship something incredibly hard, when a complex initiative that once seemed impossible finally lands and changes the trajectory of a company.

Because of that, I’ve consciously chosen to remain on the individual contributor path while seeking roles with increasing scope and influence.

➡️ For many TPMs, this is the first real fork in the road.

Do You Actually Enjoy Ambiguity or Do You Just Tolerate It?

As you get higher in your career, the programs you work on become increasingly unclear.

• Product requirements are incomplete.

• Technical solutions are still evolving.

• Stakeholders disagree about priorities.

• Decisions are rarely straightforward.

Many TPMs say they thrive in chaos. But it’s worth asking a more honest question: do you truly enjoy that chaos, or have you simply learned how to tolerate it?

For some TPMs, ambiguity is energizing. It creates space to experiment, improvise, and find new ways to achieve impact.

For others, constant uncertainty becomes exhausting. The firefighting makes it difficult to see a clear sense of progress or growth.

Personally, the surge of energy I get from working on zero-to-one programs with unclear boundaries is intoxicating. Those are the moments where I feel I can contribute the most.

➡️ Looking back, it’s not surprising that many of the roles I’ve chosen have lived in those environments. You have to decide your happy place for yourself.

Hey, Its Aadil with a quick announcement.

I have launched my first new on-demand TPM Course right here on this newsletter — “Foundations Of Technical Program Management”.

📣 Subscribe to my new “On Demand Course” annual subscription (not the regular annual subscription which is different) and unlock my highly rated Maven course content + FREE access to all future courses.

🔥 50+ TPMs have taken the course live. Some used it to level up their TPM game while others used the content to MOVE INTO a TPM role.

In the modern AI world, the foundations of TPM role will be the key difference between churning AI slop or becoming an impactful AI native TPM.

💪🏽 Unlock your full TPM potential today!

The Art of Doing Technical Program Management

📽️TPM Course: Foundations Of Technical Program Management

⚠️ This course is only available to On Demand Course subscription members. Upgrade your subscription today to take full advantage of the course content…

Listen now

a year ago · 1 like · Aadil Maan

Now, let’s keep going with this post. Thanks for reading.

Do You Want to Be a Generalist or a Specialist?

Many TPMs operate as generalists, moving across teams, products, and domains to create clarity across a vast landscape of dependencies.

Others prefer deep specialization, becoming experts in a particular technical domain such as infrastructure, machine learning systems, hardware, or security.

Read more

Upgrade To Paid - 20% OFF Annual Plans

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

Few changes for 2026:

• I am going to focus on more in-depth and long form writing which means less frequent posts than weekly.

• I will be restarting my Maven course in Q2 of 2026. You can sign up for the waitlist here.

Lastly:

Our voice as TPMs is missing from every State of AI Survey currently conducted by name brands like Lenny Rachitsky, The Pragmatic Engineer, etc.

A group of us TPMs are going to change that.

🚨 The "State of AI in Technical Program Management" survey is the first comprehensive look at AI adoption across:
→ Technical Program Managers
→ Program Managers
→ Project Managers

5 minutes. Anonymous. By program leaders, for program leaders. If you use these tools in any way, your input will be important and crucial to help us build this full picture.

If you're in a Technical Program Manager, Program Manager, Project Manager role, your input matters. IT REALLY DOES.

🔗 Link to Survey

All participants get early access to the full report.

Now, on to the main post.

What is an almanac and why should I care?

These notes are an almanac for Technical Program Managers.

An almanac is an annual publication containing vital, tabulated data including calendars, weather forecasts, astronomical information (moon phases, sunrises/sunsets), tide tables, and agricultural planting dates

So, an almanac isn’t something you read straight through and move on from. It’s something you come and reference when you need to predict something long-term, or when the season changes, or when conditions shift, or when something familiar starts to behave differently than expected.

That’s how these notes are meant to work.

Each note captures a recurring pattern in TPM work:

• where execution tends to break

• how ambiguity shows up

• how ownership erodes

• where judgment actually matters

• how to think about your career journey.

They’re short by design, so they can be consulted in the middle of real work. No need to memorize or commit to memory anything.

This isn’t a framework, a checklist, or a set of best practices. It’s a collection of observations meant to help you recognize situations faster, name them more clearly, and respond with intention.

Like any good almanac, its value compounds over time, not by giving answers, but by sharpening how you see what’s already happening all around you.

As I have said before, we TPM’s are world builders. To build better worlds, we need to see the patterns all around us and react appropriately.

Where do these notes come from?

These notes are distilled from more than 15 years of real-world industry experience working directly as a Technical Program Manager and people leader across multiple companies, teams, and problem spaces.

They are also grounded in years of writing and reflection in this newsletter, capturing patterns that surfaced repeatedly across programs, organizations, and career stages. The ideas here weren’t created in isolation or borrowed from theory alone. They emerged from shipping products, missing timelines, repairing trust, navigating ambiguity, and learning what actually matters in execution, sometimes the really hard and painful way.

Nothing here is hypothetical.

Each note exists because the situation it describes happened more than once.

How to use these notes

These notes aren’t meant to be read once and set aside.

The simplest way to use them is as a weekly practice:

• Read one note.

• Sit with the reflection.

• Apply it to the work you’re already doing.

You can also return to this collection whenever something feels off:

• when progress slows without a clear reason

• when alignment feels fragile

• when ownership gets fuzzy

• when you’re tempted to add more process instead of more clarity

You don’t need to agree with every note for it to be useful. If a note makes you pause, reflect, or slightly change how you act in a situation, it’s doing its job. If a note doesn’t do anything for you, that is okay because it is still a data point.

Over time, these notes are meant to sharpen your judgment, not by telling you what to do, but by helping you see what’s happening sooner and more clearly. The biggest impact from these notes I hope is the sharpening of your retrospective and observation skills, something super critical especially when you think about jumping from Mid to Senior to Staff+ beyond TPM roles.

That’s the real leverage in the TPM role - observation, retrospection, action.

So, here we go…

CLARITY: Where most execution problems quietly begin

1. Clarity Precedes Execution

Team failing isn’t always just because they moved slowly. They fail because they move in different directions while believing they’re aligned. Lack of clarity shows up as rework, contradictory decisions, and repeated alignment meetings that never seem to resolve anything. Strong TPMs force clarity early by explicitly naming goals, constraints, and what “done” actually means before execution momentum hides or masks the unaddressed confusion. Speed without clarity just compounds mistakes faster.

Reflection: Find one area where rework is happening often and trace it back to missing clarity at the start.

2. Clarity Beats Activity

High activity often masks low progress. When teams are busy but outcomes aren’t moving, the problem is rarely effort, it’s intent. Adding more tasks or meetings may feel productive but usually increases noise. TPM leverage comes from removing confusion so existing effort compounds instead of scatters. The fastest teams are often the ones doing less, with sharper focus.

Reflection: Identify one activity you could pause this week without changing the outcome.

3. Expectations Shape Outcomes

Misaligned expectations cause more damage than missed dates. When different stakeholders carry different definitions of success, every update becomes disappointing to someone. This shows up as surprise reactions late in delivery, even when progress was visible all along. TPMs prevent this by making expectations explicit early and revisiting them as context shifts. Expectations decay unless actively maintained.

Reflection: Reset/Reconfirm expectations on one deliverable before the next milestone. Do you see the impact.

4. Documentation Is a Thinking Tool

Documents are more than just records of decisions; they are tools for making them. Weak docs restate usually state what’s happened; strong docs force choices and surface assumptions to help see where things need to go before it’s expensive to be make the pivot. If a document doesn’t change how someone thinks or decides, it’s probably missed the mark. TPMs use writing to sharpen clarity, not to memorialize confusion.

Reflection: Re-read one document you used to push for a decision or trade off; did the document hit that goal, why or why not.

5. Early Signals Matter

Large failures are usually preceded by small inconsistencies. Repeated questions, vague answers, subtle scope drift, or quiet discomfort in meetings are early warning signs. Ignoring these trades short-term comfort for long-term risk. Strong TPMs act on weak signals while intervention is still cheap. Waiting for certainty usually means waiting too long.

Reflection: Act on one weak signal you’ve noticed but haven’t named yet.

6. Clarity Is Preventative Work

Preventing confusion rarely looks impressive. It doesn’t produce artifacts, demos, or metrics. But clear framing early avoids downstream churn, escalation, and burnout. This work often happens before anyone asks for help, which makes it easy to undervalue. Experienced TPMs do it anyway because they’ve seen the cost of skipping it.

Reflection: Clarify one ambiguous area proactively instead of waiting for it to break.

7. Communication Is Design

How information flows shapes behavior just as much as incentives do. Poor communication creates friction even when intent is good, decisions get misinterpreted, priorities blur, and teams optimize for the wrong signals. TPMs design communication deliberately: what’s shared, when, with whom, and in what form. Communication left to chance becomes a source of risk.

Reflection: Review how a recent piece of information or decision was communicated and what behavior it produced.

8. Decisions Age

Decisions don’t expire on their own, but their assumptions do. What was correct a quarter ago may silently constrain work today. Old decisions often show up as “mysterious blockers” or unspoken rules no one remembers choosing. TPMs revisit decisions before they become invisible constraints that slow everything down.

Reflection: Revisit one decision older than a quarter and check if its assumptions still hold.

9. Constraints Create Focus

Clear constraints help teams decide faster. Ambiguous constraints invite debate, re-litigation, and scope creep. Many teams argue endlessly because they don’t agree on what’s actually constrained; is it time, cost, quality, or something else. TPMs create focus by naming the real constraint and holding it steady long enough for progress to happen.

Reflection: Name the real constraint your program is operating under right now.

10. Clarity Is the Goal

Everything else, speed, process, tooling, exists to support clarity. Without it, velocity amplifies mistakes and effort gets wasted. TPMs who optimize for clarity first create durable progress even in messy environments. When in doubt, the right move is usually to make things clearer, not faster.

Reflection: Ask yourself what would make the current situation clearer for everyone involved.

OWNERSHIP: Where accountability either sharpens execution or quietly erodes it

11. Ownership Must Be Explicit

When ownership is unclear, assumptions fill the gap. Decisions slow down, work stalls, and accountability only becomes visible when something goes wrong. This often shows up as passive escalation or “I thought someone else had that.” Strong TPMs make ownership explicit early, like who decides, who executes, and who needs to be consulted, even when it feels awkward to spell out. Ambiguity here always costs more later.

Reflection: Rewrite ownership for one area where decisions feel slower than they should. Focus on a single owner who is best suited to that situation. Avoid the RACI trap.

12. Ownership Without Authority Is Fragile

Holding someone accountable without giving them influence creates hidden risk. This imbalance often stays invisible until timelines slip or tensions spike late in delivery. TPMs frequently absorb this gap quietly, which delays fixing the system. Healthy programs align responsibility with decision rights, even if it requires uncomfortable conversations.

Reflection: Map one outcome you own and list which decisions shaping it sit outside your control.

13. Alignment Without Accountability Is Theater

Teams can sound aligned while ownership remains fuzzy. Shared language is often mistaken for shared responsibility. This shows up when everyone agrees in meetings but no one follows through decisively. Alignment only matters when someone is accountable for outcomes, not just participation. Anything else is performance.

Reflection: Pick one “aligned” initiative and explicitly name who owns the outcome.

14. Escalation Is a Signal, Not a Surprise

Most escalations aren’t sudden failures, they’re delayed signals. They usually point to unclear ownership, unresolved tradeoffs, gap in accountability, or missing decision rights. When escalation becomes routine, the system is teaching people to defer responsibility upward. TPMs treat escalations as feedback about design flaws, not personal breakdowns.

Reflection: Look at your last escalation and trace what ambiguity allowed it to reach that point.

15. Shared Ownership Needs Structure

“Shared ownership” often means no one truly owns the outcome. Without structure, collaboration turns into diffusion of responsibility. To develop effective shared ownership clarity on who integrates decisions, who breaks ties, and how disagreements get resolved is needed. TPMs make this shared responsibility real by designing the systems that make the responsibilities of “shared ownership” explicit.

Reflection: Clarify how decisions are made in one area labeled as “shared ownership.” Don’t lean on RACI trap. Keep it simple.

16. Follow-Through Creates Real Ownership

Decisions without follow-through decay quickly. Ownership isn’t just making a call rather it’s ensuring that the call actually lands. This shows up when teams agree in principle but execution drifts quietly afterward. Strong TPMs track follow-through, not to micromanage, but to protect intent.

Reflection: Check one recent decision that hasn’t been reinforced since it was made. Identify the source of this lack of follow-through.

17. Authority Drifts Over Time

Decision rights shift as teams grow, priorities change, and people move roles. What was once clear slowly becomes outdated. This drift shows up as confusion about who can say yes or no and who carry’s the ball when it drops. TPMs periodically refresh ownership assumptions instead of letting them fossilize or when things break down.

Reflection: Update ownership for one area that hasn’t been revisited in months.

18. Ownership Reduces Drama

Most delivery drama thrives in the absence of clear ownership. When no one is clearly accountable, issues turn emotional and political. Clear ownership doesn’t eliminate conflict, but it channels it productively. TPMs use ownership as a preventative tool, not a reaction to failure.

Reflection: Identify one recurring conflict that might disappear with clearer ownership.

19. Accountability Should Be Visible Early

Accountability that only appears at the end of a program is too late. It should be visible throughout execution, in decisions, updates, and tradeoffs. When accountability is clear early, teams self-correct faster. TPMs surface accountability before pressure forces it out.

Reflection: Ask where accountability is currently implicit instead of explicit.

20. TPMs Often Hold the Gaps

TPMs frequently sit in the gaps between formal owners. This is useful short-term but dangerous long-term if left unnamed. Absorbing gaps quietly prevents the system from improving. Strong TPMs make gaps visible so ownership can be redesigned instead of personally carried.

Reflection: Notice one gap you’re holding that should be redesigned to a proper owner instead of endured.

Hey, Its Aadil with a quick announcement.

I have launched my first new on-demand TPM Course right here on this newsletter — “Foundations Of Technical Program Management”.

📣 Subscribe to my new “On Demand Course” annual subscription (not the regular annual subscription which is different) and unlock my highly rated Maven course content + FREE access to all future courses.

🔥 50+ TPMs have taken the course live. Some used it to level up their TPM game while others used the content to MOVE INTO a TPM role.

In the modern AI world, the foundations of TPM role will be the key difference between churning AI slop or becoming an impactful AI native TPM.

💪🏽 Unlock your full TPM potential today!

The Art of Doing Technical Program Management

📽️TPM Course: Foundations Of Technical Program Management

⚠️ This course is only available to On Demand Course subscription members. Upgrade your subscription today to take full advantage of the course content…

Listen now

a year ago · 1 like · Aadil Maan

Now, let’s keep going with this post. Thanks for reading.

EXECUTION: Where good intent meets real constraints

21. Execution Breaks at the Edges

Programs rarely fail in the middle of a team’s core work. They fail at handoffs, dependencies, and seams between teams. These edges are where assumptions go unspoken and responsibility gets blurry. TPMs create leverage by reinforcing the edges early, not by micromanaging the center.

Reflection: Identify one seam between teams that hasn’t been explicitly reinforced.

22. Status Is a Lagging Signal

By the time an issue appears in status, the important decisions have already happened. Status captures outcomes, not momentum or decay. Early signals live in hesitation, repeated questions, and subtle scope shifts. Strong TPMs listen for what isn’t being said, not just what’s reported. They tackle these decisions rather than waiting for status for something to be done.

Reflection: Write down one concern you’re carrying that hasn’t made it into status yet.

23. Milestones Hide Risk

Milestones create a sense of control but conceal most real risk. Dependencies drift and assumptions decay between checkpoints. When teams only focus on milestone completion, problems surface too late to recover cheaply. TPMs stay engaged in the in-between moments where risk actually accumulates. They name the implicit and keep an eye on the explicit risks before things go sideways.

Reflection: Look between your next two milestones and name the implicit and explicit risks.

24. Execution Is a Social System

Execution doesn’t happen in a vacuum. Incentives, fear, trust, and ego shape outcomes as much as plans do. Ignoring this leads to repeated surprises that feel “unexplainable” after the fact. TPMs work with human systems, not just schedules.

Reflection: Observe one social dynamic between teams or individuals currently influencing execution more than the plan.

25. Repetition Reveals Structural Gaps

When the same issue keeps resurfacing, it’s rarely a one-off mistake. Repetition signals a structural problem that hasn’t been addressed. Treating symptoms with reminders or escalation wastes energy. TPMs look for the underlying design flaw and fix that instead.

Reflection: Identify one recurring issue and ask what system allowed it to persist.

26. Structure Beats Heroics

Heroics feel good in the moment but don’t scale. When execution depends on individuals saving the day, the system is already failing. Sustainable programs rely on structure that absorbs normal variability. TPMs replace heroics with systems before burnout sets in.

Reflection: Notice where execution currently depends on someone “stepping up” repeatedly.

27. Good TPMs Reduce Surprise

Predictability matters more than speed. Teams can handle bad news if it arrives early, but surprises erode trust quickly. Many execution failures aren’t about missed goals rather they’re about when people found out. TPMs optimize for fewer surprises, not perfect outcomes.

Reflection: Ask yourself where surprise is still likely in the current plan.

28. Timing Matters as Much as Content

The right decision at the wrong time can still fail. Poor timing creates resistance even when the logic is sound. TPMs pay attention to organizational readiness, competing priorities, and emotional context. Execution isn’t just about what to do, it’s about when to do it; when to escalate, when to ask for more resources, when to change the plan.

Reflection: Consider whether the timing is right for a decision you’re about to push.

29. Execution Requires Reinforcement

Agreement is not the end of execution; it’s the beginning. Decisions decay unless reinforced through follow-ups, reminders, and visible action. Drift often happens quietly after alignment meetings. TPMs protect intent by reinforcing decisions until they stick.

Reflection: Reinforce one decision that’s at risk of fading.

30. Execution Is Continuous

Execution doesn’t pause between meetings or milestones. Risk accumulates even when nothing seems to be happening. TPMs stay engaged in the quiet stretches, not just during high-visibility moments. Consistent attention prevents last-minute chaos.

Reflection: Re-engage in one area that currently feels “under control.” Dig deeper, any surprises yet.

JUDGMENT: Where seniority actually shows up

31. TPM Is a Judgment Role

Tools, processes, and frameworks support TPM work, but they don’t define it. The real value comes from judgment; knowing what matters now, what can wait, and what risk is real versus theoretical. Poor judgment often hides behind rigid adherence to process. Strong TPMs are trusted because they consistently make reasonable calls under uncertainty.

Reflection: Think about a recent situation where judgment mattered more than following the process.

Read more

In 2025, my mission was simple: help TPMs grow with intention.

Not by chasing titles or copying FAANG playbooks or writing overdone advice but by developing judgment, leverage, and clarity in a moment where our role is being actively reshaped. I spent a lot of time writing about the uncomfortable middle we’re in right now: GenAI, LLM-powered tools, agents, and the quiet erosion of the “traditional” TPM toolkit.

Most of us can feel the shift. Few of us have a clear map.

In 2026, I want to unlock even more value for you, and make it easier to go deeper. To do that, I’m offering a 40% discount on the annual subscription ($80 → $48) for readers who want to seriously invest in their craft.

This offer is only available for the next 48 hours!

40% Discount On Annual Subscription

Why join?

Because TPM growth no longer comes from doing more process; it comes from better thinking. A premium subscription gives you frameworks, mental models, and lived lessons that help you make sense of ambiguity, operate at higher altitude, and stay relevant as AI changes how work actually gets done.

You will immediately unlock:

• Interview Guide For TPMs: A practical, opinionated guide built from real interviews across Apple, Google, Nike, Airbnb, Humane, and more. This isn’t about memorizing answers; it’s about learning how to think like a senior TPM, tell coherent execution stories, and demonstrate judgment under pressure.

• Getting Started With AI Tools as TPM: A grounded entry point into using AI as part of your workflow, not as a novelty. Learn how to experiment responsibly, where AI actually saves time, and how to avoid the trap of outsourcing your thinking while still gaining leverage.

• Premium Content Backed By Real World Experiences: Long-form writing that goes beyond surface-level advice. These pieces connect strategy, execution, culture, and technology, drawing from both big tech and startup environments, to help you build durable instincts, not just short-term tactics.

• A network of thoughtful, dedicated readers: You’ll be joining a quiet but serious group of TPMs who care about the craft. People who reflect, question defaults, and are actively shaping what the role becomes next, rather than waiting for a job ladder to tell them.

If my newsletter has helped you pause, think differently, or make a better decision at work, spending $48 to invest in yourself in the coming year is a no brainer. Don’t just take my word for it:

I'm in middle of my TPM interviews at Google and the frameworks and your approach to problem solving is really helpful. - J.K. (TPM Insurance) Paid Member Subscriber.

Best content I can find on actual TPM (plenty for PM for some reason!) - T.K. (TPM Security) Paid Member Subscriber.

Thank you for doing this for TPMs. There is a lot of content out there for product managers, developers etc but not a lot for TPMs. Looking forward to your content! - Tm. K. (TPM) Paid Member Subscriber

This discount link expires in 48 hours.

Cheers and Happy New Year!

- Aadil

Subscribe now

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

💰 LIMITED TIME OFFER Until DEC 31, 2025 - To continue my mission to help TPMs grow, I am offering a 30% discount on my annual subscription ($80) which gives you access to microguides, premium content and more.

Annual Subscription for $56 For 1-Year

This will be my final post of 2025

Whether it’s the time of year or the added anxiety from recent layoffs, I’ve been reflecting on a pattern I consistently see during interviews. There’s one common mistake that shows up again and again, not just with Technical Program Managers, but with Product Managers as well.

If you’re preparing for 1:1 interviews, this is worth your time.

The Reality of the Timeline

A typical 1:1 TPM interview lasts 30–45 minutes. On average, that time breaks down like this:

• 5 minutes: introductions and light conversation

• ~21 minutes: three questions at ~7 minutes each

• ~4 minutes: your questions for the interviewer

In a 45-minute interview, you might get one or two additional questions but not much more.

That’s it. That’s the entire window.

Your Mission

You effectively have 30 minutes to convince someone that you deserve the next round or the job.

It’s wild when you think about it. Your career trajectory may hinge on a short interaction with someone who only knows you through your résumé. That means your objective is simple but demanding:

Maximize the interviewer’s time to ask questions, and deliver strong, focused answers every time.

This isn’t about luck. It’s about strategy.

Use Your Time Ruthlessly Well

The Introduction (30–60 seconds, no more)

If you take more than a minute to introduce yourself, you’re already off track. This is not the time to walk through your résumé.

Your intro should cover just three things:

1. How long you’ve been a TPM

2. The domains you’ve worked in (software, hardware, cloud, etc.)

3. What you’re doing now—and where

Example:

“My name is Aadil. I’ve been a TPM for 15 years across both IC and people management roles. I’ve worked on highly complex, cross-functional programs spanning software, hardware, cloud, and AI. Currently, I’m a Staff TPM at Airbnb, leading AI-powered customer experience products.”

Clear. Concise. Done.

The Most Common Interview Mistakes

1. Spending Half the Answer on Context

If a question gives you 7 minutes and you spend 3–4 minutes explaining background, it’s game over.

Historical context rarely matters. Your role, decisions, and impact do. Maximum focus on those. Set enough context to make your role pop even more but don’t walk me through the politics unless it matters.

2. Not Focusing on You

This is your interview, not your team’s.

If you spend most of your answer describing what “we” did or the “team” did, the interviewer cannot assess your contribution. Use “I” deliberately and unapologetically.

3. Rambling Answers

This advice is common, and still widely ignored.

Long-winded responses dilute strong signals. Time your answers. You’re not memorizing scripts; you’re training your pacing so you can land the point quickly and clearly.

4. Underestimating What Counts as a “Good” Problem

Many candidates limit themselves to large, formal programs. That’s a mistake.

Complex bugs, production outages, incident responses, or messy cross-functional problems between projects can make excellent material for both behavioral and technical questions. If it was ambiguous, high-impact, and required judgment, it’s fair game.

Final Word

These insights are drawn from my interview guide, which also includes a deeper framework for tackling technical questions. Use discount code TPM2026 to access the Microguide.

Annual Subscription for $56 For 1-Year

The Art of Doing Technical Program Management

🔐 TPM Microguide On Interview Preparation - v1.0

Hi, I am Aadil and I write this newsletter on the art of doing technical program management…

Read more

2 years ago · 11 likes · 2 comments · Aadil Maan

No interview advice is truly prescriptive. Some people benefit from structured playbooks; others prefer collecting multiple perspectives. Think of this as another data point, one designed to help you be more intentional with the most constrained resource you have in an interview: time.

Good luck, and see you in 2026.

-Aadil

💰 LIMITED TIME OFFER Until DEC 31, 2025 - To continue my mission to help TPMs grow, I am offering a 30% discount on my annual subscription ($80) which gives you access to microguides, premium content and more.

Annual Subscription for $56 For 1-Year

As 2025 comes to a close, I would love to hear from you about how helpful the newsletter was for you - paid and free subscribers. The survey will take less than 5mins to complete so help me help you help me help you. 😊

Feedback On The Survey (Less < 5mins)

I’m shifting the focus of my newsletter writing toward paid premium content. Why?

After taking a full year off, I resumed my newsletter this past year with an emphasis on deeper, more durable content, most notably the TPM Microguides.

The response to this work, along with my first on-demand TPM course, has been unexpectedly strong. One piece of feedback that stayed with me:

“I’m in middle of my TPM interviews at Google and the frameworks and your approach to problem solving is really helpful.” - TPM Microguide on Interviews

Looking ahead to 2026, I’m working on an exciting new chapter: writing a book on AI and Technical Program Management. A group of wickedly smart TPMs are collaborating on something much needed. You will hear more on it soon.

As a result, my energy will increasingly go toward paid, premium content for this newsletter in between including the launch of additional courses in Q1 2026.

2025 was reinvigorating for me. 2026 will be shooting for the moon and I am glad you, my readers, are all for the ride. Let’s grow into better TPMs together!

Where Is Technical Program Management Heading in 2026?

2025 Was… a Lot

2025 was nutty. For everyone.

Forget the AI hype cycle for a second. Add in big tech layoffs, a shaky economy, trade wars, wildly misguided and misinformed RTO mandates and whatever new surprise showed up this week. I honestly thought that post-pandemicwe might finally get a breather.

Nope. The roller coaster kept going. And now, layered on top of all of that, is the question I hear constantly from TPMs:

“Where is my role heading in 2026?”

Here’s how I’m thinking about it; less as bold predictions, and more as observations forming from conversations, patterns, and what I’m seeing from industry leaders and teams in the trenches.

AI Tools Will Only Get Smarter (and Cheaper)

If Moore’s Law—or any modern variation of it—holds, then AI models and tools will continue to improve at a rapid pace. The tools we’re using today are the worst versions we’ll ever use.

The CPO of OpenAI put this perfectly on Lenny’s Podcast: this moment is a massive level-set. Without dramatically changing our workflows, our capacity will continue to increase simply because the tools get better underneath us.

This aligns with something I’ve written about before:

AI isn’t powerful because it’s magical. It’s powerful because it compounds.

TPMs who understand this will stop obsessing over “the perfect tool” and start designing workflows that age well as the tools improve.

Experimentation Time Is Ending. It’s Time to Get Real.

The novelty phase is wearing off.

Automatic meeting summaries, Jira ticket cleanups, and surface-level dashboards were necessary first steps but they’re no longer enough. Leaders and TPMs are starting to ask the real question:

What is the actual ROI here?

The TPMs who will stand out in 2026 are the ones who can separate signal from noise, a skill TPMs have always been good at, and one that matters even more now.

We’ll see a shift toward:

• Predictive planning and scenario modeling

• Risk simulations across dependencies

• AI-assisted forecasting instead of status reporting theater

In other words: fewer gimmicks, more systems thinking.

Lack of AI Tool Access Will Become a Real Organizational Problem

Here’s a quiet failure mode I’m seeing already.

Many companies say they “support AI,” but in practice, TPMs are stuck with generic access to ChatGPT or Claude, while the real leverage lives in specialized tools.

This is where TPM leadership needs to step up.

Listening to IC TPMs who are asking for specific tools, helping unblock security reviews, pushing through budget approvals; this will increasingly become a management responsibility, not an individual workaround.

Access is leverage. And lack of access will hurt.

AI Training Will Become Table Stakes for TPM Teams

If you’re running a TPM org and you haven’t figured out how to fund learning yet, you will fall behind. Full stop.

We are in a rare moment where:

• High-quality AI education is widely available

• It’s taught by practitioners, not theorists

• It’s affordable relative to its impact

Platforms like Maven are leading here: industry teaching industry.

This echoes something I’ve said before: TPMs don’t need to be AI experts, but they do need to be fluent enough to ask better questions and design better systems.

TPMs Are Running Out of Excuses Not to Experiment

I’ll be blunt.

If you’re still avoiding AI tools, or waiting for “the right time”, you’re putting yourself at risk. Not just for future roles, but for relevance in your current one. That said, job longevity has never been guaranteed. Skills alone don’t save roles. But learning does improve your odds.

The TPMs who treat AI like a curiosity will struggle. The ones who treat it like leverage will adapt.

So… Where Is the TPM Role Actually Headed?

Here’s my current synthesis.

In 2026, we’ll see a convergence of roles, especially in smaller and mid-sized companies. The line between Product Manager and Technical Program Manager will blur even more.

Some specific shifts I expect:

• Everyone will be expected to be a builder, not just a coordinator

• Tools will replace the need for custom internal systems that once required engineering investment

• “Jira ticket wrangler” TPM roles will fade out

• TPM teams will run flatter in orgs with ~100–300 engineers

• The generalist IC TPM will make a comeback

• Companies will wait longer before hiring their first TPM, thanks to embedded AI tools like Rovo

• Engineers will absorb more program responsibilities

• Demonstrating AI fluency will become normal in TPM interviews

• Big tech TPM roles will change the least, AI will mostly enhance knowledge retrieval and basic automation

• TPMs with cross-stack experience and strong AI leverage skills will be the most in demand

• More AI tools will emerge to support TPMs, not replace them

Final Word on 2025

None of these predictions might come true. Or all of them might. The diversity of opinions inside the industry right now is a signal in itself. The technology is moving fast, and certainty is uncertain.

One thing is clear: Constant learning, unlearning, and relearning will be the norm in 2026.

TPMs who stop experimenting will get blindsided, not because AI replaces them, but because the world around them keeps moving.

Until next time,
—Aadil

Subscribe now

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

P.S. I have launched my first new on-demand TPM Course right here on this newsletter — Foundations Of Technical Program Management.

📣 Subscribe to my new “On Demand Course” annual subscription and unlock my highly rated Maven course content + FREE access to all future courses.

🔥 50+ TPMs have taken the course live. Some used it to level up their TPM game while others used the content to MOVE INTO a TPM role.

In the modern AI world, the foundations of TPM role will be the key difference between churning AI slop or becoming an impactful AI native TPM.

💪🏽 Unlock your full TPM potential today!

The Art of Doing Technical Program Management

📽️TPM Course: Foundations Of Technical Program Management

⚠️ This course is only available to On Demand Course subscription members. Upgrade your subscription today to take full advantage of the course content…

Listen now

a year ago · 1 like · Aadil Maan

Building products inside a hyper-scaled Big Tech machine and building them inside a scrappy, fast-growing startup feel like two different universes but the pressure, the pace, and the stakes are very much the same.

I’ve lived in both worlds. I’ve gone from the comfort of well-oiled, decades-tested systems at Apple and Google to the raw, unfiltered chaos of a startup racing from 10 engineers to well over 100 across hardware, software, and cloud.

In that kind of growth, the ground shifts beneath your feet every few months. What worked last quarter breaks this quarter. What made sense at 10 people collapses at 50. What kept you aligned at 50 turns brittle at 150. You learn quickly, sometimes painfully, that scaling isn’t about adding more process, it’s about constantly reinventing the right amount of process for the moment you’re in.

Some lessons from Big Tech saved us. Others failed spectacularly. Most of the time, I had to experiment, observe, rebuild, adjust, and try again. Through all of that, patterns began to emerge, signals in the noise that helped us keep moving forward.

These are the lessons I learned along the way. They’re not theoretical. They’re not “best practices.” They’re battle-tested patterns that helped us navigate growth, chaos, and ambition. And I’m sharing them here for founders building the companies of today and tomorrow.

🔥 1. The Discipline of Clarity (Even When the Destination Is Unknown)

Structured clarity like clear goals, crisp problem definitions, explicit owners is not a luxury. It’s a survival mechanism when everything is ambiguous. Founders often carry the entire roadmap and decision tree in their heads, but the team can’t scale around that.

Common Advice: “Use OKRs so everyone knows the priorities.”
Reality Check: You don’t need OKRs. You need clarity.

Keep it lightweight:

• What do we want to do? (vision)

• Why do we want to do it? (tactical goals)

• When do we want to do it by? (time frame)

Is this OKRs-lite? Not really—no KR gymnastics, no ritualization. Just clarity without ceremony. Eventually OKRs may help, but don’t bring heavyweight process before it’s needed.

🧭 2. Ruthless Prioritization & Saying “No”

Big Tech teaches TPMs to prioritize based on impact, feasibility, sequencing, and business goals. Startups, meanwhile, feel like every idea is existential so everything looks important.

Common Advice: “Use RICE or MoSCoW to prioritize.”
Reality Check: Use simple, strict prioritization. When your goals are clear, you don’t need matrices or scoring systems. What startups do have is the ability to be far more ruthless than Big Tech.

Your ability to say “No, not now” is as important as finding product–market fit.

Pro Tip: Keep a “No Log.” It shows your team what you intentionally chose not to do and it models decisive leadership.

🔄 3. Building Lightweight Systems That Survive Chaos

I tried porting Apple/Google processes directly into a startup. It failed, spectacularly. Wrong scale. But the underlying principles of visibility, accountability, feedback loops were exactly right.

Common Advice: “Adopt Scrum or the latest agile methodology to move fast.”
Reality Check: You need minimum viable process that evolves as you grow.

A startup needs only a few things:

• A single roadmap

• Weekly decision reviews

• Clear owners

• Fast feedback loops through demos, always demos

That’s enough to prevent chaos without bureaucracy.

What about sprints, epics, rituals? You don’t need them. Think in releases. Consider Shape Up as the upper limit of process for a startup.

🔍 4. Making Invisible Work Visible

A TPM’s job is to expose dependencies, risks, and unstated assumptions. Founders often over-index on features and forget the enormous amount of invisible work that consumes engineering time like refactoring, migrations, design debt, compliance, operational readiness.

Common Advice: “Build detailed Gantt charts to surface dependencies.”
Reality Check: Keep it simple.

Try a tick–tock release cadence:

• Tick: ship features

• Tock: fix bugs, reduce debt, tighten systems

Pay down tech debt early and often. Recognize that shipping code is only part of the lifecycle.

Pro Tip: Use launch checklists so operational work doesn’t get lost. This has been the single best thing I have learned to do and every single time, leaders have been delighted by the rigors of my program launches.

⚡ 5. Shipping Fast Without Breaking the Team

Startups often pursue speed at any cost. Big Tech TPMs learn that sustainable velocity comes from reducing friction, not increasing pressure.

Common Advice: “Just ship in two-week sprints. Always be shipping.”
Reality Check: That’ll get you to MVP, but it won’t get you from 1 → n.

Think in releases, not sprints.

At Humane, we mapped our releases for the entire year. Engineers knew when each train left the station and what to expect. Tools like Linear use early access and beta testing strategically. Shape Up encourages durability in planning.

Combine this with ruthless prioritization and you relieve the time pressure that suffocates engineering creativity. And yes, they ship better work.

🤝 6. Cross-Functional Alignment as a Strategic Advantage

Big Tech expects TPMs to keep engineering, product, design, operations, and leadership aligned on a single North Star. Startups often lose alignment as they grow because roles blur or haven’t been defined yet.

Common Advice: “Run daily standups and a scrum-of-scrums.”
Reality Check: You don’t need layers of ceremony. You need touch points.

Examples:

• A weekly cross-functional sync (with all of engineering if you’re small) is better than many micro-meetings.

• A single, public decision log keeps everyone oriented.

• Regular demos offer better visibility and feedback than pages of status or perfunctory exec reviews.

Alignment is a muscle. You don’t start with heavy weight; you build strength over time. But like stretching before lifting, some basics like demos, shared goals, transparency never go away.

🧩 7. Scaling Communication Before Scaling Team Size

Big Tech TPMs see how communication breaks long before work does. Founders usually hire ahead of designing communication systems and the cracks become visible too late.

Common Advice: “Set up formal comms channels and rituals.”
Reality Check: You just need foundational rules of communication.

A few lightweight systems that pay huge dividends:

• A decision log, visible to everyone, and an expectation to broadcast major decisions

• Weekly company all-hands (Humane’s version of Google TGIF was deeply effective; just make it worth everyone’s time)

• A “Way of Comms” document for new hires:

  • Avoid private Slack channels

  • Use threads to reduce chaos

  • Make meeting notes accessible by default

These seem small, but they scale far better than any tool or process. Your future self, and your future team, will thank you.

Final Words

None of these lessons are universal. They’re not rules, and they’re certainly not the only way to build a team or scale a startup. They’re simply the patterns that revealed themselves to me, through trial, through error, through failure, and through the rare moments when everything clicked.

Your startup will have its own constraints, its own culture, its own people, and its own rhythm. Some of these ideas may fit like a glove; others may not fit at all. That’s normal. Every founder, every team, every company is living its own experiment.

Take these as one more data point; a perspective from someone who has walked both paths and had to figure it out in real time, just like you. Use them as prompts, not prescriptions. Let them spark new questions for your own journey:

• What does clarity look like for your team?

• How ruthless can you be in prioritization?

• Which lightweight systems would actually help you move faster?

• How does your team make invisible work visible?

• And what might alignment and communication look like if you intentionally shaped them early?

At the end of the day, building a startup is an act of design. You get to shape the systems that shape your company. These lessons are simply an offering, another lens to help you see the work ahead with more nuance, more intention, and maybe a bit more confidence.

What you do with them is entirely yours. So, don’t skewer, man, I have seen things and shared what I did in those moment. 🥹

Until next time!

-Aadil

Subscribe now

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

P.S. I have launched my first new on-demand TPM Course right here on this newsletter — Foundations Of Technical Program Management.

📣 Subscribe to my new “On Demand Course” annual subscription and unlock my highly rated Maven course content + FREE access to all future courses.

🔥 50+ TPMs have taken the course live. Some used it to level up their TPM game while others used the content to MOVE INTO a TPM role.

In the modern AI world, the foundations of TPM role will be the key difference between churning AI slop or becoming an impactful AI native TPM.

💪🏽 Unlock your full TPM potential today!

The Art of Doing Technical Program Management

📽️TPM Course: Foundations Of Technical Program Management

⚠️ This course is only available to On Demand Course subscription members. Upgrade your subscription today to take full advantage of the course content…

Listen now

a year ago · 1 like · Aadil Maan

A TPM’s primary role during planning cycles is to help your engineering teams navigate priorities, politics, dependencies, and unrealistic expectations with clarity and calm.

Annual roadmap planning is where TPMs earn their stripes. It’s messy, emotional, political, and often wildly unrealistic but it’s also the moment when teams look to you for clarity, structure, and grounding in what’s actually possible.

Below is a practical field guide built around 20 real questions TPMs either ask or encounter during planning season with answers on how to navigate these questions with confidence, influence, and a steady hand.

💡 Strategy & Alignment

1. How do I influence roadmap priorities when I don’t own the product decisions?

• As TPMs, our core responsibility is to advocate for what’s best for the business and ultimately for the customer. The most effective way to influence decisions is to connect every proposal, every ambition, every idea, back to the company’s strategic objectives. Use OKRs, mission statements, and clear metrics to anchor your point of view.

• Ask thoughtful questions that guide the cross-functional team toward the conclusion you know is aligned with the business. Influence is often a function of the questions you ask.

• A Word On Influence: Your influence grows with trust and tenure. Your credibility compounds with every successfully delivered program. If you’re new, your influence may be limited at first and that’s completely normal. Consistent execution builds the platform your future influence stands on.

2. What’s the best way to highlight gaps between what’s being planned and what’s actually feasible by engineering — without sounding negative?

• The cleanest argument is capacity.

• Use simple math: X engineers × Y working weeks = total available capacity.

• As you map scoped work against that number, the reality becomes obvious. You’re not blocking, you’re revealing constraints and realities in which all decisions must be grounded in.

• Your goal isn’t to prove anyone wrong; it’s to spark an honest conversation. Few things cut through noise like simple, visible data.

3. How do I ensure our roadmap ties back to company OKRs when product priorities seem loosely connected?

• Ask clear, innocent questions: “Which OKR does this initiative map to?”

• If the answer is vague, follow up: “Should it map to an OKR? If not, what’s the rationale?”

• TPMs are at their strongest when they ask obvious but necessary questions that expose misalignment without creating conflict.

4. What should I do when different product areas have conflicting priorities that all need shared engineering resources?

• Your job is to surface bottlenecks early and make them impossible to ignore.

• Start by aligning product owners on which initiative drives the most meaningful business impact or OKR progress.

• If that fails, escalate to product and engineering leadership. The real choices are usually:

  • Prioritize one over the other, or

  • Shift resources by deprioritizing something else.

• ⚠️ Warning: Avoid the “just hire someone” solution; hiring plus onboarding can take months. Hope is not a roadmap. Remind leadership that credible plans require real constraints. Focus only on the butts in seats you have today, not what you hope to have tomorrow.

5. How do I handle leadership asking for “stretch” goals that I know are unrealistic given current bandwidth?

• Bring it back to capacity and committed P0 work.

• It’s fine to size stretch goals, but label them clearly as stretch, aspirational, not promised.

• If leadership insists the stretch goal is mandatory, then it isn’t a stretch goal. Reclassify it as a must-have and revisit trade-offs.

• Protecting engineering teams from overcommitment isn’t resistance, it’s leadership.

🧭 Dependencies & Cross-Team Alignment

1. What do I do if a dependency team declines to support a top-priority feature for my org?

• You have two realistic options:

  1. Find a workaround. Can your engineering team temporarily bypass the dependency, even if it means tech debt or a short-term patch?

  2. Negotiate timing. Adjust scope or sequencing so the work aligns with when the dependency team can support it.

• Document decisions, communicate broadly, and make the downstream impact explicit. Clarity prevents re-litigation later.

2. How do I track and communicate inter-team dependencies without overwhelming everyone with spreadsheets?

• Use a simple shared doc, a work breakdown or scoping document works best.

• For each requirement, list:

  • Teams involved

  • High-level scope (epic-level detail)

  • Estimated effort (in weeks)

• Google Docs enables async discussion with comments, which is more efficient and human than complex tracking tools.

3. How do I get commitment from teams with competing priorities or different planning cycles?

• If cycles don’t align, secure a soft commit first; a yes/no on whether they can support the work. Anchor in company OKRs when possible.

• Next, lock down a date when they can provide final estimates. Mark that clearly in your tracker.

• Progress beats perfection. “Soft committed with final sizing on <date>” is more useful than “Team X can’t commit.”

4. What’s the right level of escalation when a dependency slips or refuses to commit?

• Level 1: Working group (TPMs, PMs, TLs etc).

• Level 2: Functional leadership (directors).

• Level 3: Executive leadership (VP+), reserved for cross-org priorities or roadmap-critical risks.

• Most issues resolve by Level 2. Escalate higher only when the impact is broad and strategic.

5. How do I make cross-team planning sessions productive instead of political battles?

Read more

Subscribe now

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

We know the patterns…

Every planning cycle I’ve ever been part of begins with a familiar ritual. Someone pulls up a list, those pesky 50 features long roadmap, and declares, “We just need estimates so we can decide what fits.” And thus, two schools of thought emerge:

• School A: Estimate everything. Size all 50 features so leadership can make informed trade-offs.

• School B: Focus deeply. Narrow it down to 10 features, then estimate them in detail to understand what scope needs to be trimmed.

Both schools believe they are doing the sensible and rational thing. One seeks breadth; the other, depth, both want something realistic to build and ship. And somewhere in all of this, the TPM is meant to guide engineering through the fog of estimation without burning everyone out or getting lost.

The Harsh Realities of Estimation

No matter which school you belong to, a few things are always true:

• Planning cycles are too short. You never get a full quarter to estimate.

• Leadership expects high-confidence numbers right away.

• Requirements can be half-baked, and designs are still in “concept” mode.

Which means your estimates are, at best, leading indicators, not promises. Margins of error will be high. Engineers will pad where they must. And as solutions evolve, timelines will stretch and contract like a rubber band.

Estimation isn’t a science or precision arithmetic, it is forecasting and prediction.

When You’re in School A

When you’re asked to estimate everything, 50 features, 12 epics, and 300 Jira tickets before next Friday, the only realistic approach is not building precision rather it’s expectation management.

• Set the tone early: Make it clear that confidence levels vary with the estimates.

  • High Confidence: These won’t change.

  • Medium Confidence: Within ±1–2 sprints.

  • Low Confidence: We’ll revisit once missing requirements arrive.

• Break it down: Don’t provide a single “magic number” for a feature. Instead, show what’s known, what’s unclear, and where the gaps lie. A long list of XL estimates is not useful to anyone.

• Negotiate at the right altitude: Don’t slice 10% off fifty features, it’s chaos and delusional. Cut 80% of the roadmap first, then refine the remaining 20%.

• Watch for disguised work: Bug fixes pretending to be features will wreck your capacity planning. Save a chunk of your capacity for KTLO and Bug Fixing.

• Anchor with a North Star: Ask Product which metrics truly matter. When the list is long, clarity about impact becomes your best friend. Go further and ask them to stack rank everything if they don’t want to cut the list.

When You’re in School B

In School B, you’ve got fewer features but deeper expectations. The pressure shifts from speed to accuracy.

• Set confidence levels anyway: Smaller list ≠ perfect data. Confidence levels will be required. See point in School A.

• Define the MVP early: Don’t over-engineer the wrong features. You still need to focus the finite time you have to plan.

• Maintain rhythm: Extra time can lead teams into endless rabbit holes of “what if.” Keep the cadence steady.

• Stay humble about capacity: Even a tight, focused list can exceed bandwidth once reality sets in.

Final Words

No matter which school you’re in, estimation always comes down to this: How well did you set expectations?

Because at the end of the cycle, the goal isn’t to have perfect numbers, it’s to ensure no one is shocked when the numbers change.

Communicate early. Share progress often. Remind everyone that estimates evolve as clarity improves. Surprises at the end mean panic meetings, which lead to rushed compromises and those rarely end well.

Estimation isn’t about control. It’s about alignment. And as TPMs, that’s our real art form; bringing order, honesty, and calm to a process built entirely on uncertainty.

Happy Planning!

-Aadil

P.S. I have launched my first new on-demand TPM Course right here on this newsletter — Foundations Of Technical Program Management.

📣 Subscribe to my new “On Demand Course” annual subscription and unlock my highly rated Maven course content + FREE access to all future courses.

🔥 50+ TPMs have taken the course live. Some used it to level up their TPM game while others used the content to MOVE INTO a TPM role.

In the modern AI world, the foundations of TPM role will be the key difference between churning AI slop or becoming an impactful AI native TPM.

💪🏽 Unlock your full TPM potential today!

The Art of Doing Technical Program Management

📽️TPM Course: Foundations Of Technical Program Management

⚠️ This course is only available to On Demand Course subscription members. Upgrade your subscription today to take full advantage of the course content…

Listen now

a year ago · 1 like · Aadil Maan

Subscribe now

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

My Dearest TPMs,

It is once again planning season, the most wonderful time of the year, when we hold out hope that maybe this time, the number of features engineering needs to estimate will be a reasonable handful. A small enough list to let you, my TPM comrades, build high-confidence estimates and sizings so the executive leadership team can make informed decisions about what to commit to for fiscal year 2026.

Alas, reality will likely look different. We’ll find ourselves staring down a list of 50 features, armed with never enough time and somewhat useful PRDs (not that we’re writing those anymore, thanks, GenAI). Many will have gaping holes in requirements, but we’ll be told, “Be agile! You don’t need all the requirements. We’re not waterfall, you know.” And you will spend every ounce of self-control not to make the “what did you just say?” face.

By the end of the planning cycle, after surviving what feels like a Cirque du Soleil act gone horribly wrong, we’ll emerge with our best “it’s fine” confidence-level estimates, only for them to be immediately changed, to the utter shock of our leaders and product partners. And once again, one of the many grand conclusions, along with engineering needs to better sizing, will be that we need a better prioritization framework.

But here’s the truth: the framework isn’t the problem. It never was.

The real ailment is the lack of direction and focus, the absence of a clear, shared understanding of where we’re going. That’s why we end up with a massive list of 50 things, hoping that if we stare at it long enough, sprinkle in some numbers, and rank them just right, the right strategy will magically appear.

If you ask me, and I’ve seen this play out across many teams and companies, when you have a strong sense of direction, a goal with real conviction (not just a vague OKR), you don’t need to estimate 50 things. You only need 5 or 7, something single digit and low.

When the goal is clear, product spends more time defining great requirements, design might give us more than just a vague concept, and marketing could be build a compelling vision. Engineering gives better estimates. You get cleaner plans, stronger alignment, and - dear God - less churn later in the development lifecycle.

So no, your prioritization framework is just fine. What you need is clarity, conviction, and the courage to say, “We’re doing these five things and not the rest.”

Sometimes all you need is a better and clearer WHY, not a new framework. Also - not sure you can vibe code your way out of this one.

More advise and guidance to follow in the coming weeks as planning season progresses through its many crescendos.

Until next time!

-Aadil

P.S. I have launched my first new on-demand TPM Course right here on this newsletter — Foundations Of Technical Program Management.

📣 Subscribe to my new “On Demand Course” annual subscription and unlock my highly rated Maven course content + FREE access to all future courses.

🔥 50+ TPMs have taken the course live. Some used it to level up their TPM game while others used the content to MOVE INTO a TPM role.

In the modern AI world, the foundations of TPM role will be the key difference between churning AI slop or becoming an impactful AI native TPM.

💪🏽 Unlock your full TPM potential today!

The Art of Doing Technical Program Management

📽️TPM Course: Foundations Of Technical Program Management

⚠️ This course is only available to On Demand Course subscription members. Upgrade your subscription today to take full advantage of the course content…

Listen now

a year ago · 1 like · Aadil Maan

⚠️ This course is only available to On Demand Course subscription members. Upgrade your subscription today to take full advantage of the course content.

Subscribe now

Mastering the Technical Program Manager Role

If you want to understand what it takes to drive complex projects to success in fast-paced, technical environments, this course is for you. A Technical Program Manager (TPM) isn’t just a project manager—they’re the strategic force that aligns teams, removes obstacles, and makes things happen.

In this course, we’ll dive deep into the TPM role, covering everything from the core responsibilities to advanced strategies that will set you apart. Whether you’re new to the field, planning to transition into the role, or just trying to understand how TPMs can make your team more effective, this course will give you the clarity and tools you need.

Here’s what you’ll gain:

• 📚 The TPM Foundation: Understand the essential responsibilities and mindset that define a successful TPM, from leading complex programs, to managing stakeholders to navigating technical challenges.

• ⚙️ Practical Strategies for Success: Learn how to organize, prioritize, and deliver on complex programs that drive real results.

• 🚀 Leadership at Scale: Discover how TPMs act as force multipliers, creating alignment across teams and ensuring smooth execution on ambitious goals.

Who Should Take This Course?

• New to the TPM role: Learn the key skills and strategies to hit the ground running and make an immediate impact.

• Looking to transition into TPM role: Get the knowledge you need to confidently move into the role and lead technical programs.

• Product / Engineering leaders: Understand what to expect from TPM, how to leverage their expertise for better project execution & alignment.

By the end of this course, you’ll not only understand what makes an effective TPM—you’ll be ready to apply these strategies in your own work or to empower TPMs in your organization.

Course Content Outline:

Ch 1. Why Take This Course?

• What makes you want to take this course?

• What will you have at the end of the course?

Ch 2. Foundation

• What is Technical Program Management?

• Why do we need TPMs?

• Where do TPMs sit in the org?

Ch 3. Leading Complex Programs

• What is complexity?

• A First Principles Framework

• Building Flexible Plans

• Stakeholder Management Simplified

• Right Way to Manage Risk

• Find Signal in the Data

• TPM Mindset(s)

Ch 4. Leading Without Authority

• Shape of Power

• Different Types of Powers

• Building Influence

• Dealing With Difficult People

• Your Career Goals Impact Influence

Ch 5. TPM Super Powers

• The Secret Method

• Systems Philosopher

• Decomposing Systems

• The Irrational Method

• Speaking Executive Speak

• Learning Mindset

• TPM As World Builders

• Physics Of Work

• Hedgehogs + Foxes

Ch 6. Being More Technical

• Common Patterns In Tech Systems

• C4 Language

Ch 7. Case Studies + Retrospectives Of Real World Projects

• Difficult Person (Apple)

• Zero to One (Apple)

• Longest Program (Apple)

• A Program That Failed (Nike)

• A Perfect Program (Google)

Ch 8. Closing Thoughts

• Key takeaways and remarks on where to take your TPM learning

FAQs

What Is the best way to watch the course videos?

This is self paced course meaning you watch it at the speed and pace as you see fit. You can reference the chapter list below, jump around the various chapters, watch as you see fit and for as many times as you want. The goal is to provide you reference material that you can keep coming back to over and over again.

What If I Have Questions, Comments, Feedback?

Feel free to DM me directly on Substack or email me with your questions, comments and feedback whenever you want - aadilmaan at gmail dot com.

Ready to get started and take your TPM skills to the next level? Lets begin and take it at your own pace.

Course Content

Ch 1. Why Take This Course?

• What makes you want to take this course?

• What will you have at the end of the course?

Ch 2. Foundation

• What is Technical Program Management?

• Why do we need TPMs?

• Where do TPMs sit in the org?

Ch 3. Leading Complex Programs (00:17:40)

• What is complexity?

• A First Principles Framework

• Building Flexible Plans

• Stakeholder Management Simplified

• Right Way to Manage Risk

• Find Signal in the Data

• TPM Mindset(s)

Read more

Subscribe now

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

There’s one question that will soon define the next generation of Technical Program Managers and one I now permanently ask in every interview regardless if I am interviewing a Product Manager or a Technical Program Manager: “How do you leverage AI tools to improve your own impact and the impact of the teams you support?”

This isn’t a trick question. It’s a lens; a way to gauge whether a TPM, or anyone, understands how their role is evolving in an AI-powered world, where productivity is stretching beyond the process, but an opportunity to amplify your impact on self and team.

Why This Question Matters

The TPM role has always been about enabling teams to do their best work to connect dots, unblock progress, and bring predictability to chaos. But the toolkit is changing.

The TPMs who will stand out in the next decade aren’t just fluent in Jira boards, sprint ceremonies, or status reports; they’re fluent in AI-assisted execution.

Whether it’s summarizing meeting notes, analyzing trends, automating repetitive reporting, or running workflow experiments, AI tools now allow TPMs to scale their impact far beyond what was previously possible. No more asking for more resources to build that one specific tool you wish you had.

Therefore, this single interview question helps separate those who are merely aware of AI from those who apply it to create real leverage whether for themselves and/or their teams.

Signals for Interviewers

When you ask this question as an interviewer, listen for a few key signals:

• Exposure: What kinds of tools has the candidate actually used? Are they exploring built-in capabilities like Gemini in Google Docs, or venturing into advanced tools or maybe even building their own custom GPTs or agents using Claude or OpenAI?

• Application: What problems are they solving with these tools at a personal level (e.g., prioritization, synthesis, communication) and at a team level (e.g., automating updates, improving visibility, synthesizing progress)?

• Depth: Are they going beyond surface-level tasks like summarizing emails and documents? The best TPMs will use AI to synthesize, predict, and influence, not just summarize.

• Context: If they haven’t used AI tools, why not? Is it because their organization hasn’t adopted them yet, or because they haven’t made the effort to explore? That distinction matters. One the candidate has control over, the other they unfortunately don’t.

This isn’t about judging capability, just yet. It’s about identifying mindset, curiosity, initiative, and adaptability. You’re assessing whether the candidate has the learning agility to thrive in an AI-augmented environment.

Guidance for Interviewees

If you’re preparing for interviews, start gathering specific examples of how you’ve used AI tools to create impact. The more concrete, the better.

For example:

• Have you used AI to draft project plans, decision docs, or risk summaries?

• Have you created dashboards or automations to track metrics and milestones?

• Have you used AI to clarify complex trade-offs or speed up technical discussions?

⚠️ Point Of Clarification: If your company hasn’t rolled out AI tools yet just say so. Many are still catching up. But don’t stop there. If you can show how you’ve taken the initiative personally, thats top marks. Maybe you’ve experimented with ChatGPT, Claude, or Gemini to learn how they think. Maybe you’ve built your own prompts or micro-agents to simplify your workflow. These are all still great examples of your learning mindset.

Your goal isn’t to prove high expertise but it’s to demonstrate curiosity. TPMs with a growth mindset stand out because they’re willing to learn, experiment, and adapt before they’re told to.

That’s what the best TPMs have always done: learn quickly, connect dots, and help others move faster.

💡Question to ask you future employer: Interviewees don’t have to hold back but can rather push on the future employer with questions like:

• What kind of AI tools are available at your company?

• Do you provide educational budget for someone who wants to learn and acquire AI skills?

• Do you have a healthy experimentation and sharing group for AI users within the company?

You want to work for a company that is thinking about the future today. No point in working for dinosaurs.

The Real Signal of Future-Ready TPMs

AI fluency is quickly becoming the new digital literacy, a signal of both curiosity and future readiness.

⚠️ Counter Argument: Some might argue that this kind of questioning is still too early. I would argue, no. The pace at which AI research and development is happening, things like these will sneak up on you. Those who get ahead will be better prepared for an inevitable future in progress.

For interviewers, this question reveals whether a candidate is a passive observer or an active shaper of how work gets done.

For interviewees, answering it well shows that you’re not waiting for permission to explore, you’re already building the future of program management, one experiment at a time. It is also an opportunity to judge your future employer as well. Can they talk the talk by helping their workforce adapt to this new future?

But this question isn’t just about evaluating candidates. It’s a mirror for the role itself. As AI becomes woven into every layer of program management, the TPM interview must evolve too. We can’t assess future-ready TPMs with yesterday’s questions.

The best TPM interviews will now focus beyond what you did but start asking on how you amplify yourself and your impact. How do you adapt. How do you turn new tools into new forms of leverage.

In this new era, curiosity isn’t optional, it’s a core competency. And the TPMs who keep asking “How can AI help me multiply my impact?” are the ones who’ll keep shaping the future of this craft.

Until next time.

-Aadil

📣 TPM Basecamp 2025, the penultimate annual TPM gathering is around the corner and this year, they have a new global innovative format.

🗓️ November 14 - The Penultimate TPM Annual Gathering
Join us for a global, distributed event designed by TPMs, for TPMs — with in-person gatherings in India, the US, and Canada, plus a shared, real-time virtual experience.
This one-day event is designed to create deeper, real-time connections between TPMs. You’ll hear from exceptional local speakers, then stay for global cross-talk as each chapter shares a live session from their region.

🤑 There is a special discount for my readers. Use coupon code AADIL20 and get 20% off your ticket.

🛒 Get your tickets NOW!

💬 At every summit and meetup, we’ve seen it: TPMs thrive when they collaborate, exchange ideas, and support each other’s growth. TPM Basecamp is built for exactly that.

🎤 Here’s a first look at some of the expected speakers:

• 🇺🇸 Bay Area: Jenny Truong, Director of TPM at Meta

• 🇨🇦 Vancouver: Reji Varghese, Senior TPM at Autodesk – The Technical Challenges Every TPM Must Master

• 🇺🇸 New York: Tal Lazar, award-winning cinematographer, producer, and educator – Lessons in Authority from the Film Set “You don’t need all the answers to lead. Authority begins when others see themselves in your vision.”

• 🇺🇸 Seattle: Toby Roberts, SVP of Engineering at Zillow Group - Fireside Chat on creating and launching the TPM role at Zillow Group.

• 🇮🇳 India: A full-day, in-person experience packed with learning, leadership, and community.

  • Working sessions with Li, Gaurav Sen, and Naveen Mansur

  • Panel featuring:

    • Deeptha Mohan – Senior Director, Head of Central PMO & Customer Ops

    • Padmasini Renga Bashyam – Building Tuzo

    • Ananya - Product Manager at Google

This is more than just a series of events, it’s a global movement to elevate the TPM craft, share knowledge, and build the next generation of tech leaders.

20% Off For My Readers - COUPON: AADIL20

Subscribe now

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

An Opportunity Unlike Anything

We’re standing at a once-in-a-decade moment for Technical Program Management. For the first time, Gen AI tools are giving TPMs the ability to truly automate the busywork, amplify their awareness, and return to their true purpose: creating clarity in complex systems. This is not just an efficiency play but it’s a redefinition of value. When AI can handle elementary aspects the TPMs will increasingly own the truly impactful activities.

This is the chance to re-invent TPM work from coordination to sensemaking.

Back to Fundamentals and Sense-Making

The true impact of TPMs has always been sense-making; what is sense making? It’s connecting the dots between teams, disciplines, and signals that don’t naturally speak the same language. In every large, cross-functional effort, there are the big visible milestones and then there are the quiet edges in between them, the gaps where things tend to fall apart. At Apple, we were taught that TPMs are the nervous system of product development; they maintain the project’s memory, understanding where every moving part sits at any moment and why its sits there and how it must move. AI can track every task, dependency, and conversation. But it still can’t decide what’s noise, what’s a red herring, or what can be safely ignored. That human judgment, knowing when to act, when to wait, and when to call out the shortcut, remains deeply human and often irrational.

With Gen AI, TPMs can finally spend less time collecting signals and more time interpreting them.

The Administration Can Be Automated

The ceremonies, artifacts, and processes that once consumed TPM bandwidth like meeting facilitation, note-taking, document drafting, can now be offloaded to AI. Your AI agent can summarize the standup, record key decisions, flag risks, and even maintain living dashboards. That doesn’t make the TPM obsolete rather it makes them available again. If you’re still manually writing project updates or taking notes line by line, you’re doing it wrong.

The future TPM focuses not on documentation but on direction which means shaping conversations, framing tradeoffs, and reinforcing principles that keep the team aligned.

The Convergence Toward the Center

Think of product development as a spectrum: strategy on one end, execution on the other. Historically, Product Managers sat closer to the strategy, TPMs closer to execution. But Gen AI is collapsing that distance. Tools like Vibe Coding bring PMs nearer to execution; AI agents bring TPMs nearer to strategy. TPMs can now use AI to run analytics, synthesize insights from unstructured data, craft program narratives, and even test “what-if” scenarios. We’re witnessing a convergence unlike anything before where TPMs evolve into strategic sense-makers who bridge technical execution and business intent.

The lines between Product and Program are blurring, but the TPM’s role in designing systems that work, both human and digital, remains irreplaceable. Is the future TPM a hybrid Product Manager + Technical Program Manager?

Differentiate Between Coordinator Roles and TPMs

For years, many organizations treated TPMs as glorified coordinators; running meetings, grooming backlogs, updating Jira boards is but a small part of our function. That version of the role is fading fast or I foresee fading first. AI copilots and agents will handle the administrative layer, and what’s left will expose the real differentiator: TPMs who can think in systems, navigate ambiguity, and drive alignment across messy, multi-dimensional programs.

Yes, there will be fewer TPM roles but they’ll carry far greater impact. This isn’t contraction; it’s concentration of a specialized function. It's a net positive.

Rise of the Generalist

With ChatGPT, Claude, and similar tools, knowledge itself is no longer a competitive edge; everyone has access to the same facts. The TPMs who thrive next will be generalists with a deep capacity for learning, connecting, and adapting. They’ll move fluidly across technical and organizational domains from infrastructure to UX, from AI models to security policies, leading horizontally and cross-functionally.

Their advantage won’t come simply from what they know, but from how they synthesize and acquire new knowledge and capabilities. The quick learner will win the day.

Laser Focus > Speed

TPMs of old pre-historic-pre-AI traded between focus and speed especially when running multiple programs. The true unlock with AI is not doing things faster but free up our cognitive budget to laser focus on the truly hairy and complex things, whether milestones, dependencies, blockers etc. Speed is not the true unlock but TPMs can go deeper and wider (depth and breadth) without sacrificing high-level visibility into the day to day tactical operations of the programs you manage.

If your objective with AI as TPM is do more, flip that thinking. AI should allow you to do less but more impactful work.

The New North Star

In this reinvented era, the TPM’s North Star becomes designing predictable systems where humans and AI collaborate seamlessly. They will be the architects of hybrid workflows where they must ensure data, tools, and people create a self-correcting loop of insight and action. The TPM of the future isn’t just managing projects but they’re designing the system of work itself.

• Less ceremony, more conversation.

• Less reporting, more reflection.

• Less managing process, more shaping intelligence.

Final Words

The more I think about it, the clearer it becomes: AI doesn’t replace TPMs but it reveals them and their true value. It peels away the layers of ceremony, the noise of status reports, the illusion of busyness and exposes what was always at the heart of this role: judgment, empathy, and clarity in motion.

The future TPM isn’t buried in Jira tickets. They’re standing at the intersection of systems and people, translating complexity into comprehension, chaos into clarity.

• They know when to trust the data and when to trust their gut.

• They know when to push the team and when to protect its focus.

• They know that progress isn’t just a measure of velocity, it’s the quality of alignment.

Gen AI will change how we work, but TPMs will determine why it matters.

We’re not just witnessing the evolution of a job title, we’re likely seeing the rebirth of a discipline. The best TPMs of this next era will not compete with AI; they will compose with it. They’ll design systems where agents, humans, and data all play their parts in harmony. They’ll move faster not because they automate more, but because they understand more deeply.

This is our moment; a once-in-a-decade opportunity to reinvent what it means to be a Technical Program Manager. To move from running programs to engineering intelligence. To step beyond the process and become the sense-makers that every AI-powered organization will need.

So the question is: when the busywork disappears, how will you transform yourself? what value will you bring to your role and team?

Until next time.

-Aadil

You are reading a “TPM Microguide” designed for my paid subscribers. These are concise, actionable guidebooks designed to help TPMs level up in specific areas of their craft — whether it’s mastering technical concepts, building program structures, or learning how Apple builds software. If you want full access, please consider becoming a paid subscriber.

My aim is to publish a new guide every month.

Subscribe now

If you have Feedback and/or Suggestions to improve this guide, please leave a comment. Only paid subscribers who have access to the guide can leave comments.

OR reach out to me for any questions - aadilmaan at gmail.com.

Purpose of This Microguide

This microguide is designed to help TPMs figure out what skills will be important and what skills you will need to adapt to make yourself ready for an AI world.

Over the past year, through my own projects, conversations with other TPMs, giving talks at tech companies, and watching the shifts happening in our industry, I’ve seen the outline of what TPMs will need to succeed in the AI era.

How to Use This Microguide

Every section is written in a modular way so feel free to copy, remix, or adapt anything here including the proposed project plan template.

How I Write These Microguide

All microguides are built on a combination of in-depth research and my 15+ years of experience leading complex programs in the tech industry. I take the time to deep dive into the core pillars of each topic, aligning research with real-world insights from the industry where ever possible.

Rather than focusing solely on academic theory, I reframe the research to highlight the most practical and relevant aspects for Technical Program Managers (TPMs). The result is content rooted in reality, offering empirical insights that help TPMs navigate challenges with a practical, execution-focused approach.

TPM Skill Guide For Those Looking to Survive The AI Transition

Every time the environment around us changes, a new kind of gap appears. On one side is where you are today; the skills you already have, the patterns you already know. On the other side is what tomorrow will demand; new capabilities, new ways of working. The people who thrive in times of change aren’t necessarily the smartest. They’re the ones who can spot these gaps early and move quickly to close them.

The ones who get left behind usually fall into two groups:

• Those who never recognized the gap at all.

• Those who realized too late that the world had already moved on.

Over the past year, through my own projects, conversations with other TPMs, giving talks at tech companies, and watching the shifts happening in our industry, I’ve seen the outline of what TPMs will need to succeed in the AI era.

Some skills are foundational, the core essential that will never go away or not matter. Others are new, and investing in them now will separate you from those who are just “using AI” versus those who are truly leading with it.

This guide is my attempt to map out those skills: the foundations you must protect, the new muscles to start building, and the technical knowledge you’ll need if you want to steer AI projects rather than just react to them.

Foundation Skills You Will Still Need

Even in a world where AI is everywhere, the core of Technical Program Management remains unchanged. If you don’t have these, no amount of AI tooling will save you. It will actually be the primary difference between people seeing you leverage AI effectively versus just churning out AI SLOP.

1. Core Project Management

This is the bedrock of TPM work and will never go away. Why? Because AI can generate documents, plans, and schedules but it cannot tell you whether they make sense for your team, your product, and your context. That judgment is yours alone.

Requirements gathering, breaking down work, mapping schedules, reporting progress, and driving agile ceremonies like sprint planning and milestone tracking, these are the levers that move teams forward. The TPM who knows how to apply these in the right way at the right time ensures that AI outputs turn into progress rather than chaos.

2. Stakeholder Management

AI might do a decent job of keeping your VP aligned with your designer, or balance priorities between infra and product. But true impact of where things go off-track and keep people from losing their minds, that’s your job.

TPMs who excel here understand how to bring together cross-functional groups with competing goals and keep them aligned around a shared plan. Your ability to influence across layers of management will remain one of the most human and irreplaceable skills you own.

3. Problem Solving

Between Jira tickets and status reports, problem solving is the skill that truly defines TPM impact. It might mean mobilizing engineers to debug a thorny issue, guiding leadership through tough roadmap tradeoffs, or building a path back to green for an off-track project. The ability to calmly, systematically, and creatively work through obstacles is the TPM’s superpower and it only grows in value when AI adds more moving pieces to manage.

4. Risk Management

Strong TPMs don’t just track risks, they anticipate, mitigate, and adapt. Risk management is what makes the difference between projects that feel “under control” and those that constantly slip. In the AI era, risks multiply: hallucinations, model drift, AI slop, etc. How to leverage AI with risk will depend on your ability to first off all understand the ABC of risk management and then leveraging AI to help you proactively address those risks.

5. Core Technical Concepts

You don’t need to write production code, or ship bug fixes (you could if you want 😉) but you must understand the mechanics of software. APIs, deployment pipelines, differences between staging, QA, and production, how unit/regression/exploratory testing works, these are non-negotiables. Without this grounding, you can’t build credibility with engineers or shape realistic schedules. The “T” in TPM still stands for “Technical.”

6. Systems Design

Great TPMs know how systems fit together. That means understanding latency tradeoffs in web apps, how front-end patterns accelerate development, and the scheduling implications of monolithic vs. microservice architectures. This is the skill that elevates you from simply tracking work to helping teams design solutions that are technically feasible and strategically aligned.

7. Sense Making*

At Google, they called it “Googliness.” I call it the core TPM art: sense making. It’s the ability to pull together fragments of information (metrics, bug counts, shifting deadlines, hallway/zoom/slack conversations) and see the real story emerging. It’s knowing when a delay in design is still safe and when it’s catastrophic, when a high bug count is noise and when it’s a signal to escalate. Sense making is what keeps programs on track in the face of complexity.

Skills To Invest In Today

These are the muscles that will matter most in the AI-native era.

1. Context Engineering

Forget the hype about “prompt engineering.” (LONG LIVE THE KING) The real future is context engineering; it is the craft of structuring data, prompts, and workflows so that AI outputs are accurate, reliable, and useful. This isn’t just writing clever instructions. It’s about giving the model the right environment to operate in, minimizing hallucinations, and shaping consistent outcomes.

2. AI Agent Design/Understanding

Read more

Practical AI for Technical Program Managers. A series of real-world scenarios showing how TPMs can use AI tools to solve common challenges, work smarter, and 10x their impact, complete with ready-to-use prompts and actionable strategies.

Subscribe now

If you have Feedback and/or Suggestions to improve this guide, please leave a comment. Only paid subscribers who have access to the guide can leave comments.

OR reach out to me for any questions - aadilmaan at gmail.com.

My Dearest Readers - At the beginning of 2025, I made a re-commitment to my writing after almost 1 year hiatus during 2024. So far, your response has been overwhelming. I feel like 2025 and beyond is going to be both terrifying and exciting.

As we hit the official mid-point of 2025, please help fill out this feedback survey so I can continue to focus on delivering real world practical solutions, advice and insights to help you grow as a TPM.

Fill Out Feedback Survey 🙏🏽

Now, on to this week’s post…

How TPMs Can Use AI

You’re reading another post in my ongoing series, “How TPMs Can AI,” where I share real world scenarios showing how AI can make Technical Program Managers more productive and effective.

Nothing beats concrete, real-world examples. My hope is that these stories inspire you to find your own ways to leverage AI, maybe even 10x your impact, effectiveness, and focus.

How This Series Works

• I’ll start with a common challenge TPMs face.

• Then, I’ll show how AI tools can help you explore possible solutions, sometimes ones you might not have considered before.

The Scenario

You’ve launched a feature. It shipped, but the path there was rocky. Now your VP of Engineering wants you to lead a retrospective.

Or maybe you’re heading into a feature review where you need to ask for more time because of unexpected scope creep.

Or perhaps you’re facing a difficult conversation about someone’s behavior.

Or you will be facilitating an estimation workshop with a group of cross-functional engineering, product, design teams.

As TPMs, we walk into many kinds of conversations on daily basis, formal and informal. But none can feel more daunting than the ones with big audiences and high stakes.

Why so challenging? Because we often lead these meetings. There’s pressure from all sides:

• Say too little, and you lose control of the room.

• Say too much, and you risk derailing the discussion.

• Say the wrong thing, and you could damage trust.

How do you keep the meeting on track when your VP starts to digress? How do you lead if you’re naturally introverted? How do you handle tough conversations without freezing up?

Before AI

Over time, experience helps. You reflect on past situations, learn what worked, and build your own playbook.

You might try to anticipate where things could go wrong, prepare pre-reads, or ask your manager and cross-functional partners for advice. But no matter how much you plan, the first unexpected moment can throw everything off.

When you’re still junior, you might even piece together advice from blogs and articles about running effective meetings. That’s useful but often not enough to prepare for the real pressure of the room.

You always need something to calm the nerves.

After AI

Here’s where AI changes the game.

The real power of AI isn’t just access to information but it’s the ability to get coaching that’s tailored to your exact situation. With the right prompt, AI can help you prepare in a way that feels actionable and relevant to you.

Recently, I had to lead a retrospective. I’ve done plenty of these in my career, but even with experience, it helps to refresh and rethink how to approach them.

So I leaned on AI. I wrote a prompt that laid out my context and asked for strategies, facilitation tips, and sample ways to phrase things during the discussion. The output gave me not just a refresher but also new angles to consider.

And this approach isn’t limited to retrospectives. You can apply it to any big or complicated meeting like feature reviews, roadmap debates, or difficult one-on-ones.

The Prompt

Read more

Subscribe now

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

The role of a TPM has always evolved with technology, but this moment feels different. AI is not just another tool, it’s literally reshaping how we define work, success, and even leadership itself. As managers and leaders, we now face questions that don’t have easy answers. And maybe the real challenge is not in finding certainty, but in learning how to lead while the ground beneath us keeps shifting.

Like many in the TPM space, we are all watching the world shift in real time. Each week, new milestones are reached with LLMs and AI tools. These breakthroughs raise questions that cannot be brushed aside.

This is especially true for those in leadership roles such as Heads of TPM, Directors, Senior Managers, and People Managers. The expectations placed on you are no longer just about managing programs. They now include guiding your teams through the uncertainty of AI adoption.

I don’t claim to have the answers to everything. But I do have questions that stay with me as I observe how our field is evolving. These questions may not resolve today, but they are worth holding as guideposts for the path ahead.

Building a Roadmap for AI Tools and Capabilities

Senior leaders are calling for teams to “use AI every day.” But how do TPMs translate that call into something concrete? A roadmap is needed, one that balances curiosity with clarity.

When everything is new and shiny, it’s easy to fall into the trap of experimenting for the sake of experimenting. The challenge is knowing which tools actually deliver value, and which are distractions. Throwing random things on the wall may show activity, but it doesn’t create long-term progress.

Beyond engineering workflows and code generation, where else can AI tools create impact? For TPMs, the most powerful opportunities may come when these tools have access to internal data (wiki notes, issue trackers, google documents, and workflows etc). That’s where real transformation will begin.

Training Existing Staff on Modern AI Tools

Every TPM team faces the same hurdle: the steep learning curve. These tools are often not plug-and-play especially when you go beyond ChatGPT or Claude chat like tools. They require re-education, not just on how to use them, but also on the new concepts and mental models they introduce.

The reality is that training doesn’t come free. Leaders will need to find budget for tools, courses, and access. Without investment, adoption will remain shallow.

The bigger question is how to convince organizations that this isn’t optional. AI fluency is fast becoming a core competency for modern TPMs. Those who can’t use these tools effectively risk being left behind.

Creating Space and Time for Experimentation

The calendar of a TPM is already filled with back-to-back meetings. Fires to put out. Deadlines to chase. Where does the space for AI learning fit in?

If leaders expect TPMs to learn and experiment only in their personal time, adoption will suffer. Forcing people to figure this out outside of work sends the wrong message. It signals that AI exploration is a hobby, not a priority.

Creating structured time during business hours for experimentation is critical. Just like we allocate time for sprint planning or retrospectives, space must be made for exploring AI. Otherwise, it will always remain an afterthought.

Developing a Lexicon for Leadership to Discuss AI Adoption

The language of AI adoption is still immature. Measuring success by counting how many documents or lines of code were generated with AI misses the point. That is activity, not impact.

Similarly, asking why teams aren’t building AI agents when the only accessible tool is ChatGPT is not useful. Leaders must bridge the gap between aspiration and capability.

What TPMs can do is help translate the broad “CEO AI Memo” into actionable, measurable, and trackable terms. By developing a shared vocabulary, adoption can be discussed with clarity rather than confusion.

Re-examining Performance Review Criteria and Approach

AI tools will equalize output in many ways. “Good enough” work will become easier to produce. That raises a hard question: how do we know what truly meets expectations?

If so much of the work is AI-assisted, traditional metrics may not apply. Is it still about volume of output? Or does it shift to judgment, decision-making, and creativity?

And what happens when leadership wants to measure AI adoption by asking “how many AI agents did you build this year”? TPM leaders will need to guide that energy toward more productive and fair measures.

Headcount and Capacity Planning

Another uncomfortable reality is the impact on team size. When efficiency rises through AI adoption, leaders may ask: “Why do we still need this many people?”

For TPM teams, the challenge is twofold.

• First, making the case for the unique value TPMs provide beyond what AI can do.

• Second, rethinking growth strategies in a world where elementary activities can be automated.

Headcount and capacity planning will no longer be a simple function of workload. It will demand a deeper understanding of what only humans can bring to the table (think: judgment, alignment, and the human side of program leadership).

Final Words

The truth is, no one has a perfect playbook for this transition. AI is rewriting the rules as we go, and TPM leaders are being asked to navigate uncharted ground. What we can do is stay curious, create space for experimentation, and redefine success in ways that honor both human judgment and new tools.

The questions we ask today will shape the answers our teams discover tomorrow. The real measure of leadership may not be in having all the answers but in guiding others through the uncertainty with clarity and intent.

Until next time.

-Aadil

Subscribe now

If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.

Share

Velocity > Speed

Every company racing to build AI products is repeating the same mantra: speed is everything. Move fast, launch quickly, and iterate later.

But speed alone isn’t enough. What really wins is velocity; the equation for velocity in my mind is speed plus direction, intent, and clarity.

After observing the industry, helping build AI products myself for the past few years, I have come to the conclusion that companies that want to win at the AI Race need to excel at two critical practices:

1. Running a robust beta testing program before launch

2. Committing to red-teaming and penetration testing as non-negotiable

If you’re a TPM tasked with planning the next AI product launch, these two phases need to sit firmly on your critical path. Treat them either as phases or milestones but do not skip them.

Why this matters

In traditional software launches, manual regression testing and automation were enough. Beta testing was optional. Red-teaming? Too costly or time-consuming or sometimes not considered necessary.

AI changes that.

A single failure isn’t just a bug, it’s a trust breaker. Hallucinations, unsafe responses, exploitable vulnerabilities… all of these can erode confidence in your product and brand.

That’s why beta testing and red-teaming aren’t “nice to haves” anymore. They’re essentials.

Beta testing: your first line of truth

Beta testing provides real-world feedback that labs and internal QA can’t replicate. For AI products, it answers three key questions:

Read more