A Framework for "Small Talks"

TL;DR This essay attempts to layout a proposal for a framework that is suppose to facilitate and nurture knowledge sharing culture within tech teams and reasons about motivations behind the proposal.

Motivation

Code reviews, pair programmings and similar conventional development practices not only strive to validate design and implementation of features while making sure that the overall code health is maintained with time but have also been primary mediums to impart and exchange domain as well as technical knowledge amongst team members.

These practices undeniably have contributed to shared domain knowledge possessed by any team, encouraged adoption of best practices while also providing a platform to express expertise in certain subject matters by individuals at the same time, which in turn has encouraged fellow teammates to cope up to the challenge of improved skillset.

Although aforementioned practices must always be encouraged in a team, in this essay I would like to propose an complementary framework to facilitate a channel to exchange knowledge within tech teams; a reason to express and share expertise or an excuse to learn from others. Think about it! When was the last time we discovered a best practice or a certain idea and attempted to share it with our teammates? Wouldn't establishing a platform where people are encouraged to share knowledge with each other help break that ice!

"When one teaches, two learn" — Robert Heinlein

The idea is to facilitate a platform where people get to share "as and when" they discover anything new without having to wait for an opportunity in the form of a meet-up or something, if that is even a thing in their workplace. It could be as simple as best practices, an improvement idea or even anything unrelated to work, etc in the form of simple short presentations. I have laid out a detailed proposal in subsequent sections. Read on!

Yet Another Talk?

Isn't it like any other presentation or talk already practiced in tech community? And if so why give it another name or bother justifying the same by over stretching the same old idea? Isn't it like putting lipstick on a pig?

IMHO, ideas that can't be identified with deeper understanding and proper vision are doomed to fail. A unique name and a proper vision statement gives an idea the much needed identity. We must understand the frailty of existing practices that give birth to any new idea, in order to truly comprehend and appreciate it. Adoption or no adoption is least of the concerns here.

"Its mark of an educated mind to entertain a thought without accepting it." — Aristotle

I believe that clarity on any idea should have enough potential to fuel the motivation and discipline required to pursue it. But first, let's explore some of the reasonings that buttresses this proposal strongly.

Dunning-Kruger's Effect

Let's admit the reality and our relatability to the notorious Dunning-Krugers Effect. Haven't we all gone through a certain concept, read a book, watched a lecture and convinced ourselves having understood it all by the end of it? And upon revisiting the same topic after certain period of time found ourselves falling short of a much better understanding?

The practice of expressing your findings, researches, expertise in the form of presentations, blogs, vlogs, books, talks, etc requires certain level of research on any given topic. Having a platform that allows people to exchange knowledge would encourage research capabilities within a team. This would help counter Dunning-Kruger's effect by improved understanding on relevant subjects and give an opportunity to acknowledge and appreciate others, leading to a healthier work culture.

The Forget Curve

It is important to realize and admit how soon things slip out of our mind. Say you want to implement a new idea in your current project or try out a library or a framework or even fit in a design pattern in your code. You thereupon make efforts to research and learn more about that subject before you could actually implement it. You realize to have gained great understand on that subject and decide to implement it. You finish implementing it and it's time to move on to other challenges and forget about it? Not really. You hit a bug in production and immediately plunge into your codebase to fix it, only to realize that you hold no memory whatsoever of the idea you materialized into your code, around that nasty bug, which once you thought you had great understanding of. Or, say you need to make use of the library or a framework you learned some time ago, in your next project but you realize you really have no recollections of it. Damn! Now you have to make those efforts all over again? Thanks to the forget curve.

What can we really do about it? I believe our ability to forget things is a boon and a bane at the same time. However, I reject the idea of having to make same efforts every time all over again. I say admit to this shortcoming of ours while making sure at the same time that our efforts are cumulative. What I mean is that we must make consistent efforts to offload our understand to decent notes, blog posts, talks, demos, open source github contributions, etc. That way we could cut short the amount of time it would take to recollect things. The key here is not sit on it long enough!

Standing On The Shoulders Of Giants

"If I have seen further than others, it is by standing upon the shoulders of giants" — Isaac Newton

Every team has members that are giants in certain subject matter. You may find some teammates who are good at domain knowledge, while others may have specialization in a technology stack. What we need to do is to acknowledge each others competency over certain subject matter and open ourselves to the idea of seeking knowledge/directions from them.

Having a platform that encourages such a proposition would allow people to be exposed to newer ideas, the way others approach to a problem and come up with solutions, their research outlook and least to mention time saved from having to start from scratch on a given topic.

Job Security

"Job security is knowing you will always have a job, even one that doesn’t yet exist today" — Louisa Wong

The idea is to be always prepared.

I am not suggesting to build a high value stature to use it to your advantage by threatening your exit from your workplace but instead allowing yourself to open up to more valuable opportunities and give yourself the freedom of choice without the fear of loosing your job.

Upgrading your skillset only when making a switch to another job IMHO is a misplaced motivation. In this ever evolving tech space, there is always a threat of getting outdated. The biggest risk taken would be failing to keep up, no matter where you work.

Volunteering to participate and engage in such knowledge sharing campaigns would allow people to exhibit their skillset and assure apt contributions to their work securing their well deserved position in any team or in the industry, in general.

Parkinson's Law

"Work expands to fill the time available for its completion".

