People ops · 3 min read
Learning out loud
We fund curiosity generously and share what we learn openly, because knowledge kept in one head helps one person and knowledge shared compounds.
We hire people who like getting better at things, and then we try hard not to get in the way of that. Two habits make this real: we fund learning without making you justify it, and we do our learning out loud, where it helps everyone. This is close to growing here, which is about your progression, and it draws on the learning budget, which is the money. This page is about the culture that ties them together: knowledge as something that flows, not something you hoard.
If it'll make you better, get it
Want a book? Buy it. A course, a tool, a conference ticket that'll teach you something real? Get that too. There's a budget for exactly this, and the point of it is that you don't have to write a business case to spend it. The approval overhead on a forty-dollar book costs more than the book, and worse, it teaches people not to bother. We'd rather trust your judgment and occasionally buy a book that didn't pan out than build a company where curiosity needs a signature.
No permission slips for learning
The default answer to "would this make me better at my job?" is yes, go. If a purchase is big enough to need a conversation, you'll know, and it's a quick one. Everything under that, just do it.
Learn out loud
The other half is what happens after you learn something. The instinct is to quietly file it away; the habit we want is to say it where others can hear it. A learning kept to yourself helped one person. The same thing shared, in a message, a show-and-tell, a blog post, helps everyone who reads it and keeps helping the next person who searches for it later.
This is the same reasoning as building in public, pointed inward. It costs you a few minutes to write up the thing you just figured out. It saves the next person the whole afternoon you just spent.
Rabbit holes are allowed
Not all learning is efficient, and some of the best of it looks like a detour. The deep dive into how something actually works, the weird side-quest, the afternoon spent understanding a system properly instead of just working around it: these pay off in ways you can't predict at the time and often can't trace afterward. We don't treat curiosity as time stolen from "real" work. A team that's allowed to go deep is a team that understands what it's building, and that understanding is where the good decisions come from.
Teach each other
The fastest way to find the holes in your own understanding is to explain the thing to someone else, so we make room for that: someone walking the team through a system they've gotten to know, a short write-up of a gnarly bug and what it taught us, an offer to pair with whoever's about to touch the scary part of the codebase. Teaching isn't a distraction from the work. It's how a small team stays smart in more than one head at a time, which is the only way a small team survives someone taking a vacation.