Archive
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.
How And What
“Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.” – George S. Patton
One of my pet peeves is when a bozo manager dictates the how, but has no clue of the what – which he/she is supposed to define:
“Here’s how you’re gonna create the what (whatever the what ends up being): You will coordinate Fagan inspections of your code, write code using Test First Design, comply with the corpo coding standards, use the corpo UML tool, run the code through a static analyzer, write design and implementation documents using the corpo templates, yada-yada-yada. I don’t know or care what the software is supposed to do, what type of software it is, or how big it will end up being, but you shall do all these things by this XXX date because, uh, because uh, be-be-because that’s the way we always do it. We’re not burger king, so you can’t have it your way.”
Focusing on the means regardless of what the ends are envisioned to be is like setting a million monkeys up with typewriters and hoping they will produce a Shakespear-ian masterpiece. It’s a failure of leadership. On the other hand, allowing the ends to be pursued without some constraints on the means can lead to unethical behavior. In both cases, means-first or ends-first, a crappy outcome may result.
On the projects where I was lucky to be anointed the software lead in spite of not measuring up to the standard cookie cutter corpo leadership profile, I leaned heavily toward the ends-first strategy, but I tried to loosely constrain the means so as not to suffocate my team: “eliminate all compiler warnings, code against the IDD, be consistent with your coding style, do some kind of demonstrable unit and integration testing and take notes on how you did it.”
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 