Someone once told me I wasn’t delivering enough impact, and I felt blindsided. I’d shipped features, written design docs, unblocked teammates, fixed backlog items. Wasn’t I delivering impact?
The feedback stuck with me. It told me I’d missed something important without telling me what. I think of this as low-digestibility feedback.
What do I mean by digestibility? Some foods are easy to process (white bread turns quickly to sugar), and others take more work (kale, leafy greens).
Low-digestibility information requires more work to extract meaning. High-digestibility information is ready to act on.
The food metaphor is silly, but it’s been sticky for me.
Low-digestibility feedback isn’t bad, just raw. The person giving it might be rushing, tired, or still figuring out what they mean.
When you receive low-digestibility feedback, you have to do the processing yourself, which takes time and energy.
The rock tumbler
As a kid, I loved shiny rocks, so I asked for a rock tumbler for my birthday. It’s like a small cement-mixer drum. You fill it with rocks, turn it on, and it makes a loud chunk-chunk-chunk as they tumble. It runs for days, and eventually the rough edges grind down into shiny gems.
I loved mine. My parents? Not so much. The clanking drove them to move it to the basement, and I could still hear it from my bedroom two floors up.
Processing low-digestibility feedback feels the same way. I sit with it. The feedback tumbles around in my head, colliding with other thoughts and experiences. It’s loud and uncomfortable. And, eventually, I find meaning.
What I extracted
I thought about the “not enough impact” feedback and realized the design docs were for future work, not current needs. The backlog items weren’t pressing. The features I shipped were table stakes. Other people had delivered more visible wins so, in comparison, mine didn’t stand out.
It stung to realize I’d been busy instead of effective. I spent my days on things that felt urgent: Slack threads, quick questions, patching problems. Unfortunately, urgent isn’t the same as important.
I showed up every day, trying my hardest. When I stepped back, I had to ask myself whether any of it mattered. The feedback didn’t feel unfair — it felt incomplete, like they weren’t seeing everything. Maybe the “everything” wasn’t worth seeing.
I scheduled a follow-up to share my thinking. They confirmed I was on the right track and offered a few more specifics. Slowly, I came to understand what they meant by “impact” and how to focus on work that mattered versus work that kept me busy.
This is what they could have said:
“You can deliver more impact without more work. Some of your design docs address problems that aren’t pressing for customers, and there’s a company goal you could make a dent in. Not all backlog items are equal either.”
This version acknowledges what I did, points to specifics, and offers direction.
Asking for clarity
Looking back, I should have asked for clarification. Something like:
“What I’m hearing is that my work isn’t hitting the mark. Can you give me a specific example? What would you suggest I do differently?”
The structure is simple: here’s what I’m hearing, here’s what I need, can you help?
I wish I’d asked sooner instead of spending weeks in the rock tumbler. Following up shows you want to act on their feedback, not dismiss it.
What changed
I started to change how I worked. Before jumping into a thread or picking up a problem, I asked myself whether it specifically required me. If someone else could handle it, I waited to see if they stepped in. If it did require me, I tried to make the fix durable by adding documentation, a script, or a UI improvement.
I stopped patching holes and started filling them in.
I still struggle with this. The pull toward quick, visible helpfulness doesn’t go away. I’ve meditated on and off for years, and I never stop getting lost in thought. I just get better at noticing and redirecting. I have to keep catching myself.
The case for vague feedback
When I first started thinking about low-digestibility feedback, I thought of it simply as bad. I felt frustrated when I received it. Why couldn’t people just tell me what they meant?
I’ve come to see some benefits. For one, people are far more willing to give vague feedback than carefully crafted feedback. High-quality feedback takes effort and time. If you only accept the spoon-fed kind, you might not get any at all.
More importantly, the work of processing vague feedback trains you to find opportunities for growth everywhere. A question on your pull request might be a sign that your code could be clearer, even if no one says that directly. A cluster of questions on one section of a design doc might mean you’re inviting bikeshedding. Maybe that section belongs somewhere else, or shouldn’t be in the doc at all. You start reading signals, not just words.
Even when someone does give you clear, specific advice, who’s to say they’re right? Their recommendation might address the symptom but miss the cause. The work of processing it yourself forces you to actually understand the problem.
We can’t only eat white bread. The greens are good for us, even if they take more work to digest.