Friday, January 8, 2010

Organizational Optimization

I'm not an expert in business organization design or organizational optimization, though have been an active decision-maker in a few organization redesigns and layoffs (I'm sad to say the latter).  It seems to me that the rules of what a business looks like, organizationally, could follow some of the same basic guidelines that enterprise architects and software architects use for the design of a large system of applications.

Clarity of Purpose
A business unit must have a well defined purpose.  It should be clear to the rest of the organization what the function of the business unit it is, so that other business units know when to engage with it, what information it has/creates/uses, and what purpose it serves.

Well Defined Interface
A business unit must be clear to the larger organization on how to interact with it and expectations the organization may have with regard to service completion time or delivery schedule.

A business unit must be able to readily respond to questions about its value to the bottom-line performance and goals of the larger organization.  If it's value is not sufficient to outweigh alternatives, then it is irresponsible to continue to use it.  The lower cost alternatives should be used.

A business unit should either be self-sufficient enough to achieve its purpose alone, have plentiful access to external services such that they are unlikely to be a limiting reagent, or have sufficient influence over the priorities of external services such that they will not hinder progress.  If the business unit is unable to make those conditions occur, then it will suffer from inefficiencies and risk not being able to achieve it's goals.

I think that's very consistent with system/software engineering principles laid out in the Unix philosophy.
  • Do one thing and do it well.
  • Write programs that work well  together.
  • Data dominates. If you have chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
  • Fold knowledge into data.
  • Design for simplicity.  Add complexity only when you must.
The time-value curve also could be use to help design organization principle.
  • Organizational structure should optimize the amount of time between an event and the decision making and action that will result from that event (opportunity is lost in the interim).


  1. Great post Paul. I would also add that if a new unit is formed (similar to a new application), then that unit should be reviewed early (and often) to ensure the strategic objectives are being met. Sure the unit will achieve things, they will even have success, but if they are not monitored closely, they can (and sometimes do) stray from the original objectives. This is especially true when different personalities and personal agendas come into play.

  2. The engineer and introvert in me wants to say "too bad personalities and personal agendas" ever come into play at all, but of course they do.

    You make a great point that no business unit can be left unaccountable to clearly defined and well understood strategic objectives. With BI-related groups that can often be a case of "eating your own dogfood." BI groups go around measuring the performance of other teams, but fail to articulate the benefit their existance brings to the organization.