Archive
Government Business
The figure below is a UML (Unified Modeling Language) class diagram that models a fictional government contracting system. So you don’t know UML? Don’t leave, because UML is easy to understand if one doesn’t over-specify in an attempt to show the world how “smart” he/she is.
The diagram shows the players (“classes” in UML lingo) in the game and some of the relationships (“associations” in UML lingo) between them. The diagram can be understood as follows:
The taxpayer funds congress, which funds groups of government bureaucrats, who hire a contractor to develop and deliver a product to be used by government workers to do their job of serving the public. Money, which everyone worships of course, ties all these main power players together. The contractor develops a product, which is then (delivered to the government and is) used by the government workers. All is well and the world becomes a better place. Whoopeee!
Yawn, meh. Boring and uninteresting, no? But wait, there’s more. Some hidden relationships between the “classes” in the system are not displayed by this proper and politically correct diagram. The diagram below shows just one of these hidden relationships – mistrust – between everyone 🙂 . How did this mistrust emerge and infiltrate the system? From the players getting burned in the past, that’s how. Especially the ultimate source of all money in the system – the taxpayer.
The last figure in this post shows the dynamic behaviors exhibited by each of the active players in this goverment business dance. In the UML, the middle compartment in a “class” (which is nothing more than a type of object – a classification) is intended to hold the attributes that characterize the class. I purposefully left them out because they’re not important to the message I’m trying to communicate.
I’ll leave it to your imagination to create specific scenarios of system operation (called “use cases” in the UML). Scenarios are specific subsets of behaviors that are sequentially strung together in time (scenarios can be modeled with UML “sequence diagrams”). At the end of a given scenario execution, the system has achieved a specific goal, like “make everyone in the system miserable”, or “damage the environment”, or “reward those who deserve it the least and punish those who are innocent of wrongdoing”.
Are there any significant players missing in this system? Are there any relationships missing? Are there any behaviors missing? Got a different model of how this government system works or how it should work? Remember this:
The purpose of a system is what it does, not what its advocates say it does.
Thanks for listening!
A Rigged System
Based on observation and personal experience, here’s my assessment of how the system nominally executes:
- A customer issues a Request For Proposal (RFP) or a Request For Quote (RFQ) for a product that meets a perceived need.
- The competitors respond with a proposal that contains a solution, a price, and a schedule.
- An organization wins (kudos and high-fives all around)!
- A program team is formed in the winning organization.
- The program team inherits the proposal schedule.
- The proposal is communicated to the product development group (PDG).
- The PDG forms a product development process (PDP) team.
- The PDP team analyzes the proposal and constructs a PDP schedule.
- The PDP team executes the PDP.
- The PDP team performance doesn’t *match* its own schedule OR the original proposal schedule – sometimes by a large amount.
- The customer, the organization, the program team, and the PDP team suffer the consequences.
- Go to step one for the next effort.
The figure below illustrates the nominal system operation, where M = Milestone.
Sometimes, but not always, the developer organization “forgets” the original proposal schedule and, via the magic of cognitive dissonance, praises the PDP team at the end of the effort for being on schedule and under budget. Sometimes, even the customer conveniently “forgets” original proposal schedule, but the customer’s financial sponsor usually doesn’t.
Do you agree with the assessment of the system’s nominal operation? If you agree with it, then consider these follow on questions:
For each of the participants in the system, where do you think the suffering starts?
Do all participants suffer equally? If not, which participant do you think suffers the most?
Is anyone at fault, or are the unintended consequences a byproduct of the system’s behavior?
What management techniques can be employed to drive “the measure of underperformance” to zero, or ideally, to a negative value?
Are there some management techniques that, if applied, will cause greater underperformance?
If you don’t agree with the assessment, then please tell me why, and what your experience has been.
Do you think the cognitive dissonance scenario exists?
If so, have you experienced the cognitive dissonance scenario?
In the cognitive dissonance scenario, even though the outcome is falsely deemed a rousing success, do you think there is any suffering by one or more participant groups during execution?
There Are Lots Of “I”s In A Team
“Sacred Cows Make The Best Hamburger”
Do you ever get tired of hearing the old and worn out management cry: “There’s no I in team!”. In this article, I’d like to challenge that unquestioned assumption.
The left-hand figure in the graphic below depicts a man-made group with a bunch of “I”s thrown together. Since the motto is “it’s every man for himself,” the group shouldn’t really be called a team. It’s more like a heap of individual and unconnected parts. In a heap, the whole is nothing more than the sum of the parts.
The figure in the middle of the graphic represents a group of people instilled with the “there’s no I in team” mentality. In this case, the group is more than the sum of its parts and it’s a much better problem solving structure than a heap of “I”s. However, because of the across-the-board homogeneity and lack of distinction between group members, the solutions produced by a group of “we”s are bland and mediocre, like unflavored oatmeal.
The figure on the right shows the ideal team. It’s composed of people who are motivated to succeed both individually and collectively. Relative to the other two types of groups, the team of “I + We”s is a super performer and it creates innovative solutions to problems. Thus, a high performing team is comprised of lots of “I”s.
Sadly, the vast majority of corpo organizations create hideous hybrid abominations like the one in the figure below. Yuk!
By; repeatedly espousing that “there’s no I in team!” to the doers sub-group; treating all work with the same apathetic reception regardless of relative quality; and punishing individual creativity; managers create and nurture a divided mediocracy. Of course, since they are the chosen ones, managers never follow the rules that they espouse for others. Thus, they are constantly and cleverly competing with their brethren for status and entitlement, operating as “I”s. It’s a good thing that the “we”s actually produce the outputs that allow the organization to survive, even though their products are mediocre and boring as hell.
Who’s Important?
Do you want to know who’s really valued by your organization’s so-called leadership? Just take a look at who’s located physically close to them. Look who’s got the big offices and what they’ve actually done to grow the organization. Look at who gets to go on company junkets. Look at who gets the training dollars. Are they the organization’s value producers, or are they the overhead consumers? Are they members of contracts, finance, marketing, human resources, business development, communications, compliance, or are they the people who create the value that keeps the organization alive: the engineers, the designers, the manufacturers, the integrators, the testers, the customer trainers, the customer support staff? Odds are that the people who directly create the wealth are cloistered in cubicle farms at the “back” or “bottom” of the building and treated as second class citizens. Long live those fossil managers who are stuck in the past and are ignorantly happy to operate by Ford’s , Taylor’s, and Sloane’s rules – regardless of what they say. Clueless dolts.
The Drunkard’s Walk
Assume that your company has a problem that needs to be solved. Management then creates a project and allocates resources: money, time and you, to solve the problem. The figure below shows the context that is established at project start. There’s you, the hairball problem, and a solution somewhere at the end of the project pipeline.
Since the best solution (out of an infinite set of possibilities) is almost always unknown a-priori, the amount of allocated money and time may not be correct. In my experience as a participant in the development and (mostly) maintenance of large, complex real-time embedded software systems, the “budgeted” amount of time and money is usually vastly underestimated. To top things off, management usually thinks that the problem-to-solution path is a linear, forward-only, sequential march to success.
The figure below shows the real drunkard’s walk that is traversed when a non-trivial problem gets solved. The start-to-end signature is person-specific. A prim and proper straight line to the solution through the official corpo process book never occurs. If you’re familiar with the problem domain and have solid experience with other similar problems, then your solution path may be less erratic than the path of others.
In the example above, notice how there are 3 occurrences of vector segments that go backward in time to revisit and correct mistakes. Each decision that you make to go backwards is a result of new knowledge discovery and learning. Sadly, because going backwards is a serious taboo in linear-sequential-think orgs, some people consciously decide to never go back, knowing full well that they’ve left some turds in the road for their followers to step in.
In a high pressure, micro-watched project, publicizing any regression steps to management in real-time is not a smart move. Even though it’s the truth, an unconscious force within you (ego) can cause you to lie and feign forward progress at every status reporting interval. Thus, in your manager’s mind, you’re “on schedule and under budget”. Splendid!
If you’re working on a multi-person project, then everyone else on the team is performing their version of the drunkard’s walk too. At each weekly breathalyzer test (oops! I meant status reporting meeting), everyone tries their damnest to appear sober in order to avoid a DUI .
Happy drinking!
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.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 