As a company, how do we keep the right hand knowing what the left hand is doing? And for that matter, how about the rest of the body?
Scholastica was founded by three people, and when we started it was easy to keep everyone in the loop. As we’ve grown, we’ve experienced the common challenge of keeping everyone in the loop without adding long meetings or time-consuming email updates.
I wanted to share an experiment we’ve been trying to keep information flowing across company areas: weekly company-wide pairing, which we call Pairing Thursdays.
The problem of growth and communication
As companies grow, it’s easy for information to spread more slowly. This can be because the overall volume of information increases so it’s harder for individual employees to stay abreast of everything happening in the company, or because the ‘information silo’ effect comes into play as within-department colleagues communicate more frequently and subsequently reduce communication with other departments.
At Scholastica, we use formal information sharing via email and Basecamp threads, as well as the old low-tech fallback of the spoken word. Even with these communication methods, though, we’ve seen a trend towards sharing summary information, while when there were only 3 people there was more sharing of rich details that stuck in our minds, things like the way a feature request was worded or the first name of a particular customer. I think we all understand that you can’t know every detail about everything in the company and that general information is efficient for keeping up-to-date, but the loss of these shared rich details altogether seemed bad.
I also remembered seeing many positive effects of serendipitous information sharing between departments: customer support happens to know about a potential bug and so responds to a customer issue extremely quickly, sales learns about a features real users love and emphasizes those features more, marketing gets an idea for a great campaign because of a seemingly random bit of customer feedback. These sorts of unexpected outcomes often come from information sharing that is unplanned yet rich: overhearing conversations, chatting at lunch, proofreading an email response.
So what could we do?
Pair programming as a model
As a tech company, we’ve tried to translate many of the Agile development tools designed to help with writing code into all areas of our business: daily scrum, two-week iterations, use of Kanban boards, story-based prioritizing.
We also use pair programming, an oft-cited characteristic of both Agile and Extreme Programming. Two software engineers look at the same screen and take turn manning the keyboard, and problem solve as they write code. This helps junior developers learn to code better, and helps even senior developers solve very challenging problems on the fly.
There are two other benefits from pair programming that we really liked, and wanted to translate to other non-technical parts of the business:
- increased [code] quality
- better diffusion of knowledge among the team
Our ideal was that every part of the business would get more eyes on the work to increase the overall quality of work being done, and help people in unrelated areas of the business get a meaningful glimpse of everything else going on in Scholastica.
In the end, we decided to experiment with transporting the pair programming model to the company as a whole, and came up with Pairing Thursdays.
Pairing Thursdays: How it works
Early each week, we randomly select two-person teams. Throughout the week, each team decides what two projects they are going to work on (one project from each team member). On Thursday the pair then spends about 3 hours working together, usually evenly splitting the time between the two projects.
We’ve had some very disparate pairings: writing new Javascript and a marketing email; answering a customer support request and then debugging the problem in the code; wireframing future features and adjusting in-site rewards. We’ve had people who know nothing about code help write it, and team members who know nothing about marketing help research Twitter hashtags. We’ve had new team members help research sales strategy, and designers help write complex code.
And here’s the kicker: everyone seems to enjoy it. I think Pairing Thursdays are so much fun because everyone gets a weekly break from their normal routine, and it’s a chance to share a sphere of the business that you’ve mastered while also getting meaningful feedback on the fly.
Moving forward
As a company, we really value creating opportunities for the team to get rich glimpses of every aspect of the company. I want to emphasize glimpse because we decided that it wasn’t realistic (or even desirable) for everyone to work on everything all the time, but episodic exposure was better than no exposure at all.
I’ve noticed that over time, the pairing projects tend to focus more on beginning project (i.e. “let’s brainstorm this together”) rather than completing work-in-progress (i.e. “let’s work on my existing project”). I think early-stage discussions do add work variety for the team and equalizes the mastery difference between the team members for more generative discussions, but it might not serve the goal of exposing rich details as well as “getting into the weeds” of a person’s real daily work.
Whether the pairing is brainstorming or working out the nitty-girtty details, I think there’s value in me being exposed to how other team members think about problems in my space, and there’s value in me thinking about problems outside my normal routine – and both values are based in everyone understanding and thinking about the company as a coherent whole and not just their sub-domain.
I can’t wait for Thursday.
