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

Things I’ve learned in my 10 years as an engineering managerNon-obvious advice that I wish I learned sooner. Jampa Uchoa Jan 16, 2026 It’s been a while since my boss told me I needed to start hiring for my team. While I was at it, I should also handle onboarding... Since I knew the roadmap, I could take ownership of that... And because I knew the people, I could coach them in their careers. I didn’t realize at the time, but he was dooming me to be an engineering manager. Since then, I’ve worked across four companies as a manager, one as a founder, and another as a manager of managers. I will skip the standard advice and lessons on Engineering Management and focus on the non-obvious ones.1. The “well-defined engineering manager role” is a myth There is no standard definition for an Engineering Manager. If you pick two random managers, they can do very different things, even if they are at the same company. In every company I’ve worked at, my role has never been the same. The only constant is that it’s defined by the team's needs, requiring you to balance across four pillars: Product, Process, People, and Programming. Some examples: Large team? Say goodbye to programming. You’ll focus on building careers, coordinating efforts, and navigating the organization to get resources for your team. Small team? You’ll manage scope to match reality, and with less communication overhead, you might actually do some coding. No PM? You own the product completely: validating features, prioritizing the roadmap, and talking to clients. This takes up most of your time because shipping features that don’t offer user value makes everything else pointless. Reporting to the CEO? You’re now the link to sales, operations, and client communications. The key is to identify where your team’s bottleneck lies in your software development lifecycle. You’ll probably shift between pillars as circumstances change, and that’s the point: the role requires flexibility. Tip: Never ask the interviewer what they expect from a manager. Some managers assume their experience is industry standard and might find that question odd. Instead, ask about their daily life and the challenges that take up most of their time.2. Everyone needs to care about the Product A few times in my career as a developer, I wondered, “Who is this feature even for? Who will use it?” No one on my team knew. We were doing it because we were told to. Morale was low. We felt we were working on things that didn’t matter - and we were. Eventually, our team disbanded, and engineers scattered across other projects. The most common reason companies fail is creating products that don’t deliver value to users, causing them not to pay. “Oh, but I have a PM for that,” you might say. But having a PM is not enough. Everyone needs to care about the product. Your team isn’t paid to just deliver code but to use it to solve problems. Code is valuable only when it benefits the end user. Sometimes, a no-code integration can outperform a custom solution. At times, it's better not to create a new feature at all to avoid maintaining a system. Teams that understand the problem, not just the spec, can pivot when necessary.3. There is no such thing as a free lunch when it comes to processes Every process trades time and attention for reliability or quality. The problem occurs when teams stop questioning if the trade is still worth it. Ceremonies become rituals. Metrics turn into goals. No one remembers why we spend an hour of our lives on this meeting. Process bloat creeps in slowly. An engineer ships a broken UI to production. Designers complain, managers panic, and suddenly every PR requires designer approval. The whole team bears the cost of a single isolated incident. Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. You stop looking at outcomes and just make sure you’re doing the process right. The process is not the thing. It's always worth asking, do we own the process or does the process own us? — Jeff Bezos, 2016 Letter to Shareholders The right process varies based on context: team size, experience levels, and deadline pressure. What works for a mature team might not work for a new one. Keep questioning and iterating. If a process isn’t improving delivery, cut it.4. Communicating downward requires transparency Your direct reports are the people who interact with you the most. They look to you for leadership and clarity, and trust that you’ll tell them what they need to know. That’s why lying or withholding information that affects them causes irreversible damage. They might not leave immediately, but they will resent you. I have a friend who still resents a manager for a lie told three years ago. They found another company, but they’re still angry about it. “Trust arrives on foot and leaves by horseback.” - Old Dutch saying I've seen some managers describe the role as “a shield that blocks everything from above,” and I disagree. A good manager is more like a transparent umbrella. They protect the team from unnecessary stress and pressure, but don’t hide reality from them. Telling the team: “Our users aren’t thrilled so far. We need to find ways to better serve them. The project risks cancellation if we don’t.” That’s fair game. They deserve to know. When you do deliver hard news, state it clearly and focus on how the team will do about it. If you act scared, they’ll be scared too. Your goal is to get them thinking about the next steps.5. Communicating up requires a strategy I see managers walk into executive meetings saying, “We’re not sure what to do - maybe A, maybe B?” and then leave with orders to do Z, which doesn’t benefit the team or the project. Executives can’t think of every possibility in detail - that responsibility lies with you and the person who owns the product (which, as we saw, could be you too). When a problem reaches the executives, it’s because a decision is needed, and...