When she was a teacher, on the first day of each class, Lauren, my wife, would start the year with a simple activity. She sat her first or second greaters down around a big sheet of paper, hung on the wall.

“Class”, she'd say, “it's time to go over our classroom rules for this year.”

Her cute little classroom

But, instead of writing her rules on the paper, she'd continue, “What would you like our rules to be?”

What do you think those first and second graders came up with?

“Unlimited Recess”, “No rules!", or “Free ice cream every day”?

Contrary to what you might expect, those kids chose some very mature rules.

These days, I use this strategy with my kids before we start a big activity. Last time we went to the Natural Hustory Museum, I asked them what our rules should be. They chose “stay together”, “walk, don't run”, “be calm”, “don't break stuff”. I, of course, added the most important rule of all: “have fun”!

Getting chased by a T-Rex at the Natural History Museum

I've found that when they choose the rules, they are more likely to remember and abide by them. Also, if they thought of a particular rule, they even remind each other of the rules. If Max, my oldest daughter, came up with “walk, don't run”, then she'll probably call her little brother out if he's running all over the place.

It turns out, we do better when we get to shape the environment that we're working with.

About a year ago, I joined a newly formed team. Some of us had worked together before, but many had not.

I suggested the first thing we do is decide how we'd like to work together.

We whipped up a Miro board to facilitate the process.

We wrote down:

  1. What things do we do?
  2. How do we do it now (if there is a process)?
  3. Who does it?
  4. How would we like to do it going forward?

We discussed many of the mundane (but important!), daily software engineering tasks. This included things like how we make changes, how we test them, how we ask for help, how we resolve issues, and more.

After we finished, to help us remember what we decided, our Project Manager created a summary doc that we added to our team's doc site.

So, how did it go?

Immediately after the process, I heard from the engineers on my team. They said they felt much better about the team and the work, that they felt like expectations were now much clearer.

As time has passed, and I can reflect on the first year of our team, I feel that we've stuck pretty closely to what we wrote down in that Miro board, and that we've had a very successful and productive year.

I think the key point is that each engineer got to decide how we'll work. This wasn't a decree from their manager or me, the tech lead. It was a collaborative process that allowed everyone to influence how our team operates.

Not everything benefits from a collaborative process. That's why we disparage certain products saying things like, “It was clearly designed by committee”. But when it comes to how we work, I think we all do better when we have a hand in shaping the environment.