📛 Why most engineers fail at knowledge sharing (6 habits that make you stand out)
Most engineers fail at knowledge sharing, hurting their growth. Learn 6 habits to share knowledge like a senior and stand out in your team.
Most software engineers say they value knowledge sharing. But when you look at their behavior, it’s all meetings, DMs, and tribal memory. They complain when things break, but they never document the fix. They push work forward, but never explain their reasoning. They give feedback, but never the principles behind it.
This isn’t just inefficient. It slows down your team, weakens your technical judgment, and traps you in the “doer” bucket instead of helping you stand out as a leader.
Here’s how I’ve approached sharing knowledge like a Senior Engineer—using writing, structure, and process, not just kindness and availability.
⭐ In this post, you'll learn
Why writing is the most scalable way to grow influence
How overcommunication beats invisible “best practices”
How to avoid knowledge silos and break others'
Tactics to turn tasks into visible team-level value
Red flags that signal a poor knowledge-sharing culture
🧠 #1 Writing scales better than talking
If you want to build real leverage as an engineer, stop trying to explain everything synchronously.
I’ve seen how fast things move when knowledge lives in documents instead of people. After I created a small design doc for a testing traffic issue, my manager called it out in front of the team. Not because the problem was hard, but because I gave the team something they could build on. A reference. A way forward. A decision.
But putting it in writing isn't enough. When your writing is clear, people trust you. When it’s not, they avoid your work.
Syncs don’t scale. Writing does. The moment you think, “this might help someone else,” you’re holding a potential leverage point. Don’t waste it.
💬 #2 Share the thinking, not just the outcome
Most engineers stop at “what.” Seniors explain “why.”
I’ve spent hours writing detailed code reviews where I not only reject bad patterns, but explain why they’re wrong and what tradeoffs they introduce. I know it takes time, but it positions me as someone with judgment. People start asking before building.
Knowledge isn’t just facts. It’s the reasoning behind decisions. Share that or you’re not helping anyone grow.
🛑 #3 Knowledge silos are silent productivity killers
Silos aren’t always visible. But you feel them when only one person can fix a bug, or nobody understands a system enough to modify it confidently.
I’ve seen this firsthand. Once, someone in my team did a fix for the second time. This person never documented the root cause the first time. Another time, smoeone wrote an document by copy-pasting from another one, without checking some of the infrastructure components even existed. These things aren’t just lazy. They are dangerous.
This gets people to investigate old tasks, rebuild context, and reverse engineer decisions because nobody documented their thinking. That time could have been used to build. Instead, it went to forensics.
I remember when I was at university, and professors would write exercises with confusing code to make sure we understood the rules of programming languages... At work, the point isn't anymore to try to trick your coworkers.
The solition is boring: write handoff docs, explain your commits, log your assumptions. It may feel like overkill, but it’s how you make your work compound.
📣 #4 Overcommunication is underrated
You think you’re repeating yourself. But half your team missed it the first time.
When I started broadcasting updates on a project, I thought I was just duplicating information. I wasn’t. I was signaling velocity. When you send emails and Slack updates, it’s not for the people who read everything. It’s for the ones who don’t. It’s for visibility, accountability, and forcing others to care.
Same goes for on-call handovers. By laying out responsibilities clearly, I showed I was taking on more than just sprint tickets. That changes perception. People start seeing you as a reliable engineer, even if nothing else changes.
And this applies directly to your career growth. Your manager has many other concerns than writing down your impact. Make sure to collect a brag doc that you can share every 6 months to 1 year.
Don’t assume others are tracking your impact. Force them to notice.
🪓 #5 Discussion is not documentation
I’ve wasted hours in meetings and threads trying to align people. Most of the time, I should’ve just done the work and shared the doc.
When I had strong ideas about some implementation details, I tried to get buy-in through comments. It backfired. Nobody was really paying attention. Later, I learned that the best way to drive change was simple: shut up, do it (or at least a proof of concept), and document it well.
I’m not saying collaboration is bad. But if you’re trying to shift how something works, clarity beats consensus. Take the task, deliver it your way, and let the artifact speak. That’s how influence spreads.
The first one to write working code wins.
👨👩👧👦 #6 Adapt to them.
When you prepare a meeting to share knowledge, you aren't the main character.
Recently I prepared a knowledge sharing meeting for people who didn't work in a project that I worked at. To be honest, I didn't know what to include and what not to include in the meeting. So I asked them what they wanted to know. I asked them to share their questions, and I prepared the meeting based on that.
It's like any entrepreneur. You can't build something in silence just to find out nobody cared about it. Ask people what they need and solve that need.
That makes people grateful, and makes everyone heard in the room.
🚀 Learn even faster
Want a higher salary, more free time, and faster learning?
This newsletter is your shortcut.
🎯 Conclusion
If you want to grow fast as an engineer, treat knowledge like code: versioned, documented, and easy to consume.
Stop waiting for people to ask questions. Make your thinking visible. Be the person who writes the doc, asks the hard questions, and overcommunicates even when it feels like noise.
That’s how you stop being a doer and start being seen as a builder.
🗞️ Other articles people like
👏 Weekly applause
These are some great articles I’ve read last week:
API Performance Improvement Tips by
. Implementing techniques like caching or load balancing are essential strategies for improving API performance and user experience.What to Look for in Code Reviews by
. A structured approach in code reviews prioritizes design, functionality, or complexity improves code quality and team collaboration.The Future of Solutions Architect Role with Agentic AI by
. The role of Solutions Architects is evolving to focus more on strategic engagement and AI governance- . Understanding the common mistakes in coding challenges, like avoiding magic numbers and ensuring you finish your projects, can significantly improve your performance as a software engineer.
🙏 One last thing before you go:
I am always working to make this newsletter even better.
Could you take one minute to answer a quick, anonymous survey?
See you in the next email,
Fran.