I’ve been thinking a lot about organizational design recently, and upon deeper reflection my approaches to date have been about as original as potato salad at a potluck. In my defense however, I was raised by corporate
I was taught that there are three ways a company is organized. These three can be combined into a dizzying number of variants, but at the end of the day – all are based on these three:
1. By Output. In the software services business this is the project team so aligned to create custom software.
2. By Customer. Typical in the sales or marketing side of an organization, this includes organization by region and by brand.
3. By Discipline. Centralizing all software engineers into one organization, for example, creates opportunities for collaboration and reuse: although you’d best steer clear of that group’s holiday party.
That’s it. One organization I worked at was the typical hierarchy organized by discipline. There were the software engineers, the designers, the 3-D modelers, the sales team, etc. It was simple. Unfortunately collaboration between groups only occurred haphazardly through informal social networks, “Really? I too, enjoy baking marzipan cookies in my spare time.”
Kurt Vonnegut described collaboration as doing God’s work without ever knowing it, and attributes it to those informal social networks that evolve in spite of a bureaucracy. He called this the karaas. On the other hand, he reserved the term granfalloon for those bureaucratic endeavors that are stodgy and completely ineffective. Anyone who has had to navigate a large organization can attest to the necessity of the karaas and the comically ineffective aspects of the granfalloon.
My next corporate environment was organized in a matrix. Software engineers were led by a Chief (later changed to Director) as were project managers, client executives, quality assurance, web developers, etc. All worked on project teams (the other dimension of the matrix: output). This often led to competing priorities and the associated drama. Time that would have been better spent baking marzipan cookies.
As my current company, Tacit Knowledge, continued to grow we were faced with the scaling issues associated with all flat structures. We had to reorganize, and I made the same tired mistakes as thousands before me. We experimented with a matrix organized by discipline and by output. Issue is we are 65 people spread across 4 offices and 3 countries. Some of our clients require teams to be onsite – which adds another 4 locales to the mix. How do you sustain this kind of organization without proximity?
Sure, we use a wiki and issue tracking religiously. We pay the 10 minute screen share tax at the beginning of every meeting. We’ve got our campfire spaces and Google docs, instant messaging and e-mail. But all of these tools were bolted on the same organizational structures. We were using these tools to enable the granfalloon. These tools worked great in support of projects, but in support of the organization they devolved into a portal to find contact information and HR policies. What was missing?
As I thought about this problem more, I began to finally get it. I had not applied any of the lessons I learned designing an online community: the human element. People with common interests define a community. Those interests can be in a particular project, in sales, in Agile software development, in Ruby on Rails, in e-commerce – you name it. We needed to use these tools for the benefit of the karaas. More specifically, we needed to support communities in places where a nexus between company strategic goals and a pervasive human interest existed – then get out of the way.
We are just starting to put some of these into practice so I’ll keep you all appraised as to what works and what doesn’t. Here are the 8 principals we are applying to shape these communities and empower them. I’ll use Agile software development as a concrete example:
1. Common interest exists: Agile. One or more passionate evangelists are also required.
2. A mission statement established through consensus: to be viewed as thought leaders in applying Agile methods, and to bring real innovation to the broader community via experience on projects.
3. Rules for consensus-based decision making: the conference sponsorship budget is allocated based on a weighted vote – where members are given more clout based on their successful participation in the community.
4. Principals for self organizing: for example, are there pre-requisites to join the community? Invite-only? Tacit Knowledge employee-only? Certification in an Agile methodology like SCRUM?
5. Make it a game. Fame in the community is rewarded by valued contributions to the community. Your most junior employee can win the game. There is no hierarchy. For example, expertise is awarded based on blogging, conference attendance, public speaking, community involvement, etc.
6.
7. Meet Up. A weekly meeting with a tight but flexible agenda is useful and sustainable.
8. Shared Content. Tagging content with one or more internal community names (e.g. “Agile”) is a good way to cross-purpose a blog entry or similar so that content can be cross-linked and discovered by all within the organization.
We have had one of these communities online for a few months – so far so good. We have a functioning weekly call, some custom workflow in Jira, strategy alignment across offices, and much more visibility then was previously the case. In short order, we will kick off a couple more. So far we have 8 in mind. The current plan is to use these communities as a replacement for one side of the traditional matrix. The difference is that their establishment is not a function of reductionism: we are not trying to sub-divide humans into specialties. The communities are instead oriented around a shared interest and a broad mandate.
One analogy is the infamous Task Force. I’ve seen companies create task forces when their organizations will simply not support the delivery of a business priority in a timely way. Put differently, they are a crutch that supports organizational dysfunction by working around it. The community analogy is relevant in that both task forces and communities are established around a set of discrete business objectives as opposed to those company organs resulting from organizational reductionism.
Communities are also very different. They are characterized by longer-lived mandates. They are self-organized, and they come with a built in system of recognition that replaces top-down managerial oversight. They also grow organically: a community’s size will wax and wane based on its appeal to the participants and its perceived utility. One can participate in multiple communities or none at all.
I believe it is the application of these organizational changes that will be the real story behind
