60+ Knowledge Sharing Sessions in Two Years

Have you ever shared knowledge?
If your answer is yes, what did you share?

In this article, I mentioned how I began sharing knowledge within the org.
But back then, it wasn’t yet a habit. That changed with this story—when I ended up running weekly or biweekly sessions for two years straight.

It began in April 2023, during the From Monolithic to Microservices project.
As the owner, I quickly noticed I was explaining the same things repeatedly to different people: design principles in TypeScript, tech stack choices, monorepo structure, shifting between library and application mindsets.
By the fourth repeat, I thought—why not share this once, with everyone?

So I started documenting these points, turning them into weekly talks, and inviting anyone interested.
Centralized info, less repetition—it sounded perfect.
Reality, of course, had other ideas.

The Shift and the Anxiety#

I began logging key discussions each week—not just technical concepts, but the reasoning behind design choices. Even small things like “why we added this lint rule” went in if they had sparked debate.

At first, content flowed naturally.
Feedback was positive.
Frequently asked questions became future topics.

Then frontends from outside the platform team asked to join.
I welcomed them—and that’s when things shifted.

A small internal session became a frontend-wide presentation.
With it came pressure: not everyone shared the same background or daily work.
What used to be casual turned into performance anxiety.

Was I being too superficial?
Too boring?

Preparing talks became stressful instead of energizing.
I found myself asking:

“Do these sessions even matter to anyone?”

Returning to the Why#

The original goal wasn’t performance—it was to solve communication pain points.

If the pressure was high and the value unclear, the solution wasn’t to “push through.”
It was to pause and rediscover the purpose.

I realized: I didn’t need to know all the answers—just ask better questions.

So I ran a survey for feedback and topic ideas.

The results?

• Interest in topics: 8.1/10
• Delivery style: 9.6/10
• Would recommend: 10/10

More important than the scores was the signal: the format worked.

I hosted a small focus group to refine the suggested topics, then built a topic queue.
I was still the speaker, but the direction came from the audience.

Three Lessons from Two Years of Sharing#

It’s Not About What I Want to Say—But What I Can Offer#

Sometimes, you don’t see your own blind spots until you teach.
The sessions turned intuition into explainable, transferable knowledge.

I Learned More Than Anyone Else#

To explain well, I had to:

• Deconstruct designs
• Study alternative implementations
• Rebuild my own logic chains

Many of my own technical roadblocks became next week’s topics.

Efficiency Through Constraints#

Midway through, I set a rule: 90 minutes prep for a 50-minute session.
It sharpened my ability to structure quickly and improved my proposal writing and system design.

Sharing Doesn’t Have to Be a Stage#

During these two years, I often wondered:

“Do I still want to be a software engineer?”

I had doubts. Maybe it was time to try something else.
But the more I hosted, the more I realized—these topics still excite me.
I still want to understand why one design is better.
I still want to articulate and share that understanding.

Knowledge sharing doesn’t have to mean public speaking, polished articles, or YouTube videos.
Sometimes, it’s just a way to avoid explaining the same thing for the fourth time—
and in doing so, you create a space where everyone learns together.

Somewhere along the way, I found myself in that process.

And I began to see the kind of Staff Engineer I want to be:
A bit idealistic, but someone who dreams of a team where learning is natural, mutual, and lasting.