Creating a Culture of Learning Inside Your Company

I’ve been working in tech for more than fifteen years now, and when I first started building software, books were one of my main ways to learn. I would carry them everywhere, reading on commutes, during lunch breaks, and late at night.

That’s why, for me, everything started with a book. Titles like The Pragmatic Programmer, Practices of an Agile Developer, Apprenticeship Patterns, and The Software Craftsman didn’t just teach patterns or tips; they reframed software development as a craft, something you continually refine with curiosity, humility, and deliberate practice.

That shift in mindset naturally leads to a bigger question:

What would it look like if our entire company treated learning as part of the work, and not a side quest you squeeze into evenings?

This article is my attempt to answer that, based on a talk I gave at RivieraDev last year called “Creating a Culture of Learning Inside Your Company”. This is also the first article in a series where I’ll explore more of the ideas and practices we have at Criteo.

TL; DR;

Creating a learning culture is less about big programs and more about small, repeatable habits that people actually enjoy doing.

In the visual below, you’ll see a snapshot of both sides of the story: the concrete practices that help learning flourish (book clubs, tech lunches, katas, hackathons, guilds, mentoring, internal talks, open source, and more), and the usual excuses and challenges that get in the way (no time, no permission, low attendance, complexity, lack of routine).

The rest of this article walks through how to turn those practices into something real in your team, and how to gently push back on the excuses so learning becomes part of the way you work, not an after-hours hobby.

Why a learning culture matters (especially in tech)

Sandro Mancuso puts it bluntly in The Software Craftsman:

“Creating a culture of learning is one of the most efficient ways of injecting passion into a company. With highly motivated developers […] companies could benefit immensely from all the innovations and efficiencies they would bring.”

In other words:

Passion follows learning, not the other way around.
A team that keeps learning doesn’t just write more code. It finds better ways to solve problems, challenge assumptions, and improve the system around them.
Over time, the compounding effect of small learning habits shows up in better architecture, fewer incidents, faster onboarding, and stronger retention.

The “yes, but…” trap

But Mancuso also adds a crucial “however”:

“However, instead of having managers trying to impose how, when, and what developers should learn, companies should empower developers to create their own culture of learning.”

That’s the core idea: you can’t mandate a learning culture from the top. You can only create the conditions, provide support, and then get out of the way so people can build it together.

Most tech companies would say they “support learning”. They’ll nod enthusiastically when you talk about:

Training budgets
Time for side projects
Knowledge sharing

And then reality kicks in.

You see the gap between “Yes, we care about learning” and “But we have deadlines/incidents/roadmaps/budget constraints”. To illustrate this, I like the following meme from the “_yes_but” Instagram account as a metaphor to show this exact tension: the intent is there, but the system gets in the way.

A learning culture doesn’t appear because someone wrote a slide saying it’s important.
It appears when small, concrete practices start to exist in the real world, and keep existing even when things get busy.

Let’s talk about those.

What a learning culture looks like in practice

Below is a non-exhaustive menu of activities that help create a learning culture from the inside. You don’t need all of them. You just need a few that fit your context, and the will to keep them alive.

1. Make learning social

Learning sticks better when it’s shared.

Some simple formats:

Book / Video / Podcast Club
Pick a topic (observability, distributed systems, leadership), share a resource, and meet monthly to discuss. Keep the bar low: one chapter, one talk, one episode.
Tech Lunch Group
Reserve a room, bring food, and have someone walk through a topic, demo, or postmortem. No slides required, no perfectionism.
Coding time, learning time
There are always opportunities to share and, for sure, to learn. Practices like Pair/Mob programming can be very powerful since the learning is always “in context” and immediately applied. Also, treat reviews as an opportunity to explain trade-offs, alternatives, and patterns. Not just to approve or reject. Even in incident reports, promote a blameless culture so everyone can learn from mistakes.

These formats work because they piggyback on existing habits (eating, reviewing code, chatting) instead of adding a whole new ceremony.

2. Practice in safe, low-pressure environments

If production is the only place people “learn”, the cost of mistakes is too high, so they stop experimenting.

Create deliberate practice spaces:

Katas / Coding Dojos / Koans
Short exercises you repeat and refine over time to practice fundamentals: TDD, refactoring, system design, etc. We already published an article about it here. Also worth mentioning is our “Disaster Recovery Testing” practice, where we learn by simulating incidents.
Hackathons / HackMeUp
Time-boxed events where people form teams, try ideas, and show them off at the end. The goal is learning and collaboration, not shipping polished products. At Criteo, we host an annual hackathon (the next one is happening this month) that involves the entire company as a central part of our innovation culture.

These spaces send a strong message: experimentation is not just allowed. It’s encouraged.

3. Open doors across the organization

Some of the best learning happens when you step outside your usual bubble.

Examples:

Internal Mobility / Desk Surfing / Team Swaps
Short rotations or shadowing periods where someone spends time with a different team to understand their constraints, tools, and workflows. At Criteo, we have an internal mobility program that allows people to share knowledge but also to gain new skills firsthand by working on different topics.
Guilds / Communities of Practice
Cross-team groups around a theme (e.g., Java guild, Python guild, observability guild) that meet regularly to share best practices, RFCs, and lessons learned. At the time of this writing, we have more than fifteen guilds at Criteo, each of them self-organized and working in the way that best suits their members.

These initiatives reduce the “us vs. them” dynamic and build a shared mental model of the system.

4. Invest in structured growth

Not everything has to be informal. Structure can give learning more visibility and legitimacy.

