Archive
Keep A Tally
Starting today, keep a tally on the number of times that mangers in your org say the words “schedule” and “quality” over the next month. At the end of the month, compute the ratio of schedule-to-quality pronouncements that you recorded; the SQR. I’ll bet you that at the end of the month, SQR >> 1.
Plumbers And Electricians
Putting an expert in one technical domain “in charge” of a big risky project that requires deep expertise in a different technical domain is like putting plumbers in charge of a team of electricians on a massive skyscraper electrical job – or vice versa. Putting a generic PMI or MBA trained STSJ in charge of a complex, mixed-discipline engineering product development project is even worse. When they don’t know anything about WTF they’re managing, how can innocently ignorant project “leaders”:
- Understand what needs to be done
- Know what information artifacts need to be generated along the way for downstream project participants
- Estimate and plan the work with reasonable accuracy
- Correctly interpret ongoing status so that they have an idea where the project is located in terms of cost, schedule, and quality
- Make effective mid-course corrections when things go awry and ambiguity reigns
- See through any bullshit used to camouflage shoddy work or to cut corners,
- Stop small but important problems from falling through the cracks and growing into ominously huge obstacles
- Perform the “verify” part of “trust but verify”.
Well, they can’t – no matter how many impressive and glossy process templates are stored in the standard corpo database to guide them. Thus, these poor dudes spend most of their time spinning out massive, impressive excel spreadsheets and microsoft project schedules so fine grained that they’re obsolete before they’re showcased to the equally clueless suits upstairs. But hey, everything looks good on the surface for a long stretch of time. Uh, until the fit hits the shan.
Maker’s Schedule, Manager’s Schedule
I read this Paul Graham essay quite a while ago; Maker’s Schedule, Manager’s Schedule, and I’ve been wanting to blog about it ever since. Recently, it was referred to me by others at least twice, so the time has come to add my 2 cents.
In his aptly titled essay, Paul says this about a manager’s schedule:
The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.
Regarding the maker’s schedule, he writes:
But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started. When you’re operating on the maker’s schedule, meetings are a disaster.
When managers graduate from being a maker and morph into bozos (of which there are legions), they develop severe cases of ADHD and (incredibly,) they “forget” the implications of the maker-manager schedule difference. For these self-important dudes, it’s status and reporting meetings galore so that they can “stay on top” of things and lead their teams to victory. While telling their people that they need to become more efficient and productive to stay competitive, they shite in their own beds by constantly interrupting the makers to monitor status and determine schedule compliance. The sad thing is that when the unreasonable schedules they pull out of their asses inevitably slip, the only technique they know how to employ to get back on track is the ratcheting up of pressure to “meet schedule”. They’re bozos, so how can anyone expect anything different – like asking how they could personally help out or what obstacles they can help the makers overcome. Bummer.
Byzantine Labyrinth
During the birth and growth of dysfunctional CCHs, here is what happens:
- silos form and harden,
- a bewildering array of narrow specialist roles get continuously defined,
- layers of self-important and entitled RAPPERS emerge, and
- a byzantine labyrinth of processes and procedures are created by those in charge.
This not only happens under the “watchful eyes” of the head shed, but incredibly, those inside the shed-of-privilege are the chief proponents and instigators of all the added crap that slows down and frustrates the DICforce. Peter Drucker nailed it when he opined:
Ninety percent of what we call ‘management’ consists of making it difficult for people to get things done – Peter Drucker
On the other hand, T.S. Eliot also pegged it with:
“Half of the harm that is done in this world is due to people who want to feel important. They do not mean to do harm… They are absorbed in the endless struggle to think well of themselves.” – T. S. Eliot
Scalability: The Next Buzzword
Since I’m currently in the process of trying to help a team re-design an existing software-intensive system to be more scalable, the title of this book caught my eye:
It’s just my opinion (and you know what “they” say about opinions) but stay away from this stinker. All the authors want to do is to jump on the latest buzzword of “scalability” and make tons of money without helping anybody but themselves.
Check this self-serving advertisement out:
“The Art of Scalability addresses these issues by arming executives, engineering managers, engineers, and architects with models and approaches to scale their technology architectures, fix their processes, and structure their organizations to keep “scaling” problems from affecting their business and to fix these problems rapidly should they occur.”
Notice how they try to cover the entire hierarchical corpo gamut from bozo managers at the peak of the pyramid down to the dweebs in the cellar to maximize the return on their investment. Blech and hawk-tooey.
BTW, I actually did waste my time by reading the first BS chapter. The rest of the book my be a Godsend, but I’m not about to invest my time trying to figure out if it is.
Context Switching
“There is time enough for everything in the course of the day, if you do but one thing at once, but there is not time enough in the year, if you will do two things at a time.” – Lord Chesterfield (1740)
Study after study after study have shown that, due to the natural imperfections built into human memory, multitasking is inefficient and unproductive compared to single-tasking. The bottom line is that humans suck at multitasking. Unlike computers, when humans switch from doing one thought-intensive task to another, the clearing out of memory content from the current task and the restoration of memory content from the previous task greatly increases the chances of errors and mistakes being made.
So why do managers multitask all the time, and why do unenlightened companies put “multitasking prowess” on their performance review forms? Ironically, they do it to reinforce an illusion that multitasking is a key contributor of great productivity and accomplishment. When a “performance reviewer” sees the impressive list of superficial accomplishments that a multitasker has achieved and compares it to a measly list of one or two deep accomplishments from a single-tasker, an illusion of great productivity is cemented in the mind of the ignorant reviewer. Most managers, huge multitaskers themselves, and clueless to the detrimental effects of the malady on performance, tend to reward fellow multitaskers more than non-multitasking “slackers“. Bummer for all involved; especially the org as a whole.
Staffing Profiles
The figure below shows the classic smooth and continuous staffing profile of a successful large scale software system development project. At the beginning, a small cadre of technical experts sets the context and content for downstream activity and the group makes all the critical, far reaching architectural decisions. These decisions are documented in a set of lightweight, easily accessible, and changeable “artifacts” (I try to stay away from the word “documentation” since it triggers massive angst in most developers).
If the definitions of context and content for the particular product are done right, the major incremental development process steps that need to be executed will emerge naturally as byproducts of the effort. An initial, reasonable schedule and staffing profile can then be constructed and a project manager (hopefully not a BM) can be brought on-board to serve as the PHOR and STSJ.
Sadly, most big system developments don’t trace the smooth profiling path outlined above. They are “planned” (if you can actually call it planning) and executed in accordance with the figure below. No real and substantive planning is done upfront. The standard corpo big bang WBS (Work Breakdown Structure) template of analysis/SRR/design/PDR/CDR/coding/test is hastily filled in to satisfy the QA police force and a full, BM led team is blasted at the project. Since dysfunctional corpocracies have no capacity to remember or learn, the cycle of mediocre (at best) performance is repeated over and over and over. Bummer.
Nested Bureaucracies
By definition, ineffective bureaucracies (are there any effective ones?) consume more resources than they produce in equivalent value to their users/consumers. According to Russell Ackoff, the only way an ineffective bureaucracy can remain in place is by external subsidization that is totally disconnected with its performance. In other words, bureaucracies rely on clueless sugar daddies supplying them with operating budgets without regard to whether they are contributing more to “the whole” than they are withdrawing. Unchecked growth of internal bureaucracies siphons off profits and it can, like a cancer, kill the hosting org.
The figure below shows a simplistic bird’s eye view of an American economic system dominated by CCH bureaucracies. The irony in this situation is that even though the Corpo Granite Heads (CGH) in charge of the CCHs are staunch supporters of the distributed free market model which rewards value creation and punishes under-performance, they run their own orgs like the old Soviet Union. Ala GM and most huge government departments, they operate as centralized, nested bureaucracies where the sloth at the top trickles money down to the mini-bureaucracies below – without regard to value produced.
Bureaucracies, being what they are and seeking to survive at all costs, jump through all kinds of hoops to camouflage their worthlessness and keep the money flowing down from the heavens. Since the cabal at the top is too ignorant to recognize that it’s a bureaucracy in its own right, it’s an expert camouflage spinner to the corpocracy’s stakeholders (who gobble up the putrid camouflage with nary a whimper) and it sucks much more out of the corpo coffers than it adds value without being “discovered and held accountable”. In the worst nested bureaucracies, none of the groups in the hierarchy, from the top layer all the way down the tree to the bottom layer, produce enough value to offset their ravenous appetite for resources. They collapse under the weight of their own incompetence and then wonder WTF happened. From excellence to bankruptcy in 24 hours.
The really sad part is that before a bureaucracy auto-snaps into place, it wasn’t a bureaucracy in the first place. Everybody in the “startup” contributed more than they withdrew from the whole, and the excess value translated into external sales and internal profits. Like the boiled frog story, the transformation into a bureaucracy was slooow and undetectable to the CGHs in charge. Bummer.
The answer to this cycle of woe, according to Ackoff, is for the leaders in an org to operate the whole (including themselves) as a system of nested free markets, where each internal consumer of services gets to choose whether it will purchase needed services from internal groups, or external groups. Each internal group, including the formerly untouchable head shed, must operate as a measurable profit and loss center. Mr. Ackoff describes all the details of nested free market operation, including responses to many of the “it can’t work because of……” elite whiners, in his insightful book: Ackoff’s Best. Check it out, if you dare.
Zero Cost Risk Mitigation
Why do managers and executives require project technical leaders to develop comprehensive “risk mitigation plans” while at the same time fully expecting the plans to cost nothing (no people, no time, no money). Formal and rigorously filled out risk registers (with no cost column) make it look like due diligence is being performed, but it’s all a ruse to sustain the illusion that management is “in control”. WTF?
Both Ends Of The Spectrum
Why does it seem that both the best engineers and the worst engineers always gravitate towards becoming managers? Because of a lack of training in the art of humanistic influence and true leadership skills, they usually (but not always) end up turning into STSJ BMs. The real tragedy is the continuous loss of the best engineers into the ranks of corpo elitism. Why? Because the revenue generating products and services they leave in the dust for fame and fortune suffer the consequences of their departure. Thus, the whole company suffers. Bummer.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 