Archive
Committees
The figure below depicts a “bent” UML class diagram of two types of committees. For those who don’t know UML, I hope that the diagram is sort of self-explanatory.
Mediocracies
As the name implies, a mediocracy is an average form of man-made organization. By definition, the vast majority of private companies are mediocracies, regardless of what top management espouses. Mediocracies are characterized by:
- Uniformity, homogeneity
- Stability (at least in the short term)
- Apathy, no ownership
- Hubris, arrogance, entitlement
- The same raises for everyone, regardless of performance
- Lots of managers and few, if any, leaders
- Stunted, bounded, personal and professional growth
- Fixed, rule-based behavior
- Reliance on improvement of obsolete processes instead of new process creation
- Promotions based on conforming behavior over performance
- Social punishment of innovators and deviants
- Slow, throttled, response times
- Lack of negative feedback loops that accelerate learning
- Reliance on firefighters, hero-worship
- A caste system where the upper echelons are disconnected and distanced from the lower constituencies
Got anymore traits to add to the list? Which would you rather work for, a staid and closed mediocracy or a vibrant and open meritocracy?
No Issues Please!
One of the differences between a leader and a manager is the way that they handle status reports from team members. When a leader receives a status report from a team member, she zeros in on the issues/roadblocks section and gets immediately to work. She talks to the team member to ferret out the problem specifics. For those issues that are out of the control of the team member, the leader becomes proactive and goes out and resolves the problem. It’s that simple.
What does a manager do with an issue? A manager ignores it. Hell, it’s work and thus, it’s outside the scope of her responsibility. After a few weeks of submitting issues and seeing no action taken, team members flip the bozo bit on the manager. Trust and respect, which are hard to earn but easy to lose, go right out the window.
Leaders rule, managers drool.
Upstream Bullies
In the aerospace and defense industry, a system engineer is the equivalent of a business analyst. They’re supposed to specify and record clear and unambiguous software requirements for the software development team, and then help the team get the requirements right.
In my experience, excellent system engineers are very hard to come by. The vast majority of them drop open-ended one line bombshells like “The system shall detect targets with a probability of detection of 95%” on the development team. Then these “shallocators” disconnect and distance themselves from the programming team and morph into glorified project managers, but without the responsibility. I call these types of system engineers upstream bullies because they’re always looking over your shoulder and telling you how to do your job even though they’ve never written anything bigger than “Hello World!”. Upstream bullies also demand that programmers dot the I’s and cross the T’s even though their own work, which is the input to the software team’s work, is a useless POS.
Ever wonder why you frequently read about large software-intensive government projects that are massively late and over budget? Besides poor leadership, another big reason is that upstream bullies are at work. If you’re a software developer and you have a choice, stay away from upstream bully shall-meisters.
System Architecture Notation
For years and years, I’ve used the simple circle and square notation shown in the top half of the figure below in order to communicate (mostly to myself) multi-technology system designs. I did it because UML hadn’t been invented yet, and circles/squares were trivial to draw with any software drawing tool.
Now that UML has been out for quite a while, I’m gonna (try) and switch to the UML notation shown in the bottom half of the diagram. Even though packages and nodes are slightly harder to draw than circles and squares with most mainstream drawing tools, every UML tool makes it as easy as pie. Even Visio (my favorite engineering graphics tool) has templates for easily generating UML notation.
Contained And Container
In Russell Ackoff‘s excellent book titled Idealized Design , he talks about container and contained systems. He essentially states that optimizing the contained system without changing the container system is a failure in waiting. The figure below depicts what often happens when a change agent succeeds in improving the contained system without consideration of the container system.
At time 1, the change agent realizes that there is an efficiency problem within the contained system. After an epic battle against the forces conspiring to keep the status quo intact, he/she succeeds in smoothing out the operation of the contained system at time 2. However, since the container system was neglected, it still operates according to the old rules and interfaces of time 1. Thus, an impedance mismatch between the container and contained system interface has appeared. This impedance mismatch can cause organizational performance to be worse than before the change (the cure is worse than the disease) to the contained system!
In an ideal system change effort, both the container and contained systems are improved. Done correctly, a smooth and high performing system-of-systems, like the above model at time 3, can be achieved. Compare the smooth circular integrated interface at time 3 with the previous inefficient and cloudy interfaces of the previous 2 times.
The Single Most Important Thing
Scott Berkun is one of my favorite technical consultants. He’s a former Microsoft program manager who worked on the development of Internet Explorer and he’s written two classic books on project management and innovation. In this post: power, Scott states a simple and profound truth:
As a program manager (glorified title for project manager), all of my power actually came from the programmers. I only had a job because of the programmers. No programmers means no code, no product, no revenue. End of story. My power was an extension of theirs. I had to treat them with respect and go out of my way to earn their trust over time.
I’d like to extend Scott’s opening sentence so that it applies to companies that develop multiple-technology products containing an integrated system of software, digital hardware, mechanical hardware, and electrical hardware.
As a program manager (glorified title for project manager), all of my power actually came from the engineering groups….. I had to treat them with respect and go out of my way to earn their trust over time.
In multi-technology companies where managers put other peer and higher up managers first, the odds are that schedule, cost, and quality will suffer. Instead of operating like high performing meritocracies, these companies end up just like the rest of the herd; as mediocracies.
Under Siege
Working on a product that requires a multi-disciplined engineering team can be a fun and exhilarating growth experience. However, the fun can be snuffed out by poor management of negative external forces. The figure below shows just some of the forces that can derail a project.
Help!
By far, the pressure exerted by the management chain can cause the most harm to the product and development team. In some companies, the lower level managers are zero resistance conductors of schedule pressure exerted by the higher ups. The negative effects of this pressure are absorbed directly by the development team.
Since I think that all people in an organization are always trying to do the right thing, the reason that this operational behavior is so ubiquitous is that the perps aren’t aware of what they’re doing. In mindful organizations that are aware, the management chain instills a mild and tempered sense of urgency that increases performance without causing harm.
Decision Making Stalemate
Joel Spolsky is one of my favorite software philosophers. Joel sticks to fundamental principles no matter what the latest flavor of snake oil is being preached at the moment.
In this blog post, Endless Debate, Joel states:
“A terribly common error is having a debate over how something should be designed, and then never resolving the debate“.
He follows that with:
“In too many programming organizations, every time there’s a design debate, nobody ever manages to make a decision, usually for political reasons. So the programmers only work on uncontroversial stuff. As time goes on, all the hard decisions are pushed to the end. These are the most likely projects to fail.”
In addition to political reasons, I’d also like to add fear. In alpha male dominated corpo cultures, fear drives the non-alpha members of the group. The titled alphas (a.k.a. managers) rule the roost and the non-alphas go silent when an alpha asserts himself – even if the alpha hasn’t got a clue on what the right course of action is.
Yes Master!
I don’t agree with Joel’s assertion that “all decisions are pushed to the end”. Because of schedule pressure and the fear of reprisal if the alpha’s instructions aren’t followed, the programmer(s) quietly implement the alpha’s horrendous decision in either code, design, or architecture.
The downstream ramifications of implementing the wrong decision get worse depending at which level of abstraction they are manifest. When the customer: gets the software, discovers the problem, and demands that it be fixed, the alphas are quick to blame the programmers since it’s often impossible, or not politically correct, to trace the problem back to it’s root cause – the bozo alpha’s poor technical decision.
Who said that life was fair?
Filtering And Distortion
Virtually everyone sees “life” as an integrated, filtered, and distorted stream of continuous analog input. Each filter is person-specific and tends to get narrower as we supposedly grow-up. The designer of the filter is the personal ego and if you’re not aware of this, it can severely degrade and limit your experience of life. My goal is to remove my personal filter so that I can experience the glorious full spectrum of life. I may not attain this goal, but I’m going to try to achieve it until my last breath. Please wish me luck.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 