Inspired by James' recent post Let Them Eat Data, which is about the many different ways organizations structure themselves poorly for data, I wanted to dig into the concept of organizational antipatterns.

I’m not a software developer, but I’ve had the good fortune of getting to spend a lot of time with smart coders over the years and I like to think a bit of their approach has rubbed off on me. While I’m not in the camp that says everyone should learn to write code, I do pretty firmly believe that there are a set of ideas in computer science and software development that would be helpful if they were more widely understood. These range from relatively simple concepts like how a database works (only simple because databases more or less work like Excel, which many people already understand), to some harder to grasp but important ideas like abstraction, which is essentially a process of generalizing something to make it easier to work with.

One helpful abstraction in the world of development is the idea of patterns. A pattern is not much more than a good approach to solving a particular type of problem. In web design, for instance, there are a whole host of design patterns that we rely on as users. These include breadcrumbing a page so you know where you came from and including a step count in a checkout process to know how much work is left. The pattern is a simple solution designers can rely on. It’s aided by a network effect: the more it’s used, the more we as users look for it, the more valuable the pattern becomes.

A pretty typical design pattern letting you know the steps ahead

While most people over the age of five are familiar with patterns, there's a related concepts that is far less well known. Antipattern was first coined in 1995 by the programmer Andrew Koenig, who explained, “An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one.” While Koenig was talking about antipatterns in the world of software development, I find myself thinking and discussing it most in the realm of organizational design. There are a set of organizational antipatterns that almost every company falls into and recognizing those ahead of time can hopefully help in avoiding them.

To give a sense of what those look like, here’s a subset of the Wikipedia list of organizational antipatterns:

  • Analysis paralysis: A project that has stalled in the analysis phase of development, and is unable to achieve support for any of the potential plans of its implementation
  • Bicycle shed: Giving disproportionate weight to trivial issues
  • Cash cow: A profitable legacy product that often leads to complacency about new products
  • Design by committee: The result of having many contributors to a design, but no unifying vision
  • Peter principle: Continually promoting otherwise well-performing employees up to a position they are unsuited for, with responsibilities they are incompetent at completing, where they remain indefinitely
  • Seagull management: Management in which managers only interact with employees when a problem arises, when they "fly in, make a lot of noise, dump on everyone, do not solve the problem, then fly out"
  • Stovepipe or Silos: An organizational structure of isolated or semi-isolated teams, in which too many communications take place up and down the hierarchy, rather than directly with other teams across the organization

There are lots more good ones, but you’ll surely recognize many from that list. Bicycle shedding is a favorite of mine. It originally comes from C Northcote Parkinson’s book Parkinson’s Law, where it’s told through a fictionalized meeting of a finance committee. Item nine on the committee’s agenda is approval for a $10,000,000 nuclear reactor. While there are a few murmurs and we’re told one of the few nuclear experts on the committee distrusts the round number, the item is approved in less than three minutes. Next up is item ten: a bicycle shed.

Chairman: Item Ten. Bicycle shed for the use of the clerical staff. An estimate has been received from Messrs. Bodger and Woodworm, who undertake to complete the work for the sum of $2350. Plans and specification are before you, gentlemen.

Mr. Softleigh: Surely, Mr. Chairman, this sum is excessive. I note that the roof is to be of aluminum. Would not asbestos be cheaper?

Mr. Holdfast: I agree with Mr. Softleigh about the cost, but the roof should, in my opinion, be of galvanized iron. I incline to think that the shed could be built for $2000, or even less.

Mr. Daring: I would go further, Mr. Chairman. I question whether this shed is really necessary. We do too much for our staff as it is. They are never satisfied, that is the trouble. They will be wanting garages next.

And so the anti-pattern of bike-shedding was named (but certainly not born). “A sum of $2350 is well within everybody’s comprehension,” Parkinson writes. “Everyone can visualize a bicycle shed. Discussion goes on, therefore, for forty-five minutes, with the possible result of saving some $300. Members at length sit back with a feeling of achievement.” Putting these items before the same committee seems like a reasonable approach, but as we’ve all probably experienced, Parkinson is exactly right in where the focus and time ends up being spent. It’s an organizational anti-pattern that if known ahead of time can be avoided.

Try the Variance customer growth platform

Join some of the world's top software companies that use Variance to power data-driven sales.
Get Started 🎉

Subscribe to Variance News

An inside look at building a company delivered in (roughly) bi-monthly installments

Thanks for signing up.
Look out for our newsletter!
Oops! Something went wrong while submitting the form.

Get to know Variance

We believe the best way to learn about a product is to read the documentation. Have a look around.

Explore our Docs