Seven Sevens

Tonight I had dinner with an old friend and a group of young Drupal architects. Their company, Lullabot, has enjoyed great success, and they described how it grew organically from the two founders to an organization of about a dozen rockstars. At that point I reflexively said, 'Stop at 45!'

The 'Bots were understandably curious about that arbitrary number, so I explained how I have been a member of several startups- all of which ceased to be 'fun' places to work around when they crossed the 50 person mark. However, I couldn't exactly target why this was the case.

Further discussion and subsequent pondering led me to a realization that 50 is just a hair over seven groups of seven. There seems to be something resonant about the number seven in the human calculus; besides all the seven references in our culture (seven days a week, seven seas, seven years bad luck) there also appears to be a hardwired capacity to manage information in groups of seven. Usability professionals speak of the (sometimes derided) 'seven plus or minus two' rule when designing interactive experiences- a menu with three items seems like too few to be consequential, whereas a side nav with twenty items is an overbearing list.

Just as web designers tune their sitemaps to achieve perceptual comfort in their information architecture, it appears humans prefer to build their social structures in similar fashion when creating organizations where interdepartmental communication is important. The department I am currently part of, while a sub group of a much larger organization, operates in a close-knit startup fashion- and yes, there are eight sub groups, each with roughly 5-9 employees (Two of the smaller groups could arguably be lumped into a single function if not for the presence of two VPs in the top roles, thus crowding what would otherwise be a streamlined org, bringing us down to seven groups).

Like a burgeoning website losing the familiar and personal touch of its quaint beta days when it begins to add more sections and navigation layers, a company that expands beyond the seven sevens becomes too large to be your extended family anymore. You cease getting to know new employees personally, and start to define them via their job functions first and personalities second. You pine for the 'good old days,' when things seemed less complicated even though the workload was proportionately higher. You tighten your circle of mental responsibility to those in your department, and suddenly you're not pulling for the company as a whole, but for the success of your circle vs. those in that other, suddenly foreign department.

These small association groups can be extremely powerful- enough so to jump apparent gaps, like an electrical spark. My small division has been thrown into the mix of a joint venture between my company and a traditional competitor- yet the virtual teams have melded together into strong working groups of about- yep- seven full time individuals (I have a hilariously uniform org chart devised by a consultant who I suspect did not ponder the metaphysical implications of their perfectly aligned Excel spreadsheet).

So it's all well and good when we can organize according to our psychological imperative- how touchy feely. What happens when this guideline breaks? My experience shows that it creates a flawed organization.

In my previous job, my boss received instructions from above to maintain a 'flat' organization- reduce the number of levels between him and the lowest employee, in an effort to reduce bureaucracy and increase accountability. As a result, he ended up with 18 direct reports- all of them design managers rolling up to his VP level position.

Each of these managers, in turn, led a team of one to three designers, each dedicated to a particular business unit in the company. The result was nearly universal dissatisfaction- operating in micro-teams, the designers had no clear relief when their workload exploded; two more hands on each team would have led to more psychological comfort that help was available for those overflow events.

Meanwhile, the eighteen design managers had less than 15 minutes a week of interaction with their manager, whose communications would often come in the form of late night email responses to inquiries sent weeks before and likely outdated by the time of reply. Finally, the VP himself was run ragged, exhausted by having to keep track of 18 teams worth of status and continually falling behind on tasks both mundane and important- he simply had too much on his plate. Additionally, he wasn't doing his career any favors, because he never had the time or mental bandwidth to demonstrate to *his* boss that he could be a strategic leader instead of a frantic email responder.

The ultimate conclusion? The entire department was killed in a fiery bus crash when the VP fell asleep at the wheel. Actually, nothing that dramatic- the VP asked for and received permission to reorganize his department, raise a couple of lieutenants to Director level, and restore harmony and balance by moving to a more reasonable number of subgroups to manage (I'll let you guess the number). I hear it's a much nicer place to work nowadays.

The next time I have to design a department org chart maybe I'll apply some guidelines based on this seven sevens concept- and decree that managers and directors can have no more than seven directs and seconds, and VPs can have no more than seven directs. It may lead to some interesting dynamics and efficiencies in organizations where problems are typically solved by throwing bodies at a them- if a manager knows they only have a limited number of resources, I bet they'll make sure they have the strongest candidates possible in place, and be more vocal about copping to their limitations and asking for cross departmental help or relief when faced with a sudden overflow situation.

Would such a structured and rigid policy be a help or a hindrance to organizational success? I suspect the former, as project failures are usually attributable to human inabilities to recognize self-limitations. Perhaps by imposing ground rules that restrict us to our psychological comfort zones we can reduce that source of project uncertainty and failure.

At the very least, it will result in some very pretty org charts.