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

Speaker 1: Up next, we have a piece by Jampa Uchoa reflecting on a decade as an engineering manager, and it moves past the usual clichés to offer some really grounded advice. It’s a deep dive into how the role actually functions in the real world versus how it’s described in job postings.

Speaker 2: Ten years is a lifetime in the tech world. Did anything specific stand out to you as a central theme in his experience?

Speaker 1: The biggest takeaway is that the well-defined manager role is actually a myth. He describes it as a constant balancing act between four pillars: product, process, people, and programming.

Speaker 2: That sounds like a lot to juggle at once. Does the focus shift depending on the size of the company or the team?

Speaker 1: Definitely. If you are at a small startup with no product manager, you might spend all your time on the product side, but in a large company, you are mostly navigating the organization to get resources.

Speaker 2: It is interesting that he emphasizes the product so much. Usually, people think managers just focus on the people or the schedule.

Speaker 1: He argues that if the team does not understand the why behind the code, morale just tanks. It is like building a high-tech bridge to nowhere; it does not matter how good the engineering is if no one actually needs to cross that river.

Speaker 2: I love that analogy. What did he have to say about the actual day-to-day management of the people on the team?

Speaker 1: He uses this great term: the transparent umbrella. You protect your team from unnecessary corporate pressure, but you do not lie to them about the reality of the situation.

Speaker 2: So you are not acting as a brick wall, you are more like a filter for the noise.

Speaker 1: Exactly. And he suggests a surprising breakdown of your time: sixty percent cheerleader, thirty percent coach, and only ten percent player.

Speaker 2: Only ten percent coding? That must be a difficult transition for people who were previously senior engineers.

Speaker 1: It is, but he warns that if a manager stays on the critical path for code, they become a bottleneck. The ultimate goal is actually to make yourself redundant so the team can thrive even if you take a month off.

Speaker 2: It is almost like you are building a self-sustaining ecosystem rather than just directing traffic.

Speaker 1: That is a perfect way to put it. He also mentions that while you should trust your team, you still need to verify through qualitative insights, not just raw metrics.

Speaker 2: Because a spreadsheet cannot tell you who is quietly helping everyone else solve problems on Slack.

Speaker 1: Exactly. It is a very human-centric approach to a very technical job.