Archive
Armed And Ready
How much technical acumen does a project manager need to have in order to effectively manage a software-intensive product development effort? Are Spreadsheet, Gannt chart, PERT chart, EVM, Microsoft Project skills, and a golden certificate from schools like the vaunted PMI the only tools needed to lead a multi-disciplined, technical crew of engineers to so-called victory? I think not, but you may think differently – especially (and understandably) if you’re a project/program manager.
I think effective technical project managers are rare and they sprout from the trenches of one or more of the technical disciplines: software, hardware, test, and systems engineering. Wrestling with technical problems in the mud while under schedule pressure from multiple managers to keep costs down and to deliver quality promptly is the hazing experience needed to appreciate both the financial and technical aspects of a project or program. It may seem that project and program managers are under pressure themselves from executives above them in the command and control hierarchy, but unlike the dudes at the bottom of the food chain, they can easily pass the buck when financial and technical goals aren’t met. Who do ineffective BMs pass the buck to when the execs in the heavens demand accountability for poor project performance (usually way downstream after project execution has been supposedly progressing splendidly)? Why, the dweebs in the cellar of course.
“You have to know a lot to be of help. It’s slow and tedious. You don’t have to know much to cause harm. It’s fast and instinctive.” – Rudolph Starkermann
Cranking fat heads off the project management education assembly line and arming them with the necessary but insufficient skills to lead technically smart people into the raging battle against complexity is like arming firefighters with squirt guns to put out a 5 alarm fire. All it does is perpetuate the illusion of control and prep the graduates for moving higher up on the Plan-Watch-Control-Evaluate ladder – even though they don’t have a clue as to what they’ll be planning-watching-controlling-evaluating. But hey, I like to make things up and I’m not fit to lead anything, so don’t listen to a word I say 🙂
Pick And Own
No, the title of this blost (short for blog-post and pronounced “blow-ssst”) is not “pick your nose“. It’s “pick and own“. My friend Bill Livingston uses the following catchy and true phrase throughout his book “Design For Prevention“:
He who picks the parts owns the behavior. – Unknown
This is certainly true in the world of software development for new projects. For maintenance projects, which comprise the vast majority of software work, this dictum also holds:
He who touched the code last owns the stank. – Unknown
Bill also truly but sadly states that when something goes awry, the dude who “picks the parts” or “owns the stank” is immediately sought out for punishment. When everything goes smoothly, the identity of the designer/maintainer magically disappears.
Punishment but no praise. Such is the life of a DIC. BMs, CGHs and CCRATS on the other hand, clever as they are, flip everything upside down. Since they don’t pick or maintain anything, they never get blamed for anything that goes wrong. Going one step further, they constantly praise themselves and their brethren while giddily playing the role of DIC-punisher and blamer.
WTF you say? If you fellow DICsters didn’t know this already, then accept it and get used to it because it’ll sting less when it happens over and over again. Tis the way the ancient system of patriarchical CCH institutions is structured to work. It doesn’t matter who the particular cast of characters in the upper echelons are. They could individually be great guys/gals, but their collective behavior is ubiquitously the same.
Don’t Keep It A Secret
When I was younger and working at my first real job as a sonar “system engineer”, I was tasked with designing a set of digital filters to process a multiplexed stream of audio signals from a sonar microphone array. During a weekly status meeting, the best manager I ever worked for asked me if I’d written up the design and had it peer reviewed. I told him that I hadn’t and then he hit me with the first of many wise zingers over several years. He told me “Don’t keep it a secret. Write it up, communicate it, share it.” Being the dumbass and naive engineer that I was (and still am?) back then, I hadn’t thought of doing that. I was just gonna slip the resulting design into the system specification, let the software and hardware and test dudes deal with any mistakes/errors downstream, and move onto my next joyful assignment.
When my mentor said “don’t keep it a secret” to me, a terrible fear gripped me: “What if I screwed up and someone points out a major flaw in the work? What would people think? People might laugh at me.” Instead of thinking about adding value to the company and helping others do their jobs better, I was dwelling on self-important thoughts about ME – poor ME. Alas, such is the conditioning that is innocently but surely foist upon us from the moment we start disassociating ourselves from our true being and we start welding ourselves to the “I” thought. This freedom-squelching conditioning process starts with our parents and continues relentlessly throughout school and throughout our working lives.
From what I remember, the writeup and review process went much better than I anticipated. However, even after that first jolt, it still took me a long, long time to overcome the fear of exposing my work to others. Even today, many years later, I sometimes relapse and must fight the fear instinct associated with exposing work to others for scrutiny – especially managers.
How about you? Have you ever experienced a similar feeling? Do you still experience it? Is your goal to jump into management as quickly as possible so that you can escape the fear and transition from scrutinizee to scrutinizer? Have you already successfully done this? Dudes and dudettes, don’t be shy and please gimme some blowback. 🙂
Why So Much Overlap?
If, as some spiritualists say, we all create our own unique personal reality, then why is there so much overlapping commonality in what we see, smell, taste, hear and physically feel? Oh sure, there are different levels of pain, different shades of red, etc, but when 1 million people have their thumbs chopped off with a machete, I’ll assert that every single one of them will feel some level of pain and not ecstasy.
If there was no overlap in perception, we’d have nothing in common, right? We’d all be isolated and life wouldn’t be worth living, or would it? Am I taking this topic too literally? If you know the answer to my conundrum, please help me out here. Thanks.
Another Humbler
It’s often frustrating but always well worth the pain to get humbled from time to time. If it happens often enough, it’ll deflate your head somewhat and keep you on the ground with the rest of your plebe peers. Too much humbling and you lose your self-esteem, too little humbling and you morph into an insufferable, self-important narcissist – like me. One of the reasons why I love zappos.com is that one of their core company values is “Be Humble”.
The other day, I was slinging some code and I was hunting for a bug. In order to slow things down and help expose the critter, I inserted the following code into my program:
//sleep for a second to allow already waiting subscribers a chance to discover us
boost::this_thread::sleep(boost::posix_time::milliseconds(2000));
std::cerr << “\nSleeping For A Bit….. Zzzz\n\n”;
I then ran the sucker and watched the console intently. Low and behold, the program did not seem to pause for the 2 seconds that I commanded. WTF? After the “Sleeping For A Bit” message was printed to the console, the program just zoomed along. WTF? Over the next 10 minutes, I reran the code several times and stared at the source. WTF? Then, by the grace of the universe, it hit me out of the blue:
//sleep for a second to allow already waiting subscribers a chance to discover us
std::cerr << “\nSleeping For A Bit….. Zzzz\n\n”;
boost::this_thread::sleep(boost::posix_time::milliseconds(2000));
Duh! This never happens to you, right?
Now, if I can only practice what I preach; walk the talk.
Plan, Plan, Plan…. Blah, Blah, Blah.
Preface
People followed Martin Luther King of their own free will because he had a dream, not a plan. – Simon Sinek
On the other hand, know-it-all business school trained weenies will profess (in a patriachical and condescending tone):
Failing to plan is planning to fail – Unknown
Irrelevant Intro
When I started this relatively loooong blarticle, I had no freakin’ idea where it would go but I followed where it led me. Led by the unknown into the unknown – it was the keystone cops leading the three (nyuk nyuk nyuk) stooges (whoo, whoo, whoo, boink, plunk, pssst!).
As usual, I didn’t have a meticulously well formed plan for this time-waster ( <- for you, heh, heh) in my fallible cranium and I made many mid-course corrections as I crab-walked like a drunken sailor toward the finish line. Hell, I didn’t even know where the freakin’ finish line was. I stopped iteratively writing/drawing when I subjectively concluded that….. tada, “I’ve arrived!”. Such is the nature of exploration, discovery, and exposition, no? If you disagree, why?
Pristine Profile – Full Steam Ahead!
The figure below shows the shape of a pristine, planned, cost vs time profile at “project start” for a long term, resource-intensive, project to do something “big and grand for the world”. Some one or some group has consulted their crystal ball and concocted a cost vs schedule curve based on vague, subjective criteria, and bolstered by a set of ridiculously optimistic assumptions and a bogus risk register “required for signoff“. To coverup the impending calamity, the schedule has been enunciated to the troops as “aggressive“. BTW, have you ever heard of a non-aggressively scheduled big project?
It’s interesting to note that the dudes/dudettes who “craft” cost profiles for big quagmire projects are never the ones who’ll roll up their sleeves, get dirty, and actually do the downstream work. Even if the esteemed planners are smart enough to actually humbly ask for estimates from those who will do the work, they automatically chop them down to size based on whim, fancy, and political correctness. <- LOL!
Typical Profile – Bummer
The figure below shows (in hindsight) the actual vs planned cost curve for a hypothetical “bummer” project. The project started out overestimated (yes, I actually said overestimated), and then, as the cost encroached into uncomfortable territory, the plan became, uh, optimistic. Since it was underestimated for “political reasons” (what other reason is there?), but no one had a clue as to whether the plan was sane, no acknowledgement of the mistake was made during the entire execution and no replanning was done. The loss accumulated and accumulated until end game – whatever that means.
Crisis Profile – We’re Vucked!
The figure below shows (in hindsight) the actual vs planned cost curve for a hypothetical “vucked” project. Cost-wise, the project started out OK, but because it was discovered that technical progress wasn’t really, uh, technical progress, bodies were thrown onto the bonfire. Again, the financial loss accumulated and accumulated until end game – whatever that means.
Replan Profile – Fantasy Revisited
The figure below shows (in hindsight) the actual vs planned cost curve for a hypothetical “fantasy revisited” project. Cost-wise, the project started out OK (snore, snore, Zzzzz), but because it was discovered that technical progress wasn’t really, uh, technical progress, bodies were thrown on the bonfire. But his time, someone with a conscience actually fessed up (yeah, some people are like that, believe it or not) and the project was replanned in real-time, during execution. Alas, this is not Hollywood and the financial loss accumulated and accumulated until end game – whatever that means.
Iterative, Incremental Profile – No Freakin’ Way
Alright, alright. As everyone knows, and this especially includes you, it’s easy to rag about everyone and everything – “everything sux and everyone’s an a-hole; blah, blah, blah…. aargh!”. What about an alternative, Mr. Smarty Pants? Even though I have no idea if it’ll work, try this one on for size (and it’s definitely not original).
The figure below shows (in hindsight) the actual vs planned cost curve for a hypothetical “no freakin’ way” project. But wait a minute, you cry. There’s only one curve! Shouldn’t there be two curves you freakin’ bozeltine? There’s only one because the actual IS the planned. This can be the case because if the planning increments are small enough, they can almost equate to the actual expenditures. At each release and re-evaluation point, the real thing, which is the product or service that is being provided (product and service are unknown concepts to bureaucrats and executive fatheads), is both objectively and subjectively evaluated by the people who will be using the damn thing in the future. If they say “This thing sux!”, its fini, kaput, end game before scheduled end game. If they say “Good job so far! I can envision this thing helping me do my job better with a few tweaks and these added features”, then it’s onward. The chances are high that with this type of rapid and dynamic learning SCRBF system in place, projects that should be killed will be killed, and projects that should continue will continue. Agree, or disagree? What say you?
This hypothetical project is called “No Freakin’ Way” because there is “no freakin’ way” that the system of co-dependent failure designed and kept in place by hierarchs in both contractor and contractee institutions will ever embrace it. What do you think?
Viable, Vulnerable, Doomed II
As the title indicates, this blow-sst is an extension of yesterday’s inane blabberfest. While yesterday’s lesson (<— lol!) dealt with the static structure of Viable, Vulnerable, and Doomed (VVD) orgs, today’s BS-fest talks about the dynamic behavior of VVD social groups. Behold that if you’re conscious and you concentrate on observing the world around you, the structure plus behavior of an org will clearly and unambiguously reveal over time what it does. Forget what its so-called leaders say it does, observe for yourself how the stratified monolith is structured, how it behaves, and what it actually produces. If you’re diligent and astute, you’ll discover the principle of POSIWID: the Purpose Of a System Is What It Does (not what it’s leadership says it does).
The UML diagram below shows a state machine model of: the mutually exclusive states of a VVV system, the transitions between the states, and the events that trigger the transitions. But wait…… VVV? What happened to VVD? Well, in a dumbass attempt to inject levity and fruitlessly retain your interest, I changed the name of the “Doomed” state to “”Vucked” so that all states start with the letter “V”. Stupid, no?
Virtually all startup companies initialize into the viable state. After all, if they didn’t have a product or service that a market didn’t want to consume, they wouldn’t be born as a viable entity, right? Over time, if they neglect their explorers and single mindedly, greedily, milk their product/service to death, eventually they’d become vulnerable to competitors. If the leadership becomes drunk with success and their heads expand too far, they start resenting and rejecting their explorers – they become vucked!
Unless, as the figure below shows, an epiphany in the head shed occurs (and the chances of that occurring in fat headed executives rolling in dough are incredibly slim) it’s death to the org and all its membership – including the innocents who had no hand in the implosion. This ain’t a hollywood story so there’s no happy ending.
Viable, Vulnerable, Doomed
Unless an org is subsidized without regard to its performance (e.g. a government agency, a pure corpocracy overhead unit like HR), it must both explore and exploit to retain its existence. Leaders explore the unknown and managers exploit the known, so competence in both these areas is required for sustained viability.
Exploitation is characterized by linear thinking (projecting future trajectory solely based on past trajectory) and exploration is characterized by loop thinking. Since these two types of thinking are radically different and prestigious schools teach linear thinking exclusively, all unenlightened orgs have a dearth of loop thinkers. Sadly, the number of linear thinkers (knowers) increases and the number of loop thinkers (unknowers) decreases as the management chain is traversed upward. This is the case because linear thinkers and loop thinkers aren’t fond of one another and the linear thinkers usually run the show.
The figure below hypothesizes three types of org systems: vulnerable, doomed, and viable. The vulnerable org has a loop thinking exploration group but most new product/service ideas are “rejected” by the linear thinkers in charge because of the lack of ironclad business cases. Those new product/service ideas that do run the gauntlet and are successful in the marketplace inch the org forward and keep it from imploding. The doomed org has an exploration group, but it’s just for show. These orgs parade around their credentialed rocket scientists for the world to see and hear but nothing of exploitable substance ever comes out of the money sucking rathole. The viable org not only has a productive explorer group, but the top leadership group is comprised of loop thinkers too – D’oh! These extraordinary orgs (e.g. Apple, Netflix, Zappos, SAS) are perpetually ahead of their linear thinking peers and they continually (and unsurprisingly) kick ass in the marketplace.
What type of org are you a member of?
Geeks Bearing Formulas
Since there are so few champions that have successfully leveraged simplicity to paradoxically conquer complexity, and he is one of them, legendary investor Warren Buffet is high on my hero and mentor list. Check these jewels out:
All I can say is, beware of geeks … bearing formulas. – Warren Buffet
The business schools reward difficult complex behavior more than simple behavior, but simple behavior is more effective. – Warren Buffet
Preserving The Problem
Because I’m a shirker, I love Clay Shirky. Not only does he have a kool name, the guy is an innovative thinker:
“Institutions will try to preserve the problem to which they are the solution.” — Clay Shirky
Like many rich and insightful quotes that I stumble upon, I didn’t quite get this one at first. But after thinking about it, I conjured this one up:
While espousing that they want unity of purpose, collaboration, esprit de corps, teamwork, and yada-yada-yada, the juntas in head sheds everywhere unwittingly (wittingly?) preserve the very same problem they supposedly want solved. In this example, the problem is poor corpo performance caused by fragmentation, isolation, stratification, disengagement, and mis-communication. CCRATS not only preserve the performance problem, I’ll go one better than the Clayster. I’ll assert that CGHs amplify the stank by nurturing and perpetuating their hand made caste system of divisive titles, arbitrary reward systems, and socially disconnected working units/departments/groups. It’s silo city – by design.
So why do head sheds everywhere perpetuate this Alice In Wonderland behavior in spite of the ominously growing evidence that it doesn’t work in an increasingly flat and globally connected world? Because changing the entrenched system they collectively built to take care of themselves would flatten the hierarchy and cause them to come tumbling down from the heavens. Do you think many of the “honorable and infallible” talking heads of our institutions want, or have the will, to give up their elevated personal standing for the greater good of the whole? I suspect not many, but those who can and do will prosper in this age of rapid change.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 