Pushing the Right Buttons: How My Son Taught Me to Find High-Impact Work as a Staff Engineer
Listen - Do - Share
A moment with my son inspired a simple yet powerful framework that I now use: Listen-Do-Share.
This approach validates ideas fast- ensuring you invest time and energy where it counts.
Here’s the story:
I’m standing in my mother-in-law’s bedroom.
It’s 7:30pm.
Time for the kids to go to bed finally.
My 4 year old son is sleeping over with granny tonight.
I’ve been asked to help them “set up the TV,” which usually means scrolling endlessly until we find his show.
I’m tired.
I’m not looking forward to this. The TV in granny’s room is old. It’s so old it still has a DVD player on it.
As I enter “dad-mode” and start fiddling with the TV, remote in hand, my son keeps whining, (asking?) to touch the remote.
But I need it.
I don’t want to let it go; I want to complete my task.
I want to finish what I have to do, so I can move on with my night and finally get some time off.
But he’s persistent, his pleas are getting louder, almost annoying.
For whatever reason, on this night, I become super dad, and decide to put my needs and desires aside.
I decide to listen to him.
So I give him the remote.
He just wants to push buttons.
(Basically what we engineers do for a living)
He’s having a blast!
Push a button, see what happens, try again.
Through osmosis, he seems to have learned iterative development. I love it!
But then… he hits the blue button.
The blue button that kind of looks like a house.
The special button in the top right that seems just as important as the big red power button, but the symbol doesn’t quite make any sense.
BOOM!
The TV makes a sound.
A DVD ejected from the side of the TV with the force of a jet breaking the sound barrier.
My son is OVERWHELEMD with joy, satisfaction, amusement, and drunk on power.
Something in the physical world just moved because his tiny finger finally hit the right button.
We share this wonderful moment.
I’m proud of myself for stepping back to listen to him rather than just do the thing.
This process is how you have staff-level impact.
You first LISTEN. What is the problem here? What is the real ask?
You then DO something. Start small, explore, try.
Finally, you SHARE that something. You need to hear from others.
And then go back to LISTEN.
Repeat this LISTEN — DO — SHARE cycle in ever expanding waves as you get positive feedback.
Raise the stakes as you validate you are onto something.
For example, last year I was embedding with a team that needed big data.
Bigger than we would want to spend on our warehouse.
In sitting with that team, I backed up and started listening. It boiled down to: we have a bunch of data that needs to stay in blob storage we want to work with.
OK -> what’s the problem with blob storage?
Well, if you are still using Hive, it’s slow and hard to manage.
Enter my discovery of Apache Iceberg and data lake table formats that enable a Lakehouse architecture (this was early 2023, lakehouse wasn’t yet the buzzword it is today).
The first iteration of LISTEN — DO — SHARE went like this:
We have this big data we don’t want in our warehouse
Let me explore the space; it’s been a while since I’ve started a greenfield project
Hey, I found out about this thing called Iceberg
Feedback from my private conversations was all positive. Let’s expand the scope and keep going.
The second iteration:
Everyone liked the idea; seems we can replace our Hive-style partitioning and upgrade our blob storage
Build a quick PoC to write some Iceberg data
Hey, look how easy it was to write to Iceberg and check out the metadata it collects for better pruning. I think this can work for us. Who can help?
Feedback expanded to more folks, we connected with other teams using Iceberg. Making noise attracted interested supporters
I’m onto something.
This loop continued to play out until a small squad expanded to a multi-team effort.
To have staff-level impact — you don’t know ahead of time what that means.
You use your experience to listen, to follow hunches, to figure out what threads are worth pulling on.
Then you do something like read about it, try it, spike something out.
Once you know more about the problem and possible solution, you share.
Staff-level impact finds you.
You just need to look for it.
Sometimes you’ll fall short (like I did with diagrams as code — pretty cool but not worth evangelizing across the company).
This is great feedback though.
It’s OK to fail.
Find the problems you think are important, do something about it, make some noise.
Get some validation, some feedback before investing more of your precious time.
The key is to listen first.
Knowing what to listen for comes with time and experience. But also the patience to hear people.
What’s the ask behind the ask.
Invest more time and energy as you get stronger signal from your peers, stakeholders, customers, that you are onto something.
The biggest mistake you can make is invest time (and worse other people’s time) in something that doesn’t deliver value.
Caveat — there is always value in doing things because you can usually learn a lot from the experience.
Try not to invest too much into learning the same lesson.
You can often get the same lesson at a fraction of the cost; iterate.
TLDR:
Listen — to yourself, to your stakeholders. What’s the problem that needs solving? Is this a problem no one is paying attention to that needs attention?
Do — make small bets, try things, learn, experiment
Share — make noise to attract early adopters/supporters, to validate if you are onto something
Thanks for reading. I’m giving a talk at StaffPlus this year about finding staff-level impact.
I would love to hear what you think of this idea or, better yet — how you define or find staff-level impact.
Please reach out. I love hearing any criticism, support, feedback, new ideas.
You’ll be doing me a huge favor — I’ll owe you a BBQ invite.
DM or comment :)