2 min · May 30, 2026

A title is a label. A competency matrix is a map.

One of the first foundational things I did as Head of Engineering was to critically think through how to spot great hires when we needed them and what life as an engineer would look like as the years wear on. Here's what I did: I defined, for every level of engineer we have, what that person is actually expected to know and to do. Not the title. The substance behind the title.

Because a title on its own is just a label. "Senior Engineer" means something different at every company, and often something different to two people in the same company. That ambiguity is where a lot of quiet dysfunction lives: a senior who doesn't know what's expected of seniority, a manager who can't say clearly why someone isn't ready for the next level, an engineer who wants to grow but has no map of what growing even means here. Everyone's working off a vibe.

So I replaced the vibe with a matrix. Each level, from the most junior all the way up to my own, has a defined set of competencies across the things that actually matter in our work: code quality, testing, design, security, delivery, the human skills and now AI-assisted development too. A title isn't a reward you're handed. It's a description of competencies you can already demonstrate. The matrix turns "you're a senior now" into "here is the specific ground a senior stands on, and here is the ground you'd need to cover next."

This isn't my invention. The practice is well-trodden in engineering leadership. Camille Fournier's career ladder work and her book The Manager's Path are the usual starting point, and there are good public examples collected at progression.fyi if you want to see how other companies have done it. I read around, watched, borrowed, and then built ours to fit Hubtel rather than copy someone else's.

But here's the part I care about most, the part that made it more than an HR artifact: I wired it into how we hire. The same competencies the matrix expects became the things we actually test for at the door. The interview isn't a vibe check either. It maps to the map. So the question we're really asking a candidate isn't "do we like them," it's "where do they currently sit on the matrix, and is that the level we're hiring for." Hiring, leveling and growth all point at the same definition of good. They stop being three separate conversations and become one.

What surprised me was the effect on fairness. When the standard is written down and shared, growth stops being political. People can see the ground ahead of them. A promotion conversation becomes "you've demonstrated these, here's what's left," not a negotiation about who advocated hardest for whom. The matrix does for careers what good standards do for code: it removes the ambiguity that ego rushes in to fill.

A title tells people what to call you. A competency matrix tells them what to expect from you and tells you how to get to the next thing. One is a label. The other is a map. As a leader, I'd rather hand my people a map.

Don't promote people into titles and hope they grow into them. Define what each level actually means, hire against it and let everyone see the map. Clarity is the kindest thing you can give an ambitious person.

Go deeper → progression.fyi — public engineering career frameworks

← All dropsNext drop → Work charts beat org charts.