Some examples from the talk:

Internal training, bootcamps, and mentoring
Domain-specific programs (machine learning, AI tools, leadership) paired with mentoring to support people as they apply what they’ve learned. Here at Criteo, we offer everything from AI Fundamentals Week to ML Bootcamps, as well as a Mentor/Coach program and onboarding sessions for new hires.
Self-learning time and resources
I would have loved to have an O’Reilly account back then when I was devouring every book I could get my hands on. Now, there are plenty of online platforms with almost unlimited resources. Providing access to your team or your company is worth investing money in. That’s something we do at Criteo, along with LinkedIn courses and our own learning hub managed by the Learning & Development Team.
Tech Talks and internal conferences (e.g., a Tech Summit)
Give people a stage to share what they’ve built, fixed, or learned. This not only spreads knowledge but recognizes learning as valuable work. We usually have one or two “tech talks” per month and one Criteo Tech Summit every year.
“20% time”-style initiatives
Protected time where engineers can explore ideas, pay down technical debt, or prototype improvements outside direct roadmap work. Getting this time may be tricky but you don’t have to stick with “the 20%”. At Criteo, we have the 10% — Side Projects rule, like two days per month.
Open Source and community work
Contributing to OSS or sharing learnings externally forces teams to raise the bar on quality, documentation, and sustainability. Thanks to a proposal from Erwan Velu, we approved an official Open-Source Charity for VPTO (Volunteer Paid Time Off) days, so Criteos can contribute to open-source projects two days per year.

None of these are “nice-to-have perks”. Over time, they’re how you grow senior ICs, staff engineers, tech leads, and future managers.

The hard part: excuses, challenges, and how to respond

Even when pretty much everyone would agree on the value of the activities previously listed, there is still friction that we could denominate: “EXCUSES | CHALLENGES”. Not to dismiss real constraints, but to make them discussable.

Here are a few patterns you’ll almost certainly hear, and how to handle them.

“We don’t have time.”

Reframe: Start so small that “no time” stops being a valid argument.

Turn one existing weekly meeting into a 15-minute learning slot once a month.
Make a “learning lightning talk” part of your team’s ritual: one person shares something they learned in 5 minutes.
Use asynchronous channels (Slack, email, internal blog) to share “one nugget per week”.

You’re not asking for a day a week. You’re asking for one recurring, visible habit.

“Management hasn’t approved it.”

From the talk: “Don’t ask for permission. Be polite, be bold.”

That doesn’t mean breaking policies. It means:

Start with what’s clearly within your control (lunch sessions, book clubs, brown-bag talks).
Show outcomes: attendance, satisfaction, small improvements that came out of these sessions.
Then go back to leadership with a story: “We tried this on a small scale, here’s what worked, here’s what we’d do with a bit more support”.

Leaders are far more likely to back something that already exists and shows traction.

“Nobody shows up.”

Communities rarely start at full speed. The 90–9–1 rule (borrowed from online communities) is a useful lens:

~1% create most of the content.
~9% engage actively.
~90% observe silently.

Your goal isn’t to get 100% of people to attend everything. Your goal is to support the 1–10% who drive the energy, and to make it easy for the rest to benefit passively (recordings, notes, docs). That’s why one of the mantras from the talk was simply: “Just do it”.

“It feels too big/complex to start.”

Another mantra: KISS — Keep It Simple, Stupid.

Don’t start with a company-wide “Learning Program 2026”.
Start with one recurring event, in one team, with a format that requires almost no logistics.
Once it works in one context, copy-paste the pattern elsewhere.

Complexity is often a form of avoidance. Simplicity makes it harder to stall.

“We tried once, and it faded out.”

Cultures are built on routines, not one-offs. Some practical tricks:

Fix a cadence (monthly, quarterly) and stick to it, even if attendance dips.
Rotate ownership so one person doesn’t burn out.
Keep formats lightweight, so they survive busy periods.

And then there’s the least glamorous but very real advice: “SPAM, SPAM, SPAM”.

Announce the session early.
Remind people a week before, a day before, and an hour before.
Share highlights afterwards so even those who didn’t attend feel the impact.

Visibility is part of the work. If people don’t know learning is happening, it might as well not exist.

The real takeaway: culture is people

One of the final slides of the talk distilled it into a single line:

Culture of [whatever] is about people.

You can have all the posters, values, and roadmaps you want.
If people don’t feel:

Safe to admit what they don’t know,
Encouraged to experiment and share,
Recognized for teaching others,

…then you don’t have a culture of learning. You have a culture of slogans.

So if you want to start or strengthen a learning culture inside your company, you don’t need a huge program. You need:

One initiative you can start in the next month.
One ally who cares as much as you do.
One routine that turns learning from a wish into a habit.

From there, let people shape it. As Mancuso suggests, the goal isn’t for managers to choreograph every learning activity. The goal is to empower developers (and everyone around them) to create their own culture of learning, and to know the organization has their back.

That’s where passion, innovation, and real change actually come from.

You made it this far, so I’m guessing this topic matters to you as much as it does to me. If you want more stories, experiments, and behind-the-scenes looks at how we’re building our learning culture, keep an eye on our tech blog and have a look at our career site to see how we’re growing the team. And if you’re already running your own learning practices, share them with your colleagues, your community, or even with us in the comments below.

Engineering

We are creators! From designing ground-breaking products to finding unique ways to solve technical challenges at an…

bit.ly

The more we learn from each other, the better our cultures get.