An even greater problem than knowing whether causation or correlation is taking place, is the unwillingness or lack of imagination to ask that question in the first place.
Designing management of the future will require that these issues be addressed.
For Instance:
- Does an organizations structure dictate its effectiveness, or does its effectiveness dictate actual structure? (in this case structure is both the org chart and the informal network of teams and contributors)
- How are competent employees made to be so? How does a new grad staight out of college become a competent professional? Did the group shape them into a competent contributor?
While it may seem easy to draw the causal lines in many instances, continuing in that exercise yields interesting results. A new grad for instance can become competent due to coaching, training and experience, and ultimately use his or her political skills to shape the organization in ways that dynamically affect their own effectiveness, bringing the causal cycle back on itself.
A companies reorganization can have positive influences on its productivity, and that productivity can swing back around to make one department more powerful than another, and dramatically alter the next re-org cycle. The picture becomes even more complicated when we consider the rise and fall of informal networks.
The problem is this:
How can we intelligently design a new system when the reality of that system is complicated and hidden from view?
When designing an organization. We have no such luxury of immutable scientific laws.
All however, is not lost. A common engineering technique that can be applied to organizational design is sometimes referred to as "redrawing the box." The box in this instance is the scope of things considered when trying to solve a particular problem, and the assumed influences and effects. In an engineering application, you can assume that in a particular box, the flow of material into and out of the box overtime will be equal, or that in a particular box, the current flowing into it, is the same as that going out. In engineering the boxes allow us to use equations and laws on small portions, with the idea being that the system is a combination of each piece, allowing us to understand the entire system.
The Hack:
Applying the technique of defining an organizations boundaries can shine light on causal issues of organizational design and effectiveness. Rather than assuming that the causal relationship is one way or the other, formulaically assessing all possible relationships, and evaluating multiple paths can allow for less biased analysis and decision making.
Example (The Management 1.0 way)
Bob is a recent graduate at a high tech software company. He's been at the company for 6 weeks, and is not performing up to par. His supervisor, Steve, interviewed him when he was hired and was impressed by his success in a college project, and his ability to communicate well during the interview. The code Bob has been turning in is sloppy, and while it seems to accomplish the task, its not "clean," and difficult for others to understand initially. The QA department is having a hard time checking his code.
There could be many any number of causes for Bobs poor performance. The most likely cause to be identified in a management 1.0 world is that Bob himself, is a poor performer, that there is something inherint to his style that needs correcting, and through adequate coaching and direction, his style could be improved.
The box would be drawn like so;
Bob is not performing, so Steve coaches Bob: Whether or not Bob improves is due either to Steves coaching ability, or Bobs ability to accept guidance. Once this box is drawn, it will persist, and no one will question it. We've decided on a model that has a finite number of outcomes, and we are quite likely to be getting the wrong impression. If we use this model to make organizational decisions (such as whether Steve should be promoted as a competent leader of new talent, or whether Bob should be laid off) we're destined to make a less than great decision.
The management 2.0 way (drawing more than one set of boxes)
A better way would be to draw multiple sets of boxes. The first box above is well and good, but here are several others. Here are a few elements of different players that we can draw boxes around
Issue: Bob's code isn't well understood
Potential Causes: Bob is a bad coder, QA isn't talented enough to understand his code, Bob doesn't understand QA's expectations, The notes that go with bobs code aren't being provides to QA. Each of these "potential causes" have potential causes themselves, and those even more causes.
The difference between this "hack" and a 5-whys or fishbone analysis
Fishbones and 5-whys in practice are commonly drawn after the suspected root cause has already been decided upon. If you look at any real world fishbones, they aren't always balanced. Many items on them are put there to create the illusion that analysis has taken place, and as a pretty graphic to show higher level management, rather than as a real tool that the investigation team employed.
The additional element that makes this hack special, is the idea to formulaically define several possible paths before an issue even materializes, and require that a certain checkbox of investigative steps are looked at before a root cause can be announced. By having a list of investigative elements that must be completed, bias and politics can be reduced in making decisions, and decision models can be forced to include elements that might not be desirable for those creating the model with the intent of selling it to upper management for approval.
1. Define the goals (companies values, objectives)
2. Define models for persistent problems and situations faced
3. Link those decision and investigative models to real world web driven data, and make them dynamic
4. Define system inputs
5. collect inputs from parties seeking to resolve an issue
6. Run the system
7. Have a third party (neither the one seeking to resolve the issue, nor the party having built the model) look at the inputs, outputs, the models assumptions ect, and make a binding decision.
You need to register in order to submit a comment.