You are reading a free post from my newsletter — The Art of Doing Technical Program Management. I write with an aim to demystify the art of technical program management and deliver proven real-world strategies, practical advise and tips, and actionable frameworks to help you level up as a Technical Program Manager.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.