Archive
Process Nazis
Unlike most enterprise software development orgs where “quality assurance” is equated to testing, government contractors usually have both a quality assurance group and a test engineering group. Why is that? It’s because big and bloated government customers “expect” all of its contractors to have one. It’s the way it is, and it’s the way it’s always been.
It doesn’t matter if members of the QA group never specified, designed, or wrote a line of software in their life, these checklist process nazis walk around wielding the process compliance axe like they are the kings of the land: “Did you fill out this unit test form?” “Do you have a project plan written according to our template?“, “Did you write a software development plan for us to approve?“, “Did you submit this review form?“, “Did you submit this software version definition form?“, “Do you have a test readiness form?“, “If you don’t do this, we’ll tell on you and you’ll get punished“. Yada, yada, yada. It’s one interruption, roadblock, and distraction after another. On one side, you’ve got these obstacle inserters, and on the other side you’ve got nervous, time-obsessed managers looking over your shoulder. WTF?
Since following a mechanistic process supposedly “proven to deliver results” doesn’t guarantee anything but a consumption of time, I don’t care much about formal processes. I care about getting the right information to the right people at the right time. By “right“, I mean accurate, unambiguous, complete, and most importantly – frreakin’ useful. For system engineers, the right information is requirements, for software architects it’s blueprints, for programmers it’s designs and source code, for testers it’s developer tested software. How about you, what do you care about?
The Factory And The Widgets
The process to assemble and construct the factory is much more challenging than the process to assemble and construct the widgets that the factory repetitively stamps out. In the software industry, everything’s a factory, but most managers think everything’s a widget in order to delude themselves into thinking that they’re in control. Amazingly, this is true even if the manager used to write software him/herself.
When a developer gets “promoted” to manager, a switch flips and he/she forgets the factory versus widget dichotomy. This stunning and instantaneous about face occurs because pressure from the next higher layer in the dysfunctional CCH (Command and Control Hierarchy) causes the shift in mindset and all common sense goes out the window. Predictability and exploitation replace uncertainty and exploration in all situations that demand the latter; and software creation always demands the latter. Conversation topics flip from talking about technical and CCH org roadblocks to obsessing about schedule and budget conservation because, of course, managers equate writing software with secretarial typing. The problem is that neglecting the former leads to poor performance of the latter.
Guilt And Coercion
In a classic CCH (Command and Control Hierarchy), the only two tools of motivation known to BMs (Bozo Managers) for getting people to sign up for no-win projects are Guilt and Coercion. Bad CCH BMs use both, and really bad BMs with a sweatshop mentality use coercion exclusively. Attempts to instill guilt are often prefaced with “Don’t you wannabe a team player?” or “It’s very important for the company”. A classic coercive one-liner is “Do this project or else!”
So, why don’t many smart DICs (Dweebs In the Cellar) step up and volunteer to lead tough projects? One reason is because smart DICs know that the toxic, fragmented, and stifling environment (created and nurtured by the very same BMs who are coercing and inflicting guilt) guarantees failure. Another reason is because textbook CCHs are bureaucracies and not meritocracies – regardless of what they espouse. Thus, all work is treated the same and everyone gets the same 3% raise no matter how hard they work or how much they neglect their own lives to “get the job done” . Can you think of other reasons?
Orchestrated Reviews
If you think your design is perfect, it means you haven’t shown it to anyone yet – Harry Hillaker
Open, frequent, and well-engineered reviews and demonstrations are great ways to uncover and fix mistakes and errors before they grow into downstream money and time sucking abominations. In spite of this, some project cultures innocently but surely thwart effective reviews.
Out of fear of criticism, designers in dysfunctional cultures take precautions against “looking bad“. Camouflage is generated in the form of too much or too little detail. Subject matter experts are left off the list of reviewers in order to uphold a false image of infallibility.
Another survival tactic is to pre-load the reviewer list with friends and cream puffs who won’t point out errors and ambiguities for fear of losing their status as nice people and good team players. In really fearful cultures, tough reviewers who consistently point out nasty and potential budget-busting errors are tarred and feathered so that they never provide substantive input again. In the worst cases, reviews and demonstrations aren’t even performed at all. Bummer.
Man, I Love This Guy
I’m not gay (not that there’s anything wrong with that), but I love Scott Berkun. I’ve spoken about him before, and it’s time to speak about him again. Scott’s got a new book out titled “Confessions Of A Public Speaker“. Like all of his other work, it’s a funny and insightful page turner.
It’s incredibly hard to be original, but everyone has the innate capability to be authentic. Scott is authentic. Check out this quote from the new book:
“In the interest of transparency and satisfying your curiosity, I average 25–30 lectures a year. Sometimes I’m paid as much as $8,000, depending on the situation. Maybe one-third are paid only in travel expenses or small fees, since they’re selfpromotional or for causes I’d like to help. Roughly 40% of my income is from book royalties and the rest from speaking and workshop fees. So far, I average around $100,000 a year, less than I made at Microsoft. However, I work fewer hours, am free from the 9 to 5 life, and have complete independence, which is worth infinitely more. I limit travel to once or twice a month, which means I turn away many gigs; I’d prefer to have more time than money, since you can never earn more time.”
Do you think many people have the cajones to expose that amount of detail about how much money they make? I don’t. Maybe I don’t because I feel guilty that I’m an overpaid and underperforming slacker. Scott follows up that trench coat opener with:
“I also think it would be good if salaries were made public, which is why I offered my fees and income. If more people did this, the overpaid and underpaid would be visible and more likely to be corrected. Or, total anarchy would ensue and civilization would end. Either way, it would be fun to watch.”
LOL! I love that idea and I would sign up to it any day. Then I, and everyone else, especially the corpocrats that run the show, would have a reference point of relativity for determining whether or not they’re overpaid.
There’s at least one company that I know of that operates this way – Semco. I know this because CEO Ricardo Semler said so in his book “Maverick“. How about you and your company? Would you try it out? Why not? If the result turned out to be FUBAR, you could always revert back to the same-old same-old and do what everybody else in the moo-herd does.
Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are even incapable of forming such opinions. – Albert Einstein
Standard CCH Blueprint
The figure below is a “bent” UML (Unified Modeling Language) class diagram of a standard corpo CCH (Command and Control Hierarchy). Association connectors were left off because the diagram would be a mess and the only really important relationships are the adjacent step-by-step vertical connections. Each box represents a “classifier”, which is a blueprint for stamping out objects that behave according to the classifier blueprint. The top compartment contains the classifier name, the second compartment contains its attributes, and the third compartment houses the classifier’s behaviors. Except for the DIC Product Development Team, the attributes of all other classifiers were elided away because the intent was to focus on the standard cookie-cutter behaviors of each object in the “system”. Of course, the org you work for is not an instantiation of this system, right?
What Would It be Like?
In this TED video, Sir Ken Robinson asks: “What would the world be like if all knowledge was instantaneously accessible to everyone at any time?” My less ambitious question is “What would the workplace culture be like if every manager, from the pinnacle of power all the way down the chain, made it his/her top (but obviously not only) priority to ensure that every one of his/her direct reports has continuous access to the tools, training, and information to get their jobs done?
Malcontents
Everyone’s heard of the stereotypical, disgruntled, malcontented, long time employee (SDMLTE) who “can’t wait to retire”. Why is this Dilbertonian image a stereotype? Because it’s so ubiquitous that it’s unquestioningly accepted by the vast majority of people as “that’s the way it is everywhere”. Well, is it? Do you really think that every organization on this earth has a surplus of SDMLTEs? Call me idealistic, but I assert “no”.
I opine that there are few (very, very, very, very, few) companies whose old warhorses, graybeards and bluehairs are uncommon, happy, content, long time employees (UHCLTE). Compared to the moo-herd of corpocracies that litter the land, these scarce diamonds in the rough have a huge UHCLTE to SDMLTE ratio. I’ll also profer that as a company gets larger, its UHCLTE to SDMLTE ratio decreases. That’s because as a company grows in size, bad management increases while great leadership decreases within the citadel walls – regardless of what the corpo stewards repeatedly espouse. Bummer.
Different Views
In all triangular CCHs (Command and Control Hierarchies), the DICs (Dweebs In the Cellar) directly create the value added outputs that sustain the enterprise. It’s management’s job (I think?) to ensure that the quality of those outputs is high enough for customers to want to buy the CCH’s products and services over competing CCHs. Of course, there are many ways to accomplish this. One is to inspect the outputs, a second is to get customer feedback, a third is to directly sample intermediate points in the value stream, and a trio of closely coupled others is to; personally descend to the cellar, observe what the DICs see, listen to what the DICs have to say regarding the issues/obstacles they face, and act “aggressively” (corpo-speak for “effectively”) to resolve those issues/obstacles. Note that the verbs, which require “hard work”, are emphasized.
The simple, dorky figure below tries to convey the difference in viewpoint between the DICs and the apex dwellers. Unlike the hierarchs, who operate freely and do whatever they want whenever they want, the DICs operate within a fragmented web of constraining “support” processes and “direction” from former DICs-turned-mini-hierarchs (picture mini-me in the Austin Powers movie franchise). Over time, since the hierarchs (and more importantly, the mini-hierarchs in training) stay away from the dirty and musty cellar and don’t do anything of substance to improve the environment, the stratification increases, the latency from raw input to value-added output increases, and the quality of output decreases. Bummer.
In CCHs with stay-at-home corpocrats, the deterioration in responsiveness and quality often gets detected at that point in time in which the real issues that are wreaking havoc are virtually unsolvable. Even then, the so-called leadership team stays away from the boiler room, speculating from afar at the causes of the performance deterioration. Out of all the methods for continuously monitoring and improving DIC performance, I assert (with no backing scientific evidence, of course) that frequent, periodic trips to the cellar to rub elbow grease with the DICs is the only true way of improving performance. Even if it’s impractical for the supreme hierarchs to do this, it’s not impractical for the mini-hierarchs, dontcha think?
Weakly Status Ritual
Everyone knows about the “weakly” status reporting ritual. It’s where the DICs (Dweebs In The Cellar) fill out and submit written status reports to the manager in charge (sic).
Did you ever wonder why status reporting is a one way street and it’s unquestioningly accepted as the norm in corpocracies everywhere? Whatever happened to “lead by example”? Why don’t managers fill out their very own weakly status reports and distribute them to their captive DICS? It’s because they don’t contribute or accomplish anything other than stapling the DIC reports together and kicking the result upstairs to the NLM (Next Level Manager) – who promptly ignores the POP (Package Of Poop) too. Side note: that’s where the term “POP server” originated.
If managers were required to submit weakly status reports to the DIC-force, what would they look like?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 