Top Down Design/Bottom up implementation

In my previous blog i made a case for management as a service profession. And that is something I really believe.

Like any good idea, however, it can be taken to bad extremes. In this post I thought I'd address that.

In traditional procedural programming, we have a concept of "top down design/bottom up implementation." What this means is that you start at the general goal and break it done into sub-tasks. You then break each of those sub-tasks up, and keep going until you hit a level that "feels right" for implementation. (There really is no hard and fast rule for what this is, knowing it when you hit it is more art then science.) Then we start building the software starting at that bottom level and working our way back up to the goal.

This results in a software design that is well focused on the goal, but also is built in clear and separable layers. Top down design is a matter of designing software functionality and interfaces to that functionality. In today's object oriented world it can be seen as a form of "encapsulation' but it is a very specific form that leads to software with some very good properties. Should any individual layer prove to have an issue it can be fixed or replaced with no impact on the layers above it and below it. Higher layers can be stripped away without sacrificing lower level functionality. Finally, each layer can be created by people with the best understanding of that layers' functionality.

An engineering project can be, and I will argue, should be designed in the same way. At the top are those defining the business goals. Beneath them on the tree are one or more layers of architect who take the output of the management layer above them and decompose it into goals for the layer below them until the decomposed parts of the design finally arrive at the implementing teams.

Such layered project design has all the advantages of layered software design. Failures on part of the process do not directly impact other parts of the process below them and impact above them only so far as the architected interfaces need to change. It also focuses each participant's efforts on the area where they add the most value to the project.

In my previous blog I talked about the management side of an engineering manager's job, but many people managing engineers are also engineers or architects themselves. And this calls for a different set of skills and approaches then the management side.

Non-engineering management can often get confused and think that "empowering the workers" means asking every engineer's opinion on everything. Or worse, asking everyone's opinion on every functional part of the process from engineering to art to game design.

This devalues the very expertise you probably hired these people for to begin with and creates a whole lot of confusing noise for upper management. In such an environment, decisions become highly politicized and those who can "sell"(1) what they want in terms that make the most sense to those who often know the least-- upper management-- prevail in defining the entire project.

Part of empowerment is authority. And if you give everyone equal authority over everything, then noone has authority over anything. A football team where everyone is trying to play quarterback doesn't get very far down the field.

So, empower your people... but empower them to do *their* jobs, not everyone else's. Trust that you have hired the right people for the right positions and let them play them without undo interference from others with other functions. That is true empowerment.


(1) Engineers have a technical term for the act of sales. We call it lying. I have *no* tolerance for engineers who deliberately color the information they are passing up in order to get a desired reaction and, if i am allowed to, will fire anyone I catch doing it. That is the flip side of giving some one authority and your trust. If they violate it, they are gone. The kind of management i do calls for honest and open communication, not political positioning.