January 26, 2026
Finally, a good boss?
Things I've learned in my 10 years as an engineering manager
The Boss Who Actually Gets It—Engineers Clap, Meeting Culture Cringes
TLDR: A seasoned manager says there’s no one job description—good managers flex between people, product, process, and code to serve users. The crowd cheers, slams meeting bloat, and argues whether managers should shield engineers from client work or involve them, spotlighting a craving for product-first, drama-free leadership.
Veteran engineering manager Jampa Uchoa dropped non-obvious wisdom: there’s no fixed manager role, just shifting between product, process, people, and programming to unblock the team. He says everyone must care about the product—code only matters if users benefit—and warns that rituals and metrics can bloat into costly process theater.
The comments exploded with engineers calling him a “unicorn boss.” One praised the mantra that a great manager makes the team thrive without them; another simply sighed, “good manager sightings are rare.” But the spiciest thread came from a dev venting they were browbeaten into client work “for ~free~ growth” while “PMs play video games between calls,” sparking a split: should managers shield engineers from meetings, or push them to talk to real users?
Memes flew—“meeting bingo,” “alt‑tab to demo,” “clownshow”—as folks dunked on status updates that don’t move the product. Others backed Jampa’s flexible approach: big teams mean less coding and more coaching; small teams can still ship and talk to customers. Across the drama, the mood was clear: fewer rituals, more user value, and managers who make themselves almost invisible by building self-steering teams. And yes, someone claimed point 9 was spot on—whatever it was, in this circus.
Key Points
- •The engineering manager role lacks a standard definition and shifts based on team needs across Product, Process, People, and Programming.
- •Team context (size, presence of PM, reporting line) changes EM focus—from coding to career development, product ownership, or cross-functional liaison work.
- •Everyone on the team should care about the product and user value; relying solely on a PM is insufficient.
- •Code is valuable only when it benefits end users; sometimes no-code solutions or not building a feature are better choices.
- •Processes incur time/attention trade-offs and can bloat; teams should regularly reassess process value to avoid ritualized overhead.