The article Four Financial Horsewomen Who Warned of the Apocalypse is a very interesting read. I recommend reading it even before I do any fact checking or delve into the reference links that the article provides.  Even if it proves not to be completely accurate, and I am not saying this will happen, it does provide a lot of food for thought.  What’s more it provides links to sites that might provide more interesting reading in the future including this site itself.

There are comments on this article at the Huffington Post.

As a software engineer I adopted the concept of top-down design of software.  I first read about this method in the early 1970s.  Essentially, you start by taking the statement of the problem and start from the top to break it down into smaller and smaller sub-problems.  The description of the design looks like a tree structure where the root of the tree is the module that solves the whole problem.  This module calls on various sub-modules that solve different sub-problems.

This technique can be thought of as an outgrowth of what I was taught in my early days at MIT. When given a tough exam question, first write down everything you know about subject of the question.  By the time you have finished writing down everything you know, you have either solved the problem or have found the direction to go to solve the problem.

When doing a top-down design, you make architectural decisions at the top that constrain what you must do at the lower level.  Many people objected to top-down design because they felt that you could not impose such constraints on the lower level before you knew what was possible to do at the lower level.

This objection comes from a misconception of how I believe a top-down design should be done in real life.

In reality, top-down design is a way of organizing the design process.  At every level, you give enough thought to the next lower level to be reasonably certain that the next lower level can in fact be implemented.  You may have to descend very far down the levels during the design phase to make certain that all your assumptions can be met.  The top-down design method is a way of organizing that descent so that it is focused on solving the top-level problem.

In the same way management decisions can be thought of as a top down design process.  The top manager, in consultation with others in the management team, breaks the problem down into sub-pieces.  No top level decision is made until there is reasonable certainty that the lower levels can do their part to accomplish the task.

So while the top manager (or top designer) guides the process using her or his own vision, nothing is cast in concrete without consultation with sub-managers (domain experts) to insure that the plan is feasible. This consultation process is where other ideas get raised that might lead to an even better solution than the manager originally envisioned.

This does not guarantee that the original plan will never have to undergo major restructuring during implementation, but it does attempt to minimze the chances of that happening. It minimizes the risk without paralyzing the effort to move forward.  If you insist on 100% guarantees, you will be too late to solve the problem (miss the market window).

A plan (or design) developed in this way ends up as also being a road-map to delegating tasks during operation (or implementation). This is what makes a project manageable when you shift from design to implementation.  Every member on the team knows what her or his responsibility is with sufficient detail, that the manager only has to manage by exception.  As long as things are verifiably following the plan, no drastic management action needs to take place.  Each manager can concentrate on the duties specifically needed to carry the plan forward.

Please think of the process described above when you think of President Obama working with the people of his administration and all the people in the country in coming up with solutions to all our problems.  Using this management style, nobody in the organization has to be a workaholic in order for the organization to succeed.

See my demonstration and download of software that I have used to carry out the software design and management method described above.

I should add that top-down implementation, testing, and documentation go hand-in-hand with top-down design.

I hear many people expressing doubts that Obama can bring about the change he promised after nominating so many people who served in the Clinton administration to high posts in the Obama administration.  The following is my reason for believing these appointments are not a hindrance to the change that he promised.

I accept Obama’s statement that the vision comes from him.

When a board of directors replaces a failing CEO with a new, powerful CEO with vision, many times the company will successfully make a large change in direction. Many of the people in the company other than the new CEO will continue to be the same people that managed the company with the old CEO. Nevertheless the company takes a drastic change in direction. So it can plausibly be with Barack Obama as the new CEO and experienced people who served in the Clinton administration as the rest of the management team.

Since the managers manage to the leader’s vision, many of the people from the Clinton administration may actually have had a vision that aligns more with Obama than with Clinton. They just did not get to behave this way when working for Clinton.

A good manager will either follow the leader’s vision or get the leader to modify his or her vision. If the manager cannot do either, the the manager ought to resign.

The leader sets the direction by deciding the tone that solutions should take. It is up to the managers to find and implement solutions that match the tone or explain to the leader why it can’t be done. A good leader will recognize good faith efforts that fail to find the solution in the direction she or he desired. Upon this recognition, the leader will bow to reality and accept a different solution.