Culture can be top down, or bottom up. The big commandments come from on high (“Speed wins!” “Done is better than perfect!” “Don’t be evil!” “Worse is better!”), and everyone scurries to figure out what they mean and how to make them happen. Eventually, a company will settle into a rhythm (hopefully sounding more like a luxury sedan, less like an unbalanced washing machine), developing official and unofficial ways of getting things done.

Some of these lower-case-m methodologies will be stolen from upper-case-M methodologies, others created from whole cloth; some will be well-defined, others reflexive and unrecognized; some will be universally applicable, others limited to specific teams; some will be mandated, others spontaneously arise.

As part of my reading group’s discussion around The Power of Habit, we’ve been thinking about some of the habits (or, really, customs) we’ve developed over the years. What struck me was how mundane they were, little things we’d tried once upon a time, now a normal part of our process. And maybe that’s the point. Big processes have to be documented and enforced. Customs are used only as necessary, and are self-reinforcing.

Here are some of the things we’ve come up with over the years.

• Three ship-its

Once upon a time, we required developers on a specific team to get code reviews and sign off from three people before committing. This was in response to quality concerns – but while it seemed a bit heavy-handed at the time, it was so popular and effective that, with a tweak here and there, it was soon adopted by many other teams.

• Bug hunts

Another time, another team, another set of quality issues, but this time we decided to get the whole team – developers, PMs, designers – together once a week to bang on the code over lunch. It wasn’t always fun, but it was effective, a surprisingly good team bonding experience, and frequently found critical errors prior to launch. Now it’s just one more tool in the arsenal – some teams do them regularly, others rely on them for special occasions.

• Book groups

As we approached the summer a couple years back, we realized with horror that we were about to be flooded with interns, to the tune of about half our full-time engineers. We’d had a high bar during the interview process, but no experience integrating anywhere near that many people at once. We tried lots of things to get them up to speed quickly, one of which was to get each of them a copy of Effective Java and organize weekly book groups. It soon became clear that there was interest among the full-timers as well, and book groups on a variety of topics, technical and otherwise, quickly spread throughout the engineering organization. Now, it’s just a normal feature of the company.

• Manager lunches

When a company is small, everyone in a particular stratum knows one other. But as an organization grows, new business units form, people specialize, and useful knowledge languishes in silos. Getting all (or most) of the managers together for a quarterly lunch turned out to be a good way to keep people in different parts of the organization (and different buildings) in touch. Speaking of which, time to start scheduling the next one…

• Team swaps

Swaps have been one of the most effective ways I’ve seen to bring someone up to speed quickly. The engineer has to be highly motivated (you can’t just assign them randomly), and a longer timeframe usually seems to work better, but working on an alien set of code is a great way to jolt someone out of a rut.

• Slice-a-thons

Our initial attempts at hackathons were a bit feeble. Engineers would spend a day working on something that might be personally interesting, but which almost always ended up being thrown away. One team, though, had the clever idea to mix things up a bit. Each developer worked with a PM to come up with a change that could be completed in a day, and then – crucially – each project got a “slice” of several percentage points of traffic. Some projects had pretty amazing improvements to conversion, and these stayed in. Slice-a-thons unfortunately never caught on more widely, but the next time I do a hackathon, this will be the model I’ll follow.

What are some of your favorite local customs?

Follow me on Twitter