There is no denial to the fact that introduction of any new practice is going to require us to drag ourselves out of our comfort zone. Having to make diligent notes, blogs, demos and presentations would require a certain amount of research effort and discipline. The key here is the quality and timing. I have over 10+ blog ideas parked as draft and I regret not having taken them up when I had much better understanding on pertaining subjects. To take up any of those blogs now would require same efforts all over again. This as you may have guessed, leads to procrastination. The imperative I believe would be to strive to find time to finish what you had decided to take up in the first place. The most common excuse we seem to find giving ourselves is that we can't find enough time. Well, it can't really be argued that it can't be the case at times but in practice these once in a while supposedly fair reasonings seem to turn into habit of excuses over time. In my personal experience, one of the our most detrimental tendency is what is famously know by Parkinson's law and top to it all, our ignorance towards it.

If a team decides to take up the challenge of establishing a knowledge sharing platform, it is going to be the responsibility of individual team members to nurture it by developing a culture around it. The key is to understand that every participation encourages follow up participations, which is how the cycle can be kept going.

Cost To Company

Every time a company hires an employee it struggles to strike a balance between the cost-to-company and the value that employee could bring in. This could be seen as curve A-B in the following graph.

All well and good so far? Not really. What companies need to acknowledge is that in this ever changing tech space, keeping up with evolving technologies is crucial besides sustaining already acquired competence at the least. Failing to keep up to trending technologies are opportunities lost and worse if employees fail to sustain already acquired knowledge and apply the same to say the least. This could lead to inflationary cost to a company as seen in curve C-D. The point I am trying to put across here is that companies need to acknowledge these issues and make efforts to address them by encouraging employees to work on their competence. Of course, an incompetent employee could always be asked to leave and a new employee could be hired with greater promises, but it's costly and not to mention there is no assurance to prevent this cycle from repeating itself.

Proposal

The proposal is to encourage teams to self volunteer for short presentations as and when they learn things as part of their research in certain subject matter. I proffer to call them "Small Talks".

This may beg an obvious question to many minds. Why small talks when we can always make notes and blogs, etc?

Well, the premise of "Small Talks" isn't really superior to other methods. However, the problem with notes taking and blogging is that they are mostly for self or an unknown audience. And ask yourself, when was the last time you volunteered for a tech talk? A small talk would be a convenient opportunity to grab onto. Besides, having to express your expertise and share knowledge within your teams would allow to address an audience that you are personally acquainted with. This would encourage superior quality of research and enhanced understanding, IMHO. Facing an audience from your domain, to which your content would be most relevant to with an awareness that your understanding could always be challenged would influence the way you approach to a subject and present it.

One could also argue that there could already be relevant materials pertaining to most of the subjects one could think of presenting. But the premise here besides knowledge sharing is to develop a culture that encourages critical thinking. Everyone has a unique take on any given subject. I say, don't shy away from that opportunity.

Listed below are the guidelines that intends to give some structure to the framework.

Digestibility

The most important aspect of these presentations is the size of the presentation itself. The intention is to keep it at a digestible size. Considering our perpetually shrinking attention span, imagine how longer presentations may bore the attendees. This could cause unwillingness to attend and worse discourage participation. I propose a duration of 10-15 minutes depending on the topic.

Please note that digestibility stresses not only on the size of the presentation but also advocates that the subject coverage must be very specific. If required, break the presentation into smaller sessions covered over a couple of days. A focused coverage of the topic would not only encourage intense research but also keep the attendees interested. On the other hand, attempting to cover boarder topic in one go would lead to procrastination owning to the amount of effort needed to pull it off.

Nature

It could be anything ranging from an improvement proposal, a best design practice you discovered, a clever solution to a tricky problem, insight in domain knowledge, a hack, how-to guide, etc. Things that may not directly be related to work are also welcome. The content of presentations must reflect its nature. Make sure to include code snippets, short demos, etc. If it's related directly to your codebase, see if you could include code walk through. This could really help hit home the message.

Please not that more than one presentations on same topic are also encouraged. People approach subject differently when researching. It could bring wider perspective to the table.

Include references in your presentations for others to refer to later.

Frequency

It isn't really possible to enforce a frequency at any level. The frequency of participation depends on the how comfortable teammates are at sharing things with each other, how excited are they really about such an idea or whether there are any incentives to participate.

Important thing here, at the least, is to strive to keep this channel always open so that people don't shy away even if they have got something to share. Believe me or not there is always going to be something worth sharing. Key is to recognize if you're victim of procrastination and if so strive to challenge it. Only you could be your judge.

People are always welcome to self volunteer or engage in a sort of pass-on challenge. Whatever works! Team leads/managers are equal participants. They could encourage a team member to participate or lead by example.

Attendance

It is not always possible to involve every team in such activities at a given point in time. Any such efforts made would simply result in procrastination as every team may have different deadlines. It's also possible that certain topics may not be relatable to other teams. Therefore, best is to keep these activities at team levels itself while keeping a channel open for others to join/participate across teams.

Intra team attendance is a must. Invitations could be and possibly should be extended to other teams as well.

Appreciation & Criticism

Ratings and reviews are critical. Team should never shy away from honest reviews while being kind to each other at the same time. Poor presentations gone uncriticized would encourage subsequent substandard participations. Remember, incompetency breeds incompetency. Suitable criticisms would help achieve aforementioned goals, such as, encouraged research capabilities within a team.

Finally, I believe that management should also strive to encourage participations by introducing some sort of reward system, if required. This could range from acknowledging individual efforts in public or considering these efforts as part of appraisals. In my linkedin connections, I know of certain companies that go the extent of acknowledging their employees in public and even encourage them to write blog posts for the companies official blog.

Tracking

There must be an organization wide tracking of presentations. This would allow people to refer to them later and could also be used for various insights.