Score Your Devex Problems Like a Product Team, and Have Career Conversations That Actually Matter
Published on 08.06.2026
Map and Score Your Devex Problems
TLDR: Most teams run structured discovery for customer problems but apply zero of that rigor to developer experience. Luca Rossi argues you should map devex friction points, score them by reach and impact, and then attack the single true bottleneck.
Summary: I've watched teams spend months doing customer journey mapping, user story workshops, and JTBD interviews, then turn around and handle developer experience complaints with a Slack thread and good intentions. The asymmetry is embarrassing when you say it out loud. Luca names it plainly: we have a methodology for product problems, and we just don't apply it internally.
The proposed approach is familiar territory if you've done any product work. You start with a listening tour, collect stories where friction actually hurt people, then group those stories into named friction points and map them against the steps of your real development process. A story map works here, but so does a spreadsheet. The artifact matters less than the act of forcing structure onto what's usually a pile of vague complaints.
Scoring comes next, and this is where the advice gets genuinely useful. Luca uses only two axes: reach, meaning how many engineers are affected, and impact, meaning how much disruption it actually causes. He drops confidence (hard to measure honestly) and effort (because you're scoring problems, not solutions yet). Simple scores, low to high, force you to have the argument explicitly instead of carrying it around implicitly in everyone's head.
The conclusion is that you then hunt for the one true bottleneck: the highest reach, highest impact problem that is blocking everything else before you even get to the others. Most devex initiatives fail because they try to fix fifteen things at once and finish none of them. Picking one and finishing it builds credibility for the next round.
What Luca doesn't dig into, and I think is worth naming, is who owns this work. Without a clear owner, the scoring exercise becomes a nice artifact that lives in a Notion page nobody opens. The methodology only works if someone has both the mandate and the capacity to act on the output.
Key takeaways:
- Map devex friction points to actual steps in your dev process, not just a vague list of complaints
- Score problems by reach and impact only, skip confidence and effort at this stage
- Find the one highest-reach highest-impact bottleneck and fix it completely before moving on
Why do I care: As someone who spends time thinking about developer tooling and build pipelines, the gap between how carefully teams instrument user-facing performance and how casually they treat slow CI or painful local setup has always frustrated me. This framing gives you a way to make the internal case with the same language product teams already respect.
Mapping devex, planning careers, and weekly readings!
Career Direction Starts With Why
TLDR: Generic career conversations produce generic outcomes. Luca argues that meaningful career growth discussions start with understanding what actually energizes an engineer, not what title they want in three years.
Summary: Early in my career, nobody asked me where I wanted to go. I got tasks, I shipped them, I got a slightly different title every couple of years. That wasn't malicious, it was just the default mode. Luca describes the same experience, and then makes the point that engineering managers today are expected to do meaningfully better, even though many still default to the same hollow annual review format.
The shift he proposes is moving from outcome questions to motivation questions. "What role do you want in three years" gets you a rehearsed answer, usually something the engineer thinks sounds ambitious rather than something that reflects how they actually feel about work. Questions like "what recent project made you feel most alive" or "what parts of your job feel like a chore" get you real information to work with.
I find this framing convincing because it changes the manager's job from career planner to career translator. You're not designing a path for someone, you're helping them articulate what they already feel but haven't put language around yet. That's a meaningfully different and more honest role.
The gap between "I want to become a staff engineer" and "I want to work on impactful technical projects with a lot of autonomy and minimal process overhead" is the gap between a label and a set of actual preferences you can act on. Once you have the preferences, you can match projects, protect time, and advocate in a way that's concrete. Without them, you're just managing toward a job title.
What I'd add is that this works both ways. These conversations reveal a lot about whether the work available at your company actually matches what someone needs. Sometimes the honest answer to the question is that this particular engineer needs to be somewhere else. That's a harder conversation, but it's a more respectful one than pretending a title change will fix a misalignment.
Key takeaways:
- Ask what kind of work energizes people, not just what role they want
- The goal is moving from a generic target to a specific set of preferences you can act on
- Motivation questions reveal information that outcome questions never surface
Why do I care: I've been on both sides of bad career conversations, and the thing that made them bad was always the same: they were about the org chart, not about the work. Any manager who can run this kind of conversation well is doing something that actually builds retention and performance, not just checking a box on a review cycle.