When I first entered the world of software development, I assumed that my value would be measured by how clean my code was, how fast I could ship, how deeply I understood distributed systems. And to some degree, that was true.
I worked long nights. I crushed deadlines. I solved problems that stumped the rest of the team. And the praise came. Promotions followed.
But something felt… incomplete.
Despite all my technical wins, I struggled in meetings. I would freeze when asked to present. I couldn’t quite translate my ideas to non-technical colleagues. I started noticing something: the people who advanced faster were not necessarily better engineers, they were better communicators. Better listeners.
So I asked myself a simple but unsettling question:
“What if the thing holding me back isn’t technical at all?”
That question cracked something open for me. And over time, I began experimenting not with new tech stacks, but with small shifts in behavior.
Here are a few tiny activities that made a big difference in my ability to connect, influence, and lead as a technologist:
Narrate Your Thought Process (Out Loud)
In code reviews. In 1:1s. In Slack.
Instead of dropping a solution like a mic, I started walking others through my reasoning:
“Here’s what I saw. Here’s what I tried. This is why I chose this path.”
It felt clunky at first, but it helped me build the muscle of structured articulation especially under pressure. It also gave others permission to think aloud too, which created more collaborative spaces.
Keep a ‘Miscommunication Journal’
Every time something went sideways a bug that got missed, a client upset, a teammate confused I jotted down what I said, what they heard, and what I should have said instead.
Not to beat myself up. Just to see the patterns.
Over time, I started to notice where I over-assumed, where I under-explained, and where my tone created unintended friction. I became a student of my own gaps and that awareness made a huge difference.
Present Your Work… to Someone Outside Tech
Your partner. Your friend. Your dog-walker.
Try explaining your last project to someone who has no idea what a container is, what a PR means, or why you need a caching layer.
Not to dumb it down, but to bring clarity. If they cannot follow it, the message probably needs work.
This one habit helped me become much more effective in cross-functional conversations with product managers, salespeople, and execs.
Ask for Feedback on How You Made People Feel
Not just “Was this correct?”
Ask:
“Did I come across as closed off in that conversation?”
“Did it feel like I shut you down just now?”
“What would’ve made that discussion feel easier for you?”
It’s awkward at first. But when done sincerely, this kind of question unlocks emotional self-awareness which is often what separates good engineers from great leaders.
Pause Before Reacting, Especially When You’re Right
This one might’ve been the hardest.
When I knew I was right, technically right, I had a tendency to jump in fast. Correct. Assert. Win.
But I started experimenting with something else:
“I see where you’re coming from. Want to walk me through it again?”
Slowing down built trust. It invited dialogue. It gave others space to step into the problem with me. And funny enough, that made my ideas more accepted not less.
Want a small challenge?
Pick one of these and try it this week.
