Thursday, August 23, 2007


bug eyesLarge organizations have a problem. It's a hard problem to solve. That is, how do you organize the division of labor when you have a large number of people? It's not a new problem. Sun Tzu's The Art of War covers it. The general was asked, "How large an army can you command?". His answer was "the larger the better". Old problem but solved.

People tend to learn new skills fairly slowly, so it is commonly thought that no one knows how to do everything. In any case, the large organization tends to discover, often by luck, that a person knows how to do some specific task, and then uses them for that one task exclusively. As the organization gets larger, groups of people form to perform specific tasks, and the organization tends to treat these the same as individuals, performing one task forever.

The large organization then takes these task groups and establishes processes that let the groups get things done together. When there is a complaint that the process isn't written down, it tends to get written, and becomes less flexible. When problems of quality arise, and let's face it, humans make mistakes, the reaction is to manage quality by requiring that a high level manager signs off on actions. But these people don't know how to do everything, so they don't know how to judge quality. They become a source of latency for projects, with no added value. Management thinks in terms of paper trails, and requires paper documents for everything.

The ebb and flow of work to do means that some task groups feel overloaded from time to time. They set up often elaborate queues where tasks are submitted, and 'customers' are given a minimum wait to get things done. For example, a database administration group may require a minimum of a week for any task - even if the task requires no analysis, no research, no diagnosis, just a simple command sent to the software. Often, these groups require that there is no face to face or even phone contact, and miscommunications are frequent, requiring resubmission of the task, with attendant latency.

So, let's say you're a developer, and the project is to project a web based application. Checking your source into the source tree requires sign off from the source code control group. Placing the application on the server requires sign off from the hardware and web server software groups. The database administrators need to sign off on the way the database is used, even if there are no new tables. The help text for your application is managed by yet another group. The application took a week to write, but takes an additional six weeks to deploy, if you're lucky.

How can this be fixed? Instead of attempting to manage quality by instituting sign offs by management enforced by restricted access to systems, the trend should be to manage quality by automated paper trails, with automated back-out systems for failure mitigation. The emphasis is on automation to reduce latency. Empower the developer to get things done by giving them the tools needed to get the entire job done. Trust that the developer will attempt to do the right thing, but don't be afraid of failure. Fear of failure causes paralysis.

There are a complicated set of issues. For brevity, this is just one of them.

No comments: