Archive
Requisite Knowledge
In “Item 3. Design Patterns” of Stephen Dewhurst’s “C++ Common Knowledge: Essential Intermediate Programming“, he states the following:
Design patterns are often described as “micro-architectures” that can be composed with other patterns to produce a new architecture. Of course, selecting appropriate patterns and composing them effectively requires design expertise and native ability. However, even your manager will be able to understand the completed design if he or she has the requisite knowledge of patterns.
Uh, Stephen, you’re kidding, ain’t ya? In a project mini-corpricracy like the one below, you’ll be lucky if even the software lead knows what a pattern is, let alone the lofty manager. The software “Rocket-tect” will most likely know what a pattern is – but probably not how to apply it since he/she will be stuck in “lemme-show-u-how-smart-I-am” jargon-land. On the bright side, everybody in the power structure (which excludes the programmers, of course) will know what a Microsoft schedule, spreadsheet, and powerpoint deck are.
DYSCO Dancer
The figure below shows the top three levels of an N level textbook corparchy. Virtually all corpo monarchs present some visual camouflage like this to model their beloved corpricracy. The massive illusions that a diagram like this intends to project are:
- an orderly flow of timely, accurate status information upward;
- intelligent direction and guidance downward;
- cooperative collaboration both sideways and diagonally;
- a paragon of efficiency and excellence for all external and (especially) internal observers to embrace without inquiry.
Now, splash some cold water on your face and observe an example of a pseudo-realistic model of a typical DYSCO dance:
If you’ve inferred that the lightning bolt connections represent clever, but antagonistic and counterproductive relationships between rival DYSCO dancing factions, then you’d be right.
Some of my friends(?) have told me that I’m an elite DYSCO dancer. Are you?
Woodstock Refugee
I’ve taken some flak from some prim and proper people for the dorky, woodstock-refugee-like pic I’ve posted on my LinkedIn.com profile:
(In case you’re interested, that’s actually a pic of me on Bourbon Street down in Nawlins during Mardi Gras.) One of the comments that I’ve received on this totally “unprofessional” photo is:
Are you looking for companies who want to hire clowns?
LOL! Well, yeah, I am. If I do want, or have, to start looking for a new company to work for, I don’t want to draw attention from any big and stodgy institution whose HR department members think pictures are important. You see, I think those types of orgs are probably stuck in 1920’s FOSTMA mindsets and I’d rather not spend 40+ hours a week working for them. Of course, this tactic will drastically reduce the number of opportunities available to me, but so what. I’ll take my chances and change tactics if I absolutely have to.
Where Elitism Is Proper?
Ever since I stumbled upon Fred Brooks‘s meta-physical idea of “Conceptual Integrity” in his classic book, “The Mythical Man Month“, I’ve strived mightily to achieve that elusive quality in the software work that I do. Over twenty years ago, Mr. Brooks stated that the greatest conceptually integral designs were the product of one, or at most two, human minds. Fred asserts that his “one or two minds” principle still holds true today:
My fictional alter ego, Bulldozer aught aught, would’ve re-worded the beginning of the statement to “Most, if not all… “, but Fred’s message stills rings loud and true.
According to Fred, in today’s world of exponentially growing complexity and team sizes, conceptual integrity is more difficult to achieve than ever:
Why the increased difficulty? Because as a team grows larger, more minds will collide with each other to express and manifest their incompatible design ideas. Big projects can, and usually do, devolve into “design by committee” fiascos where monstrously over-complicated contraptions get created and foisted upon the world.
Ok, Ok, you say. Enough disclosure of the pervasive problem – we get it Yoda. What’s the solution, bozo? Here it is:
Even though it sounds simple to enact this policy, it’s not. The role of “Chief Designer” in a group of highly educated, independent thinking people is fraught with peril. It requires a dose of discipline imposition that can be perceived as “meanness” to external observers. Too much perceived meanness can cause a supporting team to morph into an unsupporting team and lead to the ejection and ostracism of the chief designer. Too little meanness and the possibility of achieving conceptual integrity goes right out the window – it’s Rube Goldberg city. Bummer.
Does your org explicitly recognize and implement the “Chief Designer” role – which is not the same as the softer, less technical, more politically correct, and more administrative “software lead”, “project manager”, “product manager”, and…….. “software rocket-tect” roles? If your org does formally implement the “Chief Designer” role, are your chief designers kept on a tight leash by higher ranking BUTTS, BMs, BOOGLs, SCOLs or CGHs that have no idea what “conceptual integrity” means? Worse, do your “Chief Designers” (again, if you have any) handcuff themselves in order to increase their promotability?
I’m not into corpo caste systems or stratified command-control hierarchies and I struggle endlessly to fight the instinct to play the “I’m smarter than you” game, but I agree with Mr. Brooks when he asserts that world class product design is one of those rare situations…..
How about you? Where do you stand…… or sit?
Note: The snippets in this blarticle were copied and pasted from Fred Brooks’s “The Design Of Design” pitch at the Construx Software Executive Summit. You can download and study it in its entirety from here: Summit Materials.
N Minus One Half
Other than chief patriarch, where do you think the best position is on a stratified N + 1 layer corpo org chart? Consider the N – 1/2 position. You know, the coveted “dotted line” reporting position where, for some strange reason, the lowly paid and respected exec admin is always listed with the exalted, treasury raiding conciglieres. Here’s why it’s my top choice for you to aspire to:
- By definition, and probably not by your accomplishments (if any), you’re over compensated since you’re so high up on the chart.
- You don’t have any direct reports or whining sub-hierarchies of people under you to placate.
- You have the job security that independent, highly paid consultants (who may actually add value) at your level of so-called expertise don’t have.
- You have unfettered access to the corpo monarch. This gives you virtually unlimited time to kiss arse.
So, are you gonna go for it? Not me. Just give me something interesting to work on with a group of competent people and a PHOR project manager who gets the RIRPRT. Oh, and of course, pay me fairly too.
The Sparfish
On a tip from HCL Technologies CEO Vineet Nayar, I purchased and started reading “The Starfish And The Spider“. In the book, authors Brafman and Beckstrom define seven principles of decentralized orgs of people:
- When attacked, a decentralized org tends to become even more open and decentralized.
- It’s easy to mistake decentralized orgs (starfish) for centralized orgs (spiders).
- A decentralized org doesn’t have central intelligence; the intelligence is spread throughout the system.
- A decentralized org can easily mutate.
- A decentralized org sneaks up on you.
- As industries become decentralized, overall profits decrease.
- Put people into a decentralized org and they’ll automatically want to contribute.
Because of numbers 3 and 6, owners and SCOLs of centralized command and control hierarchies will never embrace the “starfish” concept. The self-centered need for SCOLs to project the image that “I’m great and you’re not” (number 3) and the constant external pressure to generate increasing profits (number 6) guarantee the status quo for all but the most enlightened leaders. However, because number 7 is the holy grail for the CGHs that sit on the throne, they try their best to feign being a starfish while remaining a spider. This systemic and self-defeating behavior is recursively nested all the way down the CCH; from the upper echelon of VPs and directors down through the fatty middle management layers and ultimately down to the BMs that rule at the interface with the DICforce.
Like Mr. Nayer, I don’t buy into the Brafman/Beckstrom set of principles 100%. Their starfish/spider metaphor works well up to a point. For example, a spider is much more mobile than a starfish; which enables it to be more proactive in acquiring the resources it needs to survive. Specifically, I believe that a hybrid “sparfish” org can increase profits while simultaneously providing an environment in which all members automatically want to contribute. By distributing resources more equitably via democracy and implementing a true meritocracy, the best of both species can be merged. The trick is figuring out how to freakin’ do it, no?
Status Seekers And Superheroes
Some people don’t like the dude, but I love Richard Branson. Why? Because he breaks the mold of CEOs who steadfastly cling to their self-image of infallibility and hide within their enclaves for fear of ruining said image and appearing human. Check out this paragraph from “It’s all About the People“.
Try to avoid hiring status seekers, as they tend to distance themselves from their employees. Look for people who care passionately about the company and not simply their status within it. In my experience, they must want to build a business that all its employees can all be proud of – one that will look after its staffers and customers alike. Of course, you can’t get it right every time. When you do make the wrong management decision, it’s vital to act decisively. As the saying goes, “Rot starts at the top”. – Richard Branson
The trick, of course, is knowing how to separate the wheat from the chaff; the bozos from the non-bozos. Mr. Branson goes on to talk about the importance of ferreting out problems before they mushroom into full blown crises:
How will you know when things are going wrong? In the early days at Virgin, I would give out my phone number to all our music company staffers and tell them to call me whenever they felt we were doing something really wrong. This was key to our development as a business, both because it helped me to identify problems early on and, more importantly, because it let the employees know that management was ready to listen to them. Fostering this kind of dialogue is essential if you want to build a company that will grow and thrive. Your staff will feel more valued and committed if they really believe you are listening to them, and you will benefit from hearing a lot of great ideas from the people on the front lines. – Richard Branson
I think the two points that Richard illuminates go hand in hand. When a SASS (who shouldn’t have been hired in the first place) is the primary cause of a problem, he/she will cleverly camouflage and redirect the blame. Having successfully moved him/her self out of harm’s way, our SASS will next offer to step up, don his/her superhero suit, and dissolve the crisis. Of course, the SASSholes situated above our superhero in the CCH will happily guzzle the full glass of koolaid.
Read, Read, Read
To put it mildly, I’m not too fond of software project and “functional” software managers that don’t read code. Even worse, wanna-be-manager tweeners and lofty software “architects” who don’t read code are the pits. Note that I’m not demanding that these exalted ones write code, just actually RTFC (Read The F#@^&*! Code). Why? I thought you’d never ask…..
You see, I’m a believer in the “trust but verify” motto popularized by Ronald Reagan during the cold war. The only pseudo-objective way to truly assess progress, consistency, and quality on a software project is to sample the product – you know, the code. If you know of a better way, then I’m all ears.
It’s not that I don’t trust people to try their best, it’s just that most hierarchical cultures are toxic by unintentional design and that forces people to innocently cover up or camouflage a lack of progress when they fill out their “weekly status sheets” or verbally report progress at useless CYA (Cover Your Arse) meetings. Sadly, once DICs get appointed into elite manager and architect titles, they tend to leave their code reading and (especially) writing days behind. Of course, they’ve arrived (Halleluja!) and they no longer have to do any “janitorial” work that can be done by fungible DORKs.
How about you? Do you think people in the roles of software project manager, software functional manager, and software architect should actively read code as part of their jobs?
In many companies, enterprise architects sit in an ivory tower without doing anything useful. – Ivar Jacobson
The Sociopaths, The Clueless, And The Losers
So, you’ve never heard of the “gaping void”? Hugh MacLeod? “Ignore Everybody“? Here’s a taste of Hugh’s work:
Of course, I fall into Hugh’s “Losers” category, but considering the alternatives I feel pretty good.
For you fellow software weenies, here’s what Grady Booch (in Masterminds Of Programming) has to say:
There’s a delightful site called Gaping Void. He’s basically a PR-type person and his claim to fame is he does art on the back of business cards. But he has this riff which has been very popular about how to be creative. You might point your readers to that one.
Uh, what are you waiting for? Scurry on over to Hugh’s site and sign up for his daily cartoon. You won’t be disappointed and you’ll feed your famished mind with some tasty food. Yum yum!
Personal Fulfillment Needs
What type of org do you work for? A DEPAM like Org A, a stinkpot CCH like Org D, or somewhere in between in a mediocre hierarchy that works to some extent?
If you run an Org, reflect on which type you think you preside over. Then, after making your decision, ask your people what they think – and not in some big public forum where they have no choice but to say what you want to hear. In other words, don’t forget to make it “safe” for them to really express what their true feelings are. On second thought, fuggedaboutit and keep your infallible tiara firmly in place. You can’t risk the chance of getting hurt and externally showing that you’re only a human being – cuz that would be terrible for the org. Or would it?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 