Pairing is a tool, not a mandate

SRT Solutions is a very collaborative environment. We enable our employees to choose the best way to collaborate. There are with a minimum number of rules and processes. If you’re in the Ann Arbor area, stop by.  We’d be happy to let you see what goes on inside. For those that can’t see us in person, you’ll see some people pairing. You’ll see some people pairing remotely with telecommuters. You’ll see teams working together in larger groups. You’ll also see people working on their own. Every one of those different styles is important.

  • People working in groups will likely be working on larger design or architecture tasks.
  • People working in pairs are probably implementing features or working on diagnosing issues.
  • People working on their own are doing detailed algorithm design, or implementing different features.

We use all these different working styles because no one configuration is perfect. Groups engender dynamic, thought-provoking ideas. We get brainstorming, new ideas, great innovations, and critical discussions. Pairing provides that extra pair of eyes, the constant review, and some knowledge transfer. Working alone is also important. Sometimes you need to think through a problem or a technique before you’re ready to share it with others.

An important result from working alone is that you gain deeper knowledge and confidence from performing tasks on your own. I see examples of this from my experience helping high school students with advanced math classes. My rule in any given session is that I do one problem, and only one problem for a student to explain a technique. After that one problem, they do all the work. I look over their shoulder, and provide some guidance if they make mistakes or get stuck, but I don’t ever take control and solve another problem.

That’s easy in a teaching session, because my only goal is that the student becomes self-sufficient. I have no deadline for finishing the problems. Sure, the student needs to turn in his homework, but I have no deliverables. I can look over a student’s shoulder for as long as it takes, my only goal is that the student grows her skills.

Contrast that relationship with two developers pairing on a feature. Because both developers have a shared deliverable (the feature), there is a natural motivation to put the keyboard in the hands of the person who will finish fastest. While one goal of pairing is to grow skills among team members, that goal is balanced against the goal of delivering software in a timely fashion. In fact, that second goal (delivering the software) often wins. The pair partner who has less knowledge about the task at hand can slowly become a passive partner.

That’s not to say that it always goes this way. Some people have strong enough personalities to ensure that they learn, and become proficient and productive without their pair partner. But, the risk is real, and it’s one reason why we allow people to work on their own some of the time, and to collaborate some of the time. You’ll learn, and grow different skills in each environment. 

We value both real collaboration, and real independent thought. That requires giving people the freedom to work collaboratively, the freedom to work independently, and the trust that everyone will recognize which is best at which time. It makes for a very dynamic workplace. People do collaborate much more often than they work alone. It also changes very quickly. Someone may work alone for a bit, and then as soon as they find they’d be more productive collaborating, they get up and find someone to join them.

Created: 4/14/2011 5:48:13 PM

Current Projects

I create content for .NET Core. My work appears in the .NET Core documentation site. I'm primarily responsible for the section that will help you learn C#.

All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.

I'm also the president of Humanitarian Toolbox. We build Open Source software that supports Humanitarian Disaster Relief efforts. We'd appreciate any help you can give to our projects. Look at our GitHub home page to see a list of our current projects. See what interests you, and dive in.

Or, if you have a group of volunteers, talk to us about hosting a codeathon event.