Weather permitting, the Netscape pick-up roller hockey game has been played every Saturday since 1996. 14 years. This hockey game has outlasted all but one of my former employers.
This is pick-up hockey. If you were to arrive with skates, stick and protective gear, you would discover a chill game where the expectation is that you’re going to sit, stare at the game for a few minutes, figure out the rules, and then start playing.
This is chill hockey. We don’t keep score. There is bumping and nudging, but rarely a fight, and the rules few:
- Offsides are enforced.
- If the puck leaves the surface, whoever gets it, gets to play it.
- Don’t be a jerk.
Hockey has a slew of other rules regarding tripping, high sticking, and cross-checking, but in the pick-up game, those rules fall under #3 — don’t be a jerk. When new individual players arrive and they deviate from these rules, they are quickly and efficiently educated. Yeah, we don’t play that way.
This was organically understood until Campbell showed up.
The Campbell game wasn’t 14 years old, but it had been around. I’d played at their converted parking lot a few times. Slightly faster game, more testosterone, and a bit more yelling, but most certainly hockey.
The Campbell game was shut down when their parking lot vanished. We’d seen the occasional Campbell player at the Netscape game, but when their rink vanished, they showed up en masse and that’s when our game went to hell.
In a game where I could count the number of fights in a decade on a single hand, we had two fights in a day. Arguments erupted regarding offside enforcement, whether to use a puck or a ball, the proper timing of line changes — it was a mess. What had been a decade of reasonably chill hockey transformed into a tension-filled game where we were suddenly… keeping score?
The reason the chill hockey game remained so for so long was due to social momentum. The collective will of the 14 veteran players already on the rink far outweighed the will of Joe the New Guy. When he showed up, he listened, he watched, and he quickly discerned the rules of our game because he wanted to play.
When 14 Campbell players showed up on the same Saturday morning, they brought the Different and the manpower to enforce it. It’s not that they didn’t care about local customs, they were willing to adapt, but there was enough of them to represent their version of the Different so they had less incentive to adapt, so arguments and fights erupted regarding unspoken rules.
As Keeper of the Chill, your role as a manager or just the guy who wants the game to go down without fisticuffs requires you not only to publicly define the rules, but also understand why they exist and how they evolve.
Whether it’s one person or many, when new folks join the team, they are in social shock. Everywhere they look, there are new faces that are speaking a strange language full of curious proper nouns and baffling acronyms. Every single detail is slightly, annoyingly, and uncomfortably different.
In an environment where everything is new, a short set of rules can go a long way to giving new recruits both structure and context about their new home. These rules are designed to give the new folks a basic operating manual for the team to make everyone’s day a little easier.
Now, I have an irrational knee jerk reaction to bad rules. In my head, a rule says, “You, sir, you can’t do your own thing. You must do it this way,” and that is not what a good rule embodies. My negative reaction is due to rule abuse. See, I’m a nerd and I’m predisposed to fucking love rules because a logical and well-followed rule keeps the well-defined system functioning smoothly. It keeps us on the same page, it sets expectations, and it makes the world a more predictable place.
Problem is, people abuse rules. They think because they have authority, they can define a rule to support their particular agenda. People think “This is way we’ve always done it” is a reason to continue to do so in perpetuity. When these folks are cornered and asked, “Why does this rule exist?” we all discover their unsatisfying crappy answer and rules get a bad rep.
A Defensible Rule
My first bit of advice in defining a rule set is to not get lost in the process. You’re likely already a company of 10 or more people, and many of these rules are already understood by the existing team — they are part of your DNA. You do not need to form a committee and schedule seven meetings in order to define a good set of operating rules. In fact, I see no reason why you shouldn’t be able to spin around in your chair and starting writing them on the nearest whiteboard:
- Anyone who interviews a candidate can veto the hire.
- We leave it to the developer to decide when they need a code review, but when they break the build, they’re in the code review penalty box.
- If you have questions about the development environment, you look at the wiki before you spam the mailing list. When you find the answer to your question, you update the wiki.
These are examples off the top of my head and may not apply to your development organization. Just as each team has a different vibe, so will they have different rules, but as you’re considering your list, think about this:
- In your day, where are there points of friction?
- Where would clarity make you less angry?
- What critical parts of the day need to be explicit?
- Where does the team constantly screw up?
- What meeting do you repeatedly have that could be killed by simply defining a rule?
For items on this list, you have two sanity checks.
#1 Is this rule defensible? Can you explain in great detail to anyone who wants to know the current and relevant reasoning for this rule? The reason every single bug has an assigned milestone is so that we know when we expect to address it. A blank milestone not only means we don’t know when the issues will be addressed, it means no one has taken the time to triage the issue and make a call. We value completeness and quality.
#2 Is this rule obvious? You’ll know you’ve hit the mark on a rule by vetting it with the existing team. If you’ve successful defined the rule, their reaction will be, “Duh, everyone knows that”.
Values, Not Rules
It’s worth noting that in many years of software development, I’ve never seen this type of list written down. The unspoken expectation is that new hires are expected to discover and understand this list via social osmosis. As a means of understanding a team, it’s an essential exercise, but defining this list does not replace the exercise of discovering what it means.
These rules are your values. These rules might not be mission statement-worthy, but then again, you’re not defining these at the senior management junket at the Half Moon Bay Ritz-Carlton. These are rules that affect your every day.
– Anyone who interviews a candidate can veto the hire — We value everyone’s opinion. We take hiring seriously. If you’re part of the interview team, you’re responsible for building this company.
– We leave it to the developer to decide when they need a code review, but when they break the build, they’re in the code review penalty box. We value your judgement and we understand that people make mistakes. If you make one of these mistakes, we’re taking reasonable action to prevent future mistakes because your daily actions affect the productivity of the entire team and the quality of product.
– If you have questions about the development environment, you look at the wiki before you spam the mailing list. When you find the answer to your question, you update the wiki. We value communication and we value efficiency. While we want you to move as quickly as possible, we document our collective knowledge because documentation scales better than our time.
Just because you made a list of rules doesn’t mean you’ve explained their value. The new folks still have to discern from the group why the rules matter. In the meantime, these rules keep them on the rails.
They Didn’t Know
After a particularly feisty Saturday game, I typed up the rules for the hockey game and stapled a copy to each of the benches:
- We play with offsides. If you don’t know what offside is, ask.
- We don’t do timed line changes, skate hard and then give someone else a chance.
- If the puck leaves the surface, whoever retrieves it gets to play it.
- Don’t fight. This is pick-up hockey.
Rules are not constraints, they are optimizations and they are clarifications. They are designed to describe what is possible or allowable and rules are not fixed in stone. When Campbell showed up the next week, we didn’t keep score, but after two weeks of ignoring the guy who compulsively and vocally kept score, we discovered a new rule — keeping score is more fun.
Leave a Reply