I've been tinkering with my CV endlessly over the last six months. It started with a decision that I needed a new chapter. And then what followed was a frustratingly slow but necessary process of figuring out exactly what I wanted that new chapter to be. It took time to figure out exactly where I was in my career, what kind of engineer I was, what I enjoyed doing, what I was good at, where I wanted to develop, what kind of challenges I was interested in, what kind of companies I wanted to work for, what kind of teams I wanted to work in, what kind of domains I wanted to work in.
These are not easy questions. Some of them I had answers for; I just didn't realise it until I asked the questions. Some answers took time to reveal themselves. And as I was able to answer more and more questions, my application volume dropped. Today, I have a very specific job profile that I'm looking for, and more confidence than ever that my next role will be where I do the best work of my life, so far.
This evolution lives in the version history of my CV. I think that's natural, because the CV is meant to capture my professional identity in a single document. It's natural to have been applying for roles as I was figuring out what I was looking for, and the CV is something I could keep coming back to. It was a routine process of refining my mental model of who I was and what I wanted, and then comparing that against my CV to see how well it continued to reflect that. As I evolved, so did the CV.
But once I reached the point of clarity and confidence, I realised that I was still tinkering. I was still making small tweaks here and there, as I kept revisiting specific wording, whether I was emphasising the right things, whether my CV was easily "scannable", whether it gave the recruiter or the hiring manager enough gradual substance to keep reading. And I think that tinkering will go on forever if I let it, because while the CV may be a great tool for capturing my experience at a high level, it's never going to be very good at conveying nuance.
I think my engineering profile is difficult to communicate in a conventional CV. And I spend a lot of time thinking about how to overcome that. I also spent time thinking about what it must be like for recruiters and hiring managers, sifting through piles of identical CVs, trying to find the right candidates to strengthen their team. And I'm not convinced that the CV is a great model for answering that question specifically: "Will this person strengthen my team?" The CV is very one-dimensional. It's not optimised to communicate the context or the depth of someone's experience with a skill. It doesn't tell you if they're pushing themselves, or in what direction. It doesn't tell you the kind of work that excites them, or where their personal competitive advantage lies.
When I put myself in the shoes of the hiring manager reviewing my CV, I imagine there are three questions my application needs to answer for them:
- Do I have the capabilities to start contributing value today?
- Does the work the role requires align with how I want to develop?
- How might I offer outsized value over time?
Delivering Value Today
This is the question a traditional CV probably comes closest to answering. My CV is structured into the following sections:
- Profile: a high-level overview of the type of engineer I am and the type of role I'm looking for.
- Selected Impact: a selection of outcome-led bullets that surface my strongest evidence of delivering business impact.
- Technical Skills: a map of hard and soft skills that I possess and technologies that I'm familiar with.
- Experience: my relevant commercial experience and details about the types of projects I've worked on.
- Current Projects: a selection of personal projects that I'm currently working on to experiment and develop myself outside of commercial work.
- Education: a bootcamp. I'm a late bloomer with a previous life.
The skills and experience sections are probably the most relevant for this question, and between them a hiring manager can reason about what I'm capable of. But it's low resolution. If they wanted to understand how substantial my experience with a particular skill was, they would have to pick that skill and then read through my experience looking for evidence. And at best, they would be interpreting based on whatever information I decided to provide. If I haven't explicitly surfaced evidence for that skill, or haven't done it convincingly, that skill is just words on a page.
Development Alignment
I've had the privilege of working with some great servant leaders. One of the pillars of this style of leadership is creating an environment that supports you to develop yourself. Servant leaders encourage introspection and enable self-development by looking for opportunities to get you working on the things that you enjoy and in areas you want to grow. So it stands to reason that a hiring manager would be assessing this during recruitment. The question I need my application to answer is: "Are the things that I enjoy, the things that I'm good at and, crucially, the areas where I'm looking to develop well aligned with the role, its requirements and the opportunities that will become available as the product grows?"
I think that traditional CVs struggle with this, partly because of the recruitment process itself. The CV is a model of your professional identity, and its purpose is to convey your strengths. It tends to present every skill in the same flat way, with very little room to distinguish established practice from active development. And for good reason - you're being screened against other candidates. If your CV tells a recruiter that you're developing a certain skill, and another candidate claims strong proficiency, which candidate will the recruiter prefer? Especially in the early stages, before a hiring manager has gotten involved, how much nuance is there in the screening materials? Are required skills qualified with information about where strong proficiency is genuinely required vs where emerging capability and a strong interest would be just as good?
Outsized Value
I've only seen this language used in one place, but I have a hard time imagining any hiring managers not thinking about it. The best comparison I can think of is elite-level players in sports. In professional sports, success is determined by fine margins. Clubs want to recruit players who are difference-makers. I think this is a useful way to think about recruitment, from either side. For myself, I'm constantly thinking about what makes me unique: "What specific combination of my skills becomes more than the sum of their parts?" This won't include every skill I possess. There are lots of skills that I consider core competencies for any product engineer, but that aren't necessarily where I see my true value.
This also echoes the question from the beginning that I imagine hiring managers are asking: "Will this person strengthen my team?" I think one way that CVs attempt to answer this question is around impact framing. Recruiters and hiring managers look for evidence of the business impact you have already delivered, as a sort of proxy for what kind of impact you can be expected to deliver for them. I understand the reasoning behind this, but I think it's flawed.
I think that impact framing is evidence that you can articulate your impact, and that you think in terms of impact. But I think it's incomplete evidence of how you created that impact, and whether the same judgement would transfer into a different environment. Outcome-focused work is also shaped by the environment around you: the product culture, access to users, instrumentation, decision-making structures and the people you work with. Strong impact evidence can show that you've operated effectively within those conditions, but it doesn't necessarily tell a hiring manager which parts of the outcome came from your own judgement.
I think a much better indicator for what an engineer would give you is understanding how they think. That's one of the reasons I write and publish articles like this one, so prospective managers and colleagues can have a window into my thought process. But none of that really comes through in a CV. CVs are professional marketing materials. They're polish. They're for you to position yourself as a solution to an immediate problem. They're not optimised to communicate your potential long-term value.
Introducing: The Engineering Capability Profile
So what's the solution? Well, I spent a lot of time thinking about different ways to visualise my skills. My first instinct was inspired by sports: the spider graph. I thought about plotting my skills as points around an outer web, with an inner web representing proficiency, or an inner web representing my current focus and interest for each. But I didn't like the implication that I was "weak" or "disinterested" in certain areas.
I needed something that represented my skills across different spectrums of context. And crucially, I didn't want it to be ambiguous. I didn't want a hiring manager to have to do more work to understand what I offer. I wanted to present my skills in an inspectable way, with a simple interface that was also intuitive and flexible, that let someone view them in different contexts and dig deeper where necessary.
What I came up with was the Engineering Capability Profile. It groups my skills vertically, similarly to how my CV does, but it also adds context.
In the default view, each skill is tagged with the type of evidence that supports it (commercial ownership, commercial exposure or applied), where that skill lives inside my current development trajectory (maintaining, deepening or learning), and whether I see it as a core competency or an area of strategic leverage.
The three context views — evidence basis, development trajectory and leverage profile — regroup the same skills around one of those dimensions. Each skill can also be opened to inspect how I define it, the evidence behind it, how I'm developing it and why I classify it the way I do.
This capability profile tells hiring managers significantly more than my CV does, even at a glance:
Distributed systems
Commercial exposure / Learning / Core competency
This says that I've worked with distributed systems commercially without owning them directly, that I'm actively building the mental model needed to take on more responsibility, and that I see distributed-systems knowledge as an important baseline capability rather than a major source of my long-term differentiation.
Domain modelling
Commercial ownership / Deepening / Strategic leverage
This says that I've owned domain-modelling decisions commercially, that I'm deliberately making that practice more rigorous and systematic, and that I see it as a meaningful part of how I could create outsized value over time.
Back to the Three Questions
So let's revisit the three questions I posed before:
Do I have the capabilities to start contributing value today?
The capability profile communicates my skills alongside their context. If the role requires someone with deep technical experience with distributed systems, who can come in and take ownership of them, I'm probably not the right fit. That isn’t a weakness in the profile; it’s an honest answer to the question.
Does the work the role requires align with how I want to develop?
Alternatively, if the role requires someone who is actively developing their distributed-systems capability and will have room to grow into greater ownership, the role could be a strong fit.
How might I offer outsized value over time?
If the role and the wider product engineering culture heavily emphasise domain modelling, this could be an exceptional fit. I have meaningful commercial experience; I'm actively working on deepening my knowledge and capability; and crucially, domain modelling is a key part of how I see myself contributing outsized value long term.
