Transform Your Team Dynamics And Developer Engagement by Cultivating a Knowledge-Sharing Culture
Stand out from other teams with a few mindset shifts
Have you ever wondered why some companies face permanent turn over while other stick together through thick and thin?
It’s certainly not an easy question, but the first answers that come to mind are:
management is a nightmare
tech is boring
people leave for a better salary everywhere
At least, that’s what I have encountered the most in my short career.
But while better pay is good, most developers would agree that losing some money for a job that nurtures knowledge learning and good team cohesion is a solid solution.
It’s easier said than done; everyone is different, and conflict can quickly arise for basic issues.
I’ve been in a few teams where most developers were doing their jobs, pumping out functionalities without wanting to share anything with other teammates; and for some that’s perfectly fine.
But in today’s newsletter, I want to discuss how to keep things interesting for developers daily and build better team cohesion using a couple of culture shifts that every team can do.
The team above all else
Picture this.
You have a team of four developers: John, Bryan, Maria, and Alex working on an application together.
Throughout the application's life, each person works on separate functionalities. Sometimes together, other times alone. Things seem to be going okay.
John has a pretty good knowledge of his dedicated functionalities, but the rest is vague. He heard his coworker talk about it during the daily meetings, but that’s about it. It’s fine for him; he likes working on his own.
Maria, on the other end has been maintaining legacy code for two years. She would love to work on the latest functionalities with John.
One day, John is sick, and an error on his part of the code is crashing the production environment. No one can fix it quickly because they have no idea how it works, and the angry manager tries to get John to work on his day off.
This is a true story I’ve lived in the past; I just changed the names.
When you end up with the application knowledge that is not evenly spread.
It might result in two issues:
Bottlenecks in task resolution if the developer in charge of the functionality is off for some days or leaves the company unexpectedly
Frustration from the other developers because someone might be stuck maintaining legacy code while others might be working on the shiniest new framework.
But how do you fix it?
1 - Encourage functionality demo within the team
Developers should start sharing their work through presentations and demos.
It boosts everyone’s comprehension of the code and interaction within the team.
But how do you choose the tasks that need sharing and those that don’t?
You certainly can’t go and share every task through a demo. There are enough meetings already.
It highly depends on the complexity of the task and the size of the updated code base.
If a task is technically complex, it will usually need a presentation, even if the code update is moderately small.
It's the same thinking if the code is moderately complex but large.
For example, we built a new microservices to send emails. The code is simple, but it’s a new service with a new database. Everyone needs to understand how it works.
No more “hum, I think Alex has worked on something like that in the past” in the middle of an emergency.
How do I run the presentation?
The goal is not to ask for a full, high-end presentation with PowerPoint and fancy animations.
Presenting the functional parts, followed by what it looks like in the code, exchange a few questions, and you’re good to go.
If there is too much pressure on the developers, it won’t be done.
How to get started?
That’s the hard part. At first, no one thinks of doing it, so it needs to be thoroughly thought of for each ticket until it becomes an automatism.
The call to run the presentation has to be made by the teammates who think it’s necessary.
It’s a good idea to designate a developer to take that role initially.
After some time, you end up with a team where every developer has a fair amount of knowledge on all the parts of the applications.
Anyone can leave at any time without the added pressure of being a failure point.
This doesn’t only apply to new functionalities! Getting everyone up-to-date on the legacy code base is also important, although I agree it’s more complicated.
2 - Push for innovation
Innovation is a culture.
Developers love some freedom, and companies love new, shiny functionalities.
Companies like Google and Netflix have innovation for developers as their core principles.
Google employees are encouraged to spend 20% of their work hours, or one day a week, working on projects of their choice unrelated to their regular job responsibilities -
The goal of having a dedicated time block for innovation is to allow developers to develop their skills and push their limits on projects they love.
The knowledge they learn can then be shared with the rest of the team.
Upon reading “working on projects of their choice unrelated to their regular job responsibilities,” you tend to think that they will probably work on their small personal projects.
But some of the biggest Google functionalities came from the 20%: Gmail, Google News or AdSense.
How to implement it?
Sometimes, copying the big companies is the way to go.
Define a particular time or a particular amount of time a developer can associate with an innovation task in a week.
I understand that not every company can dedicated 20% of it’s developer time to innovation. We’ve been doing “every Friday afternoon” at the company where I work, and it has been enough to get great results.
You will face detractors of this practice:
“Developers will use this time to not work on anything since there is no task definition, no deadlines”
“We can’t track what developers are doing; how is this helping the company’s bottom line?”
It’s not because developers work on what they want that they don’t have to show proof of what they are working on. It’s a sharing process; you’re trying to develop a culture where everyone can be trusted and love working there.
What will the developer work on? If I match my experience with Google’s, the projects developers worked on during innovation are usually work-related.
Why? Because you have the company’s resources, and it’s already a subject you work on for 8 hours a day. You have ideas that could innovate, but the product team doesn’t want to spend time on those ideas during “normal” hours.
The hardest part for the team is not feeling the pressure of delivering “real” day-to-day functionalities, which takes over the time dedicated to innovation.
It needs to be clear in everyone’s mind that innovation time is like time off. You won’t ask someone to work after work hour, well you can’t ask someone to work during innovation time.
I know some manager ask to work after hour, but that’s what I said at the start, people tend to leave those companies.
I’ve talked mainly about what’s possible at the team level; let’s discuss something that can be done at the company level.
3 - Meetups: Easy to organize, hard to keep alive
Setting up a meetup in a company is easy. You pick the people you want, say all the frontend developer, you send them an invite and voila!
But without a clear definition of who will lead the meetings and which subject will be talked about, you can be sure it will be dead in the water after the first occurrence.
To make sure things run smoothly, you first need to decide three things:
who will lead the meeting?
Which subjects will be discussed?
How recurring will the meeting be?
It can be a single person or a team. From experience, I would recommend a small team of two to four maximum. As for everything, the more you are, the less people want to interact, so keep it small.
Then, the core team needs to decide what will be talked about during the meetings.
It’s easy to say “frontend,” but that won’t get you anywhere in the long run.
Once you have defined the cloud of topics you want to address during those meetings, you must define the length and what the timeline of each meeting will be.
Here’s what we do:
1-hour meeting:
The first 30 minutes or less is a tech presentation. We get someone from the audience or the core team to run a presentation on a subject he likes or finds interesting. It can be someone he uses daily or a new framework, as long as it’s close enough to the front-end world.
The next 15 to 20 minutes is frontend news if anything is interesting to talk about.
The last 10 minutes is an open discussion. You can ask for help or transverse questions.
Finally, how recurring do you want this meetup to be?
You don’t want to spam your colleagues with meetings, too often will get boring and you’ll lack subject to talk about.
Not often enough and people will forget about it, don’t remember news from 3 month ago.
So, we run a meetup every month with no pressure to cancel it or make it shorter depending on what’s going on in the space and the company.
And the most important fact of all: know one month in advance what the subject of the next meeting will be.
There’s no better killer than joining a meeting where no one knows what today’s subject will be.
Working as a team is never easy, but the more you try to make it enjoyable for everyone, the better it will be for you.
I truly believe developers are curious by nature, so implementing ways to share and learn as their day-to-day core is the best way to keep everyone fulfilled.
It just has to be done properly so as not to feel like it’s forced on them and polluting their lives with endless meetings.
That’s it for today; thanks for reading until the end. If you liked this post, you can follow me on X or LinkedIn