Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Defined His Engineering Levels With a Rubric
Transcript
- Lucas: So there's this CTO at a SaaS company — about 150 engineers — who got fed up with promotion politics. Every six months, the same pattern: managers arguing for their reports, no consistent criteria, and the loudest advocates won. Luna: Sounds like every company I've ever worked at. Lucas: Right. So he did something surprisingly simple. He wrote down a public rubric defining every engineering level — from intern to principal — using just four dimensions. Luna: Okay, four dimensions — what were they? Lucas: Scope, complexity, autonomy, and impact. For each level, from L1 to L6, he defined what each dimension looks like in practice. Not abstract adjectives — specific behaviors. For example, an L3 engineer — mid-level — has 'scope: a single feature or small subsystem,' 'complexity: known patterns, some debugging,' 'autonomy: works independently on well-defined tasks,' 'impact: contributes to team goals.' Luna: And that replaced the old system of 'senior whatever' and 'just got promoted because they've been here three years'? Lucas: Exactly. He shared the whole thing publicly — it's on his blog — and the results are striking. In the first year, promotion-related disputes dropped by about 70 percent. Managers had a shared language. Engineers could map their own growth. Luna: Seventy percent is huge. But I wonder — does that kind of rigid rubric ever box people in? What about the engineer who's incredible at debugging but can't design a system at scale? Does the rubric penalize them? Lucas: That's the smart question. He handles it by weighting — not every dimension is equal at every level. At lower levels, autonomy and complexity matter more. At higher levels, scope and impact dominate. So a great debugger can still progress by showing broader impact, even if their scope stays narrow. Luna: So it's more of a profile than a checklist. Lucas: Exactly. He said the hardest part wasn't writing the rubric — it was getting managers to stop promoting based on tenure or likability. The rubric forced them to write evidence against those four dimensions. And if you couldn't give a concrete example of, say, increased scope over the last cycle, the promotion didn't happen. Luna: That sounds like it creates a paper trail. But also a lot of work for managers. Lucas: It does. But he argues it's less work than the old system — because the old system generated endless back and forth with HR and skipped-level meetings. Now, the rubric does most of the filtering. A manager either has the evidence or they don't. Luna: And what about engineers who are on the fence? Say someone meets three of the four dimensions but not the fourth — do they get promoted? Lucas: He says that's where the calibration committee comes in. A group of senior engineers and managers reviews borderline cases. But the rubric gives them a starting point, not a binary pass-fail. They discuss whether the gap in one dimension is offset by exceptional performance in another. Luna: I like that it's not purely mechanical. There's still judgment, but it's anchored. Lucas: And the anchor is public. Every engineer in the company can read the rubric and see what they need to do to reach the next level. That transparency alone, he says, changed the culture. People stopped gaming the system and started focusing on the work that actually mattered for growth. Luna: Do you think this scales to larger companies? Like a thousand engineers? Lucas: He thinks so, with some tweaks. The rubric itself scales fine — you just need more levels or more nuance. What gets harder is the calibration process. At his scale, one committee works. At a thousand engineers, you'd need multiple committees, and ensuring consistency across them becomes a challenge. Luna: Right. So the tool scales, but the governance doesn't necessarily. Lucas: Yeah. And that's actually where a lot of companies screw up. They copy a rubric from a blog post — maybe Google's or Spotify's — but they don't build the decision-making process around it. The rubric becomes a decoration, and promotions stay political. Luna: So what's the minimum viable version for a team that wants to try this? Say a startup with twenty engineers. Lucas: Start with just two dimensions: scope and impact. Define what those mean at three or four levels. Write one example behavior per level. That's it. Put it on a single page. Then use it in the next promotion cycle as a discussion guide, not a rulebook. Luna: Two dimensions, one page — feels doable. Lucas: And iterate. The CTO we're talking about took three cycles to get the rubric right. He adjusted the language, added the complexity and autonomy dimensions later, and kept refining. The key was just starting with something concrete. Luna: You know, it's funny — we talk about engineering metrics, architecture, team topologies, but the thing that actually determines whether people stay or leave is often this: can I see a path forward? A rubric makes that path visible. Lucas: Absolutely. And it's one of those things that costs almost nothing to build but returns huge dividends in retention and fairness. Luna: Before we go deeper — and this is totally unrelated but actually kind of related — conversations like this one are why listener support matters so much to us. We keep the show ad-free because we want to talk about real practices, not sponsored trends. Lucas: Yeah, and a couple of dollars a month from listeners who find these episodes useful genuinely makes that possible. It's at buy me a coffee dot com slash fexingo — if you've gotten something out of the show, that's the best way to keep it going. Luna: And it really does add up. We hear from people who say they use these ideas in their standups or their planning sessions — that's exactly why we do this. Lucas: So back to the rubric — one thing I found really smart was how he tied each level to the company's strategic goals. An L4 engineer's impact dimension wasn't just 'helps the team' — it was 'influences the quarterly roadmap.' Luna: That directly links individual growth to company direction. Feels like it prevents the 'I did my tickets, promote me' mindset. Lucas: Exactly. And it gives senior engineers a reason to care about strategy, not just code. The rubric pushes them to engage with product decisions, with architecture trade-offs, with mentoring — because those are the behaviors that define the next level. Luna: I'm curious — did he share any pushback from the team? I imagine some people felt threatened by the new transparency. Lucas: He said the biggest pushback came from managers who had been using 'vibes-based' promotions for years. Suddenly they had to produce evidence. A few of them left — which he sees as a positive filter. Engineers, by and large, loved it. They finally knew what 'senior' actually meant. Luna: So it also becomes a management litmus test. Lucas: Yeah. If a manager can't articulate why someone is ready for promotion against clear criteria, they probably shouldn't be managing that person's career. Luna: Alright, so for someone listening who wants to build a rubric this week — what's the first step? Lucas: Grab a blank page. List your current engineering levels — even if they're just 'junior, mid, senior.' For each level, write one sentence about what someone at that level should be able to do independently. That's your first draft. Then share it with three engineers and ask: does this match your experience? You'll get your first round of feedback in an hour. Luna: I like that it's low ceremony. No tooling, no committee, no six-month rollout. Lucas: Exactly. And within a few cycles, you'll have something that actually works for your team. The CTO we talked about says his rubric now drives not just promotions but also project assignments and mentorship matching. Luna: It becomes a central operating document. Not bad for something that started on a single page. Lucas: That's the thing about good engineering leadership — it's often about making the implicit explicit. A rubric is just that: take what everyone already knows but never says, and put it on paper. Luna: Alright, I'm going to try this with my own team. Two dimensions, one page, start today. Lucas: Let me know how it goes. We can do a follow-up if you get traction. Luna: Deal.