The Christmas Gift Your Developers Actually Want: Being Heard
Developer friction is rising while leaders double down on AI and metrics. The only way to fix what’s actually broken is to ask the people doing the work.
I owe you an apology for skipping last Tuesday. Time was tight, and rather than forcing out something rushed, I chose to wait until I could sit down, think clearly, and write something that actually adds value.
It’s that time of year when we make time for the people who matter most. We schedule dinners with family we haven’t seen in months, we catch up with old friends over drinks, we actually show up to those holiday parties. There’s something about December that makes us pause the usual grind and invest in relationships.
So here’s a question: when was the last time you sat down with your developers, not for a sprint review, not for a stand-up, but to actually understand how they work?
If you’re like most engineering leaders, the answer is probably uncomfortable. Research from Atlassian shows that 63% of developers now say their leaders don’t understand their pain points, up sharply from 44% just a year ago. That’s not a marginal drift, that’s a crisis of disconnection happening in real time.
And the cost? Developers are losing an entire day each week to inefficiencies that most leaders don’t even know exist.
Why the listening tour beats another AI tool
The irony is rich. While leaders are betting big on AI to boost productivity, they’re missing the fundamental step of understanding where the actual friction lives. Developers aren’t asking for more tools, they’re asking to be heard.
Nicole Forsgren and Abi Noda make this clear in their new book Frictionless: the best way to find developer friction is by asking developers. Not surveying them. Not tracking their metrics. Actually sitting down and listening.
Start with a listening tour. Your goal is to understand your developers software development experience, or as Courtney Kissler, SVP and CIO at Expeditors, says, “Honor their reality.”
Listen without defensiveness or explanations, and remember it’s not your role to judge their reality. Stay curious, asking for details when needed. Note helpful practices, but avoid soliciting solutions, neither you nor they have the full picture yet, and they aren’t thinking like strategic product owners.
This isn’t about being nice. This is about seeing what’s actually broken before you waste another quarter implementing solutions to problems you’ve imagined rather than verified.
The 12-15 developer rule
Here’s where most organizations go wrong: they either talk to too few developers (missing critical perspectives) or approach it haphazardly (getting skewed data).
Forsgren and Noda are specific about this. To be most effective, you’ll want to talk to 12-15 developers. And to ensure you have a representative sample, plan strategically — consider factors such as years of experience, product area, type of development (like legacy, mobile, cloud, data science).
Think about that number for a second. Twelve to fifteen conversations. That’s maybe six hours of your time spread across a few weeks. Six hours to understand where millions of dollars in productivity are leaking out of your organization.
You need two planning lists:
Demographics that matter. For example, work location (onsite, remote, hybrid) and experience level (junior or senior devs).
Work types and organizational areas where devs work.
These lists help you map out your interview coverage and track who you’ve spoken with. You’ll quickly see if you’re relatively balanced between new hires and long-time employees, but don’t have interviews scheduled with junior devs in platform and legacy teams. That may be intentional, or it might be a simple oversight. Having this visualization helps you spot those gaps and correct them before you make decisions based on incomplete data.
The structure matters. You’re not trying to be exhaustive, you’re trying to be representative. You want to hear from the senior architect who’s been there eight years AND the mid-level engineer who just joined. You want perspectives from the team shipping customer features AND the platform team building internal tools.
What you’ll actually learn
When you actually do this, when you shut up and listen, you discover something uncomfortable: the friction your developers experience often has nothing to do with the problems you thought you were solving.
The research from Atlassian shows the top time-wasters for developers are finding information (services, docs, APIs), adapting new technology, and context switching between tools. Notice what’s not on that list? Coding. Developers only spend 16% of their time actually writing code, and it’s not even registering as a friction point.
So all those coding assistants you’ve invested in? They’re enhancing the experience without actually improving it, because you’ve been optimizing for the wrong 16%.
Meanwhile, the real problems, scattered documentation, unclear service boundaries, constant tool-hopping—go unaddressed. Tech debt, which used to dominate friction surveys, has actually fallen out of the top five issues. Not because it’s solved, but because other problems have gotten worse.
The empathy gap is getting worse
Here’s the part that should worry you: this disconnect between what developers experience and what leaders think they experience is accelerating. Leaders are banking AI-driven time savings while actual friction increases. It’s a false economy where developers are expected to deliver faster while navigating more unaddressed obstacles.
The gap exists because leaders stopped doing the most basic thing: asking. They’re making assumptions based on their own outdated experience of what development felt like when they were writing code, or they’re relying on proxy metrics that tell them everything except what developers actually need.
Let developers know that talking to you is a good use of their time. You can set yourself up for success by sending out short notes introducing yourself and your work and asking for a quick, 30-minute meeting. Depending on the team and organizational culture, these notes will be either well-received or met with skepticism, developers have seen a lot of initiatives come and go.
But here’s what changes the equation: when you actually follow through. When developers see that someone listened, understood, and changed something tangible as a result, the skepticism dissolves. Not because of what you promised, but because of what you delivered.
Your December resolution
This December, while you’re making time for everyone else who matters in your life, make time for the people building your product. Not in a Zoom all-hands. Not through an engagement survey. In actual conversations where you’re there to learn, not to sell them on your roadmap.
Twelve to fifteen conversations. That’s your winter project. Before you plan Q1’s tooling investments, before you finalize next year’s platform roadmap, before you commit to another initiative that developers will silently work around, go understand their reality.
Because the friction you can’t see is costing you more than you think. And the only way to see it is to ask.
Make it count
The best part? You don’t need budget approval for this. You don’t need executive buy-in. You don’t need a consultant. You just need to block time on your calendar and send some emails.
Start with your own team if you’re nervous. Pick three people from different parts of your organization. Ask them what slows them down. Ask them where the process breaks. Ask them what they’d fix if they could wave a magic wand.
Then actually listen. Take notes. Don’t defend. Don’t explain. Don’t problem-solve in the moment.
Just listen.
The gifts you give your developers this season don’t come wrapped in boxes. They come wrapped in attention, understanding, and the promise that someone actually cares about making their work better.
That’s the kind of gift that keeps giving long after January.
Want to dive deeper into how to structure these conversations? Nicole Forsgren and Abi Noda’s “Frictionless” offers a comprehensive framework for discovering and addressing developer friction at every level of your organization. Also don’t miss to download a free workbook with practical exercises and templates to guide your listening tour.
Taking a Winter Break
This is my last post for 2025. I’ll be taking a break over the holidays and will return with fresh content in January.
But I don’t want the conversation to stop here. What topics would you like me to tackle in 2026? Whether it’s a specific developer experience challenge you’re facing, an organizational pattern you’ve observed, or something you’d like a pragmatic take on — I want to hear from it.
Submit your topic idea here and I might write about it in an upcoming post.
A Thank You to My Readers
To everyone who’s read, subscribed, and engaged with these posts over the past few months, thank you. Your support means a lot to me.
As a year-end thank you, I’m offering 70% off on my monthly and annual subscriptions until December 31st. If you’ve been considering supporting this work, now’s the time: Get 70% off your subscription
See you in 2026. Have a great holiday season, and may your on-call rotations be quiet.
Cheers Marcel