Disclaimer: I want to make sure that you remember to apply the model that will fill your organization best. Depending on your team and the challenges you face, you have to focus on different activities.

Why your program failed? #

I've seen a lot of successful and failed learning initiatives. What was common for all the failures is that they were never more important than day-to-day tasks. A most striking example is when a company pays an expert to visit and teach them, but half of the people stay at their desks because they have features to deliver. The same thing happens when the speaker is from another team or when no one has time to do pair programming with a new hire because of a deadline. In all those cases knowledge sharing is not a priority. If you want to create a learning culture, then you have to make it more important than short term deliverables.

Team #

Let's start at the team level. Sharing experience and knowledge in the team has to be different from what you share at the company level. Everyone on the team should understand code and the domain that you're working on. If that's impossible, then you should split them into smaller teams.

Pair Programming (Mob Programming) #

Pair programming will make sure that at least two people on the team know some part of the code thoroughly. If something is crucial that the whole team needs to understand it, then mob programming is the answer.
The only downside is that those practices are taxing. At the end of the day of pair programming, I'm always drained. Working like that for a week is hard to sustain. It has a lot of benefits for all the hard work you put into it. You don't need code review anymore, and the pair can do complicated and even overwhelming tasks much faster.
One of the secrets of dirty work is that many people spend a lot of time on Facebook or other attention-grabbing websites. It's impossible to work all the time, but the problem with such sites is that after you open them—with the idea of a 5-minute break you realize an hour later that you did almost nothing this morning. It's impossible to happen when your colleague looks at the same screen as you. You have to focus on the tasks. I would even advise to use Pomodoro and to take obligatory breaks for both of you to recharge during the day.

Mentoring #

In my experience, mentoring works best when it's combined with pair programming. The new hire will learn faster when he is the only person touching the keyboard, and his mentor has to explain and guide him.
Mentoring can be useful without pair programming too. You can assign a senior developer to be a go-to person for your juniors. It can be scary for juniors to ask questions when they just joined and want to prove themselves. No one wants to look dumb, and no one wants to interrupt other team members when they seem to be focusing on something hard.
Having a person to ask can be liberating, and I've seen it helping new hires tremendously.

Code Review #

Code Reviews seem to be the default right now, but they are harder to use correctly. A lot of times, reviewers focus on code style or trivia. Building a better understanding of the application architecture or business domain from them is almost impossible. For a lot of distributed teams - especially across timezones that's the best they can do.
Making code reviews more effective is not that hard.

• Branches should live for a day or shorter.
• Make reviews small (e.g., a couple of files).
• Focus on why given change is needed.

Team meetings outside of the office #

One of the best hacks to make meeting fun is to do them in a nicer place than your meeting room. It makes sense to schedule your long meetings during lunch and book a table at a restaurant. You can also meet at the end of the day and talk at the coffee house or a pub. Just remember to treat it like work and to start, e.g., at 3 PM if it's likely it will take 2 hours.

Prepare a presentation for the rest of the company #

It's connected to the second part of this post, but I want to emphasize that the process of creating and presenting a talk for the whole company greatly benefits the team that makes it. To make an excellent presentation, you have to look from the outside and try to see what lessons you can draw from the last project. What can be useful for other teams? It forces you to rethink your daily work and see new connections.

Company #

Now the part about sharing knowledge between teams or even departments. My disclaimer about making time for it is even more important at the company level than on the team level. Having time to attend a presentation about part of the project you're not working on might seem like a waste of time if you only focus on the current sprint. It pays off in the long term when there is less duplicated effort between teams and more overall collaboration.

Lunch and Learn #

It's the easiest thing you can do—order food and convince one of the teams to share what they know about their technology or even their part of the domain. Having Lunch and Learn once in a couple of weeks can help a lot in spreading knowledge between the teams.

External presentations #

One of the developers prepares a presentation for a meetup or a conference. The best thing for him and the company is to make time for him to run a test run at the office. It's easier to present in front of the friendly audience, but everyone listening learns much more than if they heard the same content from someone else. Because they know the presenter, they listen more carefully (especially if they want to give feedback). I've found it useful even if the subject is not related to the work you're doing.

R&D + Retrospectives #

Making time for research, spike technologies, or architectures that might work better and later on sharing results with the rest of the company can help a lot with accelerating learning of the whole company. It's not enough to prepare talks about what we currently do if everyone is aware of it. It's not enough to try new things and experiment. But if you combine those two, then lessons learned in one team can save a lot of time of the other groups.

Internal training #

In my experience, making time for a person to prepare training can deliver more value than buying one from the shelf. What didn't work in my experience is to keep the right for it in the company. All of the ones I've produced or participated in died when the person making them left the company—sometimes just other priorities robbed them of time to run them. I've yet to see an internal training that was successfully passed over inside the company. What I've seen work is a developer working on training but keeping the rights for it. As it's his private property, he was more inclined to update it from time to time. Paradoxically teaching at other companies helped him improve it and add more context that he could use at his work. The only downside is the person going independent if he finds more passion for teaching than coding. While it may happen, I see more value in improving the whole company to take that risk.

Feedback or Comments?

← Home

Want to learn more?

Sign up to get a digest of my articles and interesting links via email every month.