Things I've learned in my 10 years as an engineering manager

The role of an engineering manager is never static; it is shaped by the team's immediate bottleneck and expressed through four pillars: product, process, people, and programming. Large teams pull you into career coaching, resource navigation and cross-functional coordination, while small teams let you stay hands-on with code and scope. When there is no product manager you become the product owner, and reporting to the CEO turns you into the bridge to sales and operations. The constant is the need to identify where the workflow stalls and to move your effort accordingly.

Process rituals can become self-fulfilling obligations that drown out outcomes. A single broken UI can spawn endless approvals, turning a quick fix into a permanent gate. Good process should serve customers, not own the team. Managers must constantly ask whether a ceremony still adds value or simply consumes time. Trust is the other linchpin: withholding information or micromanaging erodes morale, while transparent communication and genuine praise keep engineers engaged. Delegating recurring tasks, teaching others to own them, and avoiding the "bus factor of 1" prevents you from becoming the single point of failure.

Hiring decisions illustrate how risk-aversion can cripple speed. Over-screening, adding interviewers, and demanding referrals create bottlenecks that let top talent slip away. Instead, focus on a lean interview loop, recognize second-order effects, and treat each hire as a strategic investment in the team's capacity. By staying clear on where your effort adds the most leverage-coaching, removing blockers, and protecting the team from unnecessary stress-you keep the organization moving without becoming its own obstacle.