u/Advanced_Abalone8530

How do experienced TPMs operate effectively in high-ambiguity, low-process environments without burning out?

Before becoming a TPM, my background was in project/program management, ops, process improvement, analytics, process standardization, etc. I’ve been in TPM roles for about two years now.

I switched depts and the software is similar to products I’ve supported before, but the subject matter and workflows have been a learning curve, especially because the environment is extremely meeting-heavy (avg. of 10+/day and 55/week) and reactive. There’s very little focus time to actually absorb context deeply and I’m already working 55-60 hours/week. Add ADHD to the mix too while we’re at it. 🤯 I’m already burnt out. Job-hunting would add to the fire, but also, the job market is not great right now…

A lot of my instinct has been to create structure, improve intake quality, standardize processes, consolidate sources of truth, and reduce chaos. I’m struggling to find the line between “valuable ops/process improvement” vs. “over-engineering” in a fast-moving TPM environment.

For experienced TPMs in highly ambiguous orgs:
How do you balance delivery vs. process improvement?
How do you avoid burnout from nonstop context switching?
And how do you develop deep knowledge when the environment itself is fragmented and reactive?

Thank you for helping me survive, nerds of Reddit. 🫡

reddit.com
u/Advanced_Abalone8530 — 8 days ago