📛 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.
While this article appears to be an opinion, a Strong one, but still just an opinion. So there is a contr-opinion of mine:
There are two types of documents that you can create: fire-and-forget and maintainable ones. Both of them have a drawback of their own. If you are creating documents with the intent of it being alive and actual all the time, then someone must spend effort updating it regularly. This activity is scaling with the number of documents, so at some point, someone needs to spend a significant portion of the day updating documents. Usually, this cannot be just a person hired for this purpose, but someone with actual knowledge on the topic.
On the other hand, creating documents that won't be updated is quickly generating A LOT of entangled documents, which become a horror for someone to find the information that they need, and even worse for someone who does not know what information they are searching for, but just wants to get holistic knowledge over the topic. If you have 2000 pages of documentation about your project, then good work, you have a lot of text that few will read, and fewer will understand.
Another point that the author raised is to overcommunicate to increase visibility and get to the people that does not read everything. I understand this perspective, but we should ask why people that does not read everything do it in the first place. As a selective reader myself, I can answer this - because it is overhead, most of the information in Slack or email is not useful for me, and well, is overshared. So if one is going to follow your advice, then others, like me, are going to mute even more Slack channels - it's like an arm-war between these two approaches. And casualties are the ones who do read everything, because they have to read even more.
Do I have a solution on my own? No :). My current approach is to keep documentation at a bare minimum - just enough for a person new to the topic to be able to get through all of it in half an hour. The rest of if I prefer to pass in the conversation to ensure that knowledge is fresh, pass in a form aligned with the reciever and context dependend.
Incredible tips Fran.
Some of the same things I came across when I transitioned to senior roles. It's so easy to just say that I know all of this stuff, but none of it is useful when you've to deliver it synchronously. Also, the bit about adapting to the audience is spot on. The approach you follow to explain something depends a lot on the intended readers.
Also, thanks for the mention!