Back to Feedback — Episode 1
This is the first post in a series I've been building for a while: Back to Feedback. The premise is simple — take four years of real performance review feedback and turn each recurring pattern into a practical lesson for software quality professionals. No theory. Just "here's what actually happened, and here's what I did about it."
I'm starting with the pattern that, in hindsight, sits at the root of almost everything else: knowledge sharing.
Where it came from
This one showed up across multiple review cycles, in different words, from different people. The first time, it came as a gentle nudge — something along the lines of "you could inspire others to do what you're doing." Later, a technical talk I gave on quality metrics was specifically called out as a positive example. But also as a one-off. Something that happened once and didn't become a habit.
The clearest signal came when the same colleague gave me the same advice in two separate review cycles, one year apart: "share your automation ideas more." That's not a coincidence. That's a pattern I wasn't seeing.
Where I went wrong
I did share knowledge — reactively. Someone would ping me with a question, I'd help. Someone would get stuck, I'd explain. What I didn't have was a proactive, recurring practice of transferring what I knew — partly because I was on a team of Senior engineers, and I assumed they probably already knew most of what I knew, since we were at the same level.
The practical result: knowledge I had accumulated stayed with me. The team depended on finding me, rather than having asynchronous access to what I'd already solved, documented, or learned. I wasn't hoarding anything deliberately — I just hadn't understood that withholding knowledge by omission has the same effect as withholding it by intention.
What I learned
Knowledge that only lives in your head isn't a team asset. It's a team risk.
That sentence sounds harsh, but it's literally true: if only one person knows how to handle a specific type of problem, the whole team becomes vulnerable whenever that person is unavailable — in a meeting, on vacation, or after they leave. Centralizing knowledge without meaning to is still a single point of failure.
The subtler lesson took longer to absorb: being a technical reference doesn't mean knowing the most. It means making the team know more. When I gave that metrics talk, the recognition I received came from people who rarely gave me feedback in day-to-day work. That told me something important — the visibility of your knowledge creates recognition that raw competence alone never will.
How to fix it
The solution isn't "be more generous" or "try to share more." That's an intention, not a system, and intentions collapse under the weight of a busy sprint.
What works is building a fixed cadence for sharing, across different formats and frequencies: something lightweight and weekly (a short post in the team channel), something more structured monthly (a talk or a write-up), and something quarterly aimed outside the immediate team (a public post, like this one). When sharing becomes a routine, it stops depending on motivation or memory — it just happens.
The 5 practical steps
Create a fixed space for weekly learnings. Pick a channel or thread and post one thing you learned that week — no matter how small it seems. The format matters less than the consistency.
Document before moving on. Every time you learn a new tool, technique, or process, write a short summary of "what I learned and how I applied it" before switching to the next problem. This turns individual learning into reusable material for everyone.
One technical session per semester. Pick a topic your team doesn't fully own yet and propose a short session — even 15 minutes is enough. The goal isn't a polished presentation. It's knowledge transfer.
Publish externally, monthly. Turning real work situations into public content (like this series) forces you to structure what you've learned in a way others can actually use — and creates a visible record of your growth over time.
Build a shared reference repository. Keep an organized space — a shared doc, a wiki, a code repo — with templates, scripts, and checklists that any teammate can access without having to ask you first. The goal is removing yourself as the bottleneck.
None of these require exceptional talent. They require only one thing I didn't have: scheduled repetition.
📚 Further reading
- Building a Second Brain (Tiago Forte) — a practical system for capturing and organizing knowledge so it stays accessible later, not just in your memory at the moment you learned it.
- Ultralearning (Scott Young) — useful for understanding how to structure your own learning so it's ready to be taught to others from the start.
- Atomic Habits (James Clear) — the theoretical foundation for turning "share knowledge" from an intention into an automatic routine.
- The Power of Habit (Charles Duhigg) — explains why systems beat willpower, especially for behaviors that require consistent repetition.
- Show Your Work! (Austin Kleon) — the central argument of this book is exactly this: making the process visible — not just the final result — is what builds recognition and reputation over time.
- The Knowledge-Creating Company (Ikujiro Nonaka & Hirotaka Takeuchi) — a classic reference on how organizations (and individuals within them) convert tacit knowledge into shared knowledge.
This was episode 1 of the Back to Feedback series. Next week: Episode 2 — I delivered. I didn't say anything. And no one knew.
What do you know today that your team doesn't know you know?