Is it okay to learn on the clock? The version I’d defend — and the version that looks like slacking

Every team I have joined had an unspoken rule about learning. Some teams treated weekday deep work on a new tool as stewardship. Others treated anything that was not a ticket as theft. Both cultures used the same sentence — “we invest in people” — and meant opposite things.

I have been on both sides of the guilt. I have closed a laptop at 6 p.m. knowing I needed to learn a datastore I was about to own, then stayed up until midnight “so I wasn’t stealing time.” I have also watched engineers disappear into tutorial loops for three days while a production footgun waited in the same repo. The question is not whether learning on the clock is moral. The question is which version you can defend to a teammate who is carrying the pager.

Here is the version I would defend as a manager and as an IC — and the version I would interrupt.

The version that looks like slacking

Learning becomes slacking when it is unbounded, unshared, and disconnected from the work the team already owes.

The pattern is familiar. Someone picks a course because it is popular. They block mornings for “upskilling.” They produce notes nobody else will read. The sprint still has a migration that needs a real owner. When you ask what changed in the codebase, the answer is a bookmark folder.

I do not mind curiosity. I mind curiosity that never collides with a commitment. If your learning cannot name the risk it reduces, the feature it unblocks, or the person it makes less lonely on-call, it is a hobby wearing a corporate badge.

Other tells:

• You only study topics that feel prestigious, never the messy system you already own.
• You refuse pairing because “I need focus time to learn,” then cannot explain the system in a design review.
• You treat every bug as an excuse to rewrite in a stack you want on your résumé.
• Nobody on the team could say, without asking you, what you are trying to get better at this month.

That last one matters. Private learning plans are fine. Secret learning plans that collide with shared deadlines are how trust erodes.

The version I would defend

Learning on the clock is legitimate when it is attached to owned work, time-boxed, and made useful to more than one person.

The cleanest version looks boring. You are about to take a service that uses a queue you have never operated. You spend two focused hours reading the runbook, reproducing a failure in staging, and writing three bullets in the team channel: what surprised you, what you still do not trust, and what you will try next. That is not slacking. That is doing the job with your eyes open.

I also defend learning that reduces future coordination cost. If three people will touch Terraform next quarter, one person spending an afternoon building a tiny example module and a demo notes page is cheaper than three separate panic sessions later. The accounting trick is to treat that afternoon as product work for the team’s ability to ship — because that is what it is.

Make the contract explicit

Most conflict about learning is a contract problem disguised as a culture problem. Managers say “grow,” then reward only closed tickets. Engineers hear “grow,” then feel punished for anything that is not a story point.

If I am managing, I make three things explicit:

1. What learning is expected for the role. Owning a service implies learning its failure modes. That is not optional personal development. It is the job.
2. How much protected time exists. A default I like: up to a half day a week for deliberate practice tied to current or near-term ownership, unless an incident or launch says otherwise. Not a sacred entitlement. A default.
3. What “done” looks like. A short writeup, a paired walkthrough, a staging experiment, or a checklist improvement. If learning leaves no artifact, it is hard to defend when the week gets ugly.

If I am an IC and my manager will not make that contract, I still make one for myself and say it out loud. “I am spending Tuesday morning on the payment retry path because I am on-call next week” is a sentence that invites support. “I am taking Tuesday for growth” invites suspicion.

Learning that belongs after hours — and learning that should not

I am not anti night study. Some deep reading is easier when Slack is quiet. Certifications, long courses, and career bets that are mostly about your next job often belong to you, not to the sprint.

What I refuse to romanticize is the culture that pushes all learning past 10 p.m. and then congratulates people for grit. That culture selects for people without caregiving loads, without health limits, and without a life. It also creates a quiet lie: the company gets the upside of skills while pretending it did not buy them with unpaid evenings.

If the skill is required to do the job safely, it belongs on the clock. If the skill is a personal bet, evenings are fair. If you cannot tell which is which, ask whether you would still need the skill if you stayed on this team for two more years. Required for the seat: clock. Optional résumé garnish: your time.

How I coach the gray area

Most real weeks are gray. You need to learn ClickHouse enough to stop guessing. You also have a release. Here is how I navigate that without becoming a process priest.

Attach learning to a near commit. “I need two hours before I touch the migration” is easier to schedule than “I need to get better at databases.”

Prefer learning in the path of work. Reading production metrics, writing a failing test, or restoring a backup in staging beats another abstract course module.

Share the residue. A five-bullet note in the team doc turns private progress into team memory. That is how you earn the next block of time.

Cut scenic routes. If the ticket needs a correct index, do not “learn” by rewriting the service in a new framework. That is career cosplay.

Watch for learning as avoidance. When feedback is hard or a design is contested, some of us suddenly need a week of tutorials. I have done that. The fix is not more content. The fix is the conversation.

What I tell juniors and what I tell seniors

To juniors: you are not stealing when you ask for time to understand a system you are expected to own. You are stealing when you hide confusion until it becomes an outage. Ask early. Write what you learned. Invite a second set of eyes.

To seniors: your highest-leverage learning is often teaching. Pairing, reviewing with explanation, and leaving better runbooks compounds more than another private deep dive into a tool you will not put into production this year. Also, model the contract. If you only learn at midnight, the team will copy the midnight part and miss the judgment part.

A simple test before you block the afternoon

Before I block learning time, I ask four questions:

1. What decision or risk gets cheaper if I learn this now?
2. What artifact will exist by the end of the block?
3. Who else benefits if I share it?
4. What committed work moves, waits, or gets covered while I do this?

If I cannot answer those without squirming, I am probably about to slack with better branding. If I can answer them cleanly, I defend the block — to my manager, to my teammates, and to myself when guilt shows up anyway.

Is it okay to learn on the clock? Yes — when learning is how you keep the promises the team already made. No — when learning is how you avoid them. The adult version is not endless hustle after dinner, and it is not unbounded tutorial mornings. It is explicit ownership, bounded time, and residue the next person can use.