Archive
Uneducated, Greedy, Fungible, Lazy, Untrustworthy
I enjoy reading Watts Humphrey‘s work, but it’s not because I’m a big fan of his TSP/PSP software development approach. It’s because his writings inspire me to think and inquire. Thus, his writings are full of great blog post seedlings.
In “Leadership, Teamwork, and Trust: Building a Competitive Software Capability“, Watts describes the unquestioned assumptions made by managers regarding workers back in the ole’ days when Frederick Taylor’s scientific management methods were king:
Uneducated, Greedy, Fungible, Lazy, and Untrustworthy – UGFLU. There must not be a vaccine for curing UGFLU because it seems like the affliction has heartily survived 100 years of medical advances. UGFLU is an adaptable and robust little bugger, no?
Taylor’s List
Since his management methods don’t apply to the vast majority of work performed in the 21st century, yet bazillions of managers still cling to them out of cluelessness, I’m constantly ragging against Frederick Winslow Taylor‘s work in this blog (can you say FOSTMA?). However, like all man-made ideas, beliefs, and concepts in the world, it’s not a black and white affair.
In Watts Humphrey‘s final book, “Leadership, Teamwork, and Trust: Building a Competitive Software Capability“, Watts summarizes some less well-publicized tenets of Taylor’s teachings. In the following list, he reproduces Mr. Taylor’s advice to managers:
“Heartily cooperate“? “Equal division of work“?”Management takes over all work for which they are better fitted“? WTF? Uh, it seems like Tayloristic managers today (and of course, not all managers fit this bill) have only embraced the non-yucky, self-serving parts of Mr. Taylor’s teaching. They’ve conveniently thrown out the baby with the bath water, no?
Ammunition Depot
In preparation for a debate, both sides usually spend some time amassing evidence that supports their distorted view of the issue. Well, this post is intended to serve as a repository for my distorted side of an ongoing debate.
All the above snippets were strategically and carefully culled from various discussions posted on the wonderful Joel Spolsky and Jeff Atwood site: Stackoverflow.com.
Patron Saints
I’m not too fond of books written by experts in a know-it-all, patronizing voice. Check out this blurb from a famous and multi-decorated software management guru:
Besides being targeted at other patronizing know-it-alls by a fellow patronizing know-it-all, one hidden assumption in these words is that “senior executives and managers” actually care about understanding and trying to solve the nasty socio-technical problems that are weaved into the fabric of every large software development project. Another unspoken assumption is that “senior executives and managers“, with their five minute attention spans and disdain for immersive and sustained thinking, would read a whole book – let alone a tome promoting yet another “successful” software development process.
I wish I could follow the sales chart for this book and the hierarchical rankings of those who bought it.
Performance Improvement
ASSume that within the vast lands of a self-described great kingdom, you’re the prince of the little fiefdom below. To keep you comfortably propped up on your throne, the DICforce in each of the 3 little green boxes, under the watchful eye of your enforcer (the faceless BM dude with the white name tag), performs 3 day-to-day functions critical to your, I mean your group’s, “success“. For simplicity, let’s call these functions F1, F2, and F3.
So, everything’s humming along until – BAM! – revenues start declining and costs start rising. D’oh! and WTF? After spending some time down in the puke green boxes and thoroughly observing/investigating/analyzing/evaluating the state of your state, you declare that the performance of the “F2” function is gumming up your well-oiled machine. In your wisdom, you address your minions and boldly proclaim: “F2 Sux!“.
Uh, what change do you decide to make to “improve performance“? One option is to bring in some external “F2 gurus” to train your underperforming F2 DICsters. Another option is to fire your current F2 DICs and permanently hire new, expert, F2 DICs.
After mulling these options over, it hits you like an insight from Gawd…. you’ll hire one expert F2 enforcer dude, give him/her an ego-stroking overhead staff, and move your existing F2 DICsters into his/her newly born sub-fiefdom. So, you implement your brilliant idea and end up with this new borg:
So, besides further fragmenting your borg, increasing your overhead cost structure, pissing off your existing loyal enforcer, and having the same DICsters still supposedly screwing up the F2 function, what else can you pat yourself on the back for?
Loops Of Distrust
Mistrust reigns everywhere. Governments distrust big businesses and vice versa. Big business heads (and I mean it both literally and figuratively), even though they often superficially espouse otherwise, distrust their low level, non-executive people.
The two cause-effect loop diagrams below crystallize the situation, no? On the left, more regulation begets more lobbying and lawyering – which begets more regulation. Bummer. On the right, more red tape begets more subversion – which begets more red tape. Double freakin’ bummer.
In the government-DYSCO cat-and-mouse duel, government, even though it’s a massively dysfunctional CCH itself, wants its version fairness and equity to prevail. In the DYSCO-DICforce scenario, the DICforce wants its version of fairness and equity to prevail. In both scenarios, the DYSCO DJs want an unfair advantage.
Note: Not all companies are DYSCOs. Only DYSCOs are DYSCOs. Every once in a blue moon I state a disclaimer like this because some people may think I’m a black-and-white binary thinker.Those that do may be binary thinkers themselves?
CC++
For a comical moment, imagine that the C++ programming language was monopolized by a fortune 500 corpricracy and renamed as CorpoC++. Here’s a list of possible SCOL titles that could be conjured up and bestowed on some lucky people in the CC++ business unit:
- VP Of Exception Handling
- VP of STL containers
- VP of STL algorithms
- VP of Static Polymorphism
- VP of Overloading
- VP of Classes, Structs, and Enums
- VP of Primitive Types
- VP of Dynamic Polymorphism
- VP of Idioms
- VP of Deprecated Features
- VP of Backward C Compatibility
- VP of Syntax
- VP of Reserved Keywords
- VP of Construction, Destruction, and Copy Operations
- VP of Boost Feature Adoption
If you think “design by standards committee” is bad, what kind of monstrosity do you think this merry band of anti-collaborative thugs would hatch?
Hard To Misuse
I’ve seen the programming advice “design interfaces to be hard to misuse” repeated many times by many different gurus over the years. Because of this personal experience, I just auto-assumed (which is not a smart thing to do!) all experienced C++ developers: knew it, took it to heart, and thought twice before violating it.
Check out the three date() function prototype declarations below. If you were responsible for designing and implementing the function for a library that would be used by your team mates, which interface would you choose to offer up to your users? Which one do you think is the “hardest to misuse“, and why?
Which Path?
To all front line managers out there: “which path below did you take when you were promoted out of DIC-land?” To all DICs out there who want to, or are on a course to, move into the brave new world of management, uh, I mean formally anointed leadership: “which path below do you plan on taking?“.
To all those who took or prefer the D&D path, please leave this page now. To the remaining E&E takers and preferrers, please peruse this follow-on diagram:
Will you allow the natural and effortless course of increasing entropy occur after you’ve made your choice, or will you temporarily “hold it together” with effortful due diligence throughout your career – no matter how high you go or how much pressure you feel from your peers?
Is it even reasonable to ask for any overlap between work-work and management-work as one ascends higher up in a hierarchically structured CLORG? For example, in a 10 layer hierarchy, is it insane to expect the dudes in the upper echelons to know something, anything, about the nature of the work that goes on down in the boiler room?
Gored
In her book, “The Stone Age Company“, author Sally Bibb cites W. L. Gore (which coincidentally is on my list of faves) as one of the exemplar companies that will continue to thrive in an increasingly chaotic future that is sure to be apocalyptic for legions of old guard CLORGs. Sally states that one of the leadership mantras inside Gore is: “Look over your shoulder to make sure someone is following you“. In other words, if people don’t willingly follow you, you won’t be a leader for very long at the company.
Serendipity being what it is, I recently stumbled upon this short essay by W. L. Gore CEO Terri Kelly: No More Heroes: Distributed Leadership. Here’s what Ms. Kelly, in spite of being a real-life CEO, authentically says:
Organizations that hold onto conventional leadership models will find it increasingly difficult to attract and retain top talent.
Leaders will need to recognize that their primary role is to empower others versus build their own power. They will no longer stand behind a title with assumed authority to tell people what to do.
Those who know their leaders best are typically the individuals they lead. If you want individuals to have a voice in the organization, they must also have a voice in selecting and evaluating their leaders.
All associates (at Gore) get the opportunity to rank members of their team, including their leaders. They are asked to create a contribution list in rank order based on who they believe is making the greatest contribution to the success of the enterprise.
Note that followers have a say in who leads them and they evaluate each other and their bosses by perceived contribution – not by rank or status or academic knowledge or “number of years of service”. Now that’s empowerment, no?
So what do you think? Is your company structurally and behaviorally oriented for success in an increasingly networked, complex, and flattened world? Or is it the same old, same old, business as usual….. waiting to get gored to death by competitors who are.

















