Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How to Build an Engineering Ladder That Actually Works
Transcript
- Lucas: Luna, I want to start with something that bugs me. I see so many companies — well-funded, smart teams — copy-paste an engineering career ladder from a blog post, stick it in a Notion doc, and call it a day. Luna: Oh, the classic 'Levels FYI' approach. I've been guilty of that myself. Lucas: Exactly. And the problem is, a generic ladder doesn't reflect your company's actual work. So you end up with people gaming the system — or worse, leaving because they don't see a real path. Luna: So what does a good ladder look like? Give me a concrete example. Lucas: I worked with a Series B startup last year. Thirty engineers, mostly full-stack and data. They had a ladder with five levels — but the only criteria were vague phrases like 'demonstrates leadership' and 'technical excellence.' No one knew what that meant. Luna: So promotions were basically a popularity contest. Lucas: Worse — they were based on tenure. The senior engineer who had been there three years got promoted over the mid-level who shipped three major features. That person quit. And then two more followed. Luna: Ouch. So what did you build instead? Lucas: We designed a ladder around four dimensions: technical scope, ownership, mentorship, and impact. Each dimension had three to four concrete descriptors per level. For example, technical scope at Level 3 meant 'works independently on a well-defined component.' At Level 4, it meant 'defines the architecture for a new service.' Luna: That sounds a lot more objective. But how do you handle the fact that a frontend engineer and a backend engineer might have very different paths to those? Lucas: That's the tension. You can't have a one-size-fits-all descriptor for every role. So we introduced role-specific examples alongside the generic criteria. For frontend, 'ownership' might mean owning the design system. For backend, it could mean owning a data pipeline. Same dimension, different evidence. Luna: Did you tie it to projects? I've seen ladders that just live in a doc and never get referenced. Lucas: We did. Every quarter, each engineer wrote a one-page impact summary mapping their work to the four dimensions. Then their manager used that in the promotion discussion. No more 'Bob is a great guy' arguments. Luna: What about the staff-plus level? That's become a whole thing in the industry. Lucas: Right. The staff-plus conversation is huge. For this company, we capped at what they called 'Senior' — equivalent to L5 or L6 at a larger company. They weren't ready for a staff track because they didn't have enough engineers to mentor or enough cross-team projects. We advised them to revisit once they hit 80 engineers. Luna: That's smart. Don't build a ladder for a company you're not yet. Lucas: Exactly. And by keeping it lightweight, they actually used it. Within six months, they had their first transparent promotion cycle. Two people moved up, and — this is the key — no one was surprised. Luna: Because the criteria were clear and the evidence was accumulated over time. Lucas: Yeah. And the engineers who didn't get promoted knew exactly what they needed to work on. That's the whole point. Luna: I think a lot of leaders are afraid to make the ladder too specific because they worry it'll be too rigid. But you're saying clarity beats flexibility. Lucas: Absolutely. A vague ladder isn't flexible — it's just confusing. People want to know: 'What does it take to get from Level 3 to Level 4?' If the answer is 'it depends,' you've lost them. Luna: Let's talk about the mentorship dimension. How do you measure that without making it feel like a checkbox? Lucas: We kept it simple: number of junior engineers formally assigned, plus a short survey from each mentee. Not about popularity — about whether they improved. Did the junior ship a feature faster? Did they unblock themselves more often? That's the data. Luna: And the impact dimension — that's the one companies usually mess up because they equate impact with hours worked. Lucas: Right. Impact is not effort. We defined it as 'measurable change to a business or technical metric.' If you spent 80 hours refactoring a module but no one noticed, that's not impact. If you spent 10 hours automating a deployment that saves the team 30 hours a month, that is. Luna: So you're measuring output, not input. Lucas: Exactly. And that shift alone changed the culture. People stopped bragging about late nights and started asking: 'What did we actually ship?' Luna: If today's conversation gave you something usable, I'll just mention that the way we keep Tech Leadership ad-free is through listener support. If you found this useful, you can buy us a coffee at buy me a coffee dot com slash fexingo. Lucas: And it genuinely helps. We don't run ads, so it's listeners like you who keep the lights on. All right — back to the ladder. One thing we haven't talked about is how to handle the transition from IC to manager. Luna: That's a whole episode. But briefly, in this ladder, did you have a separate management track? Lucas: We did. At Level 4 and above, you could choose between IC and manager. Same base pay, same level title — just different expectations. The manager track emphasized people development and process improvement. The IC track emphasized deep technical leadership. Luna: And you made sure that switching tracks wasn't seen as a demotion. Lucas: Critical. We had a senior engineer who tried management for six months and hated it. He switched back to IC and was promoted the next cycle. No stigma. In fact, we celebrated it. Luna: That's the kind of culture that retains people long-term. Lucas: Yeah. And it all starts with a ladder that actually reflects the work. Not a copy-paste job.