Archive
A Big Fat Waste Of Time
Having recently finished the above two heretical books on the undiscussable joke that is “the Annual Performance Review“, I coincidentally stumbled upon this recent FastCompany.com article: “Why Year-End Reviews Are A Big Fat Waste Of Time”.
Alas, even though author Denis Wilson plants some decent advice for managers in the blarticle, it still reeks of a slight “tweak” to the notoriously bad, but eerily unopposed, APR practice.
After posting the link to the blarticle on Twitter, I had this interesting exchange with Adam Yuret:
Upon reflection on why such a horrendously demeaning practice like the APR still exists in the 21st century, BD00 has come to the conclusion that the guild of management collectively thinks:
- The APR actually “works” or,
- They know it doesn’t work but they have no motivation to attempt such a big and scary change to the org, or
- They know it doesn’t work but they have no motivation to explore alternatives for achieving what the APR is actually supposed to do.
So, How Do You Know?
In the software development industry, going too slow can result in nothing getting done in an “acceptable” amount of time and thus, impatient managers cancelling projects. On the other hand, going too fast can result in hackneyed designs, halted downstream progress due to lots of rework on an unmanageable code base, and thus, frustrated managers cancelling projects.
As the figure below shows, the irony is that going too slow can result in less sunk cost due to earlier cancellation than going too fast – which gives a false illusion of great progress till the fit hits the shan.
So, how do you “objectively” know if you’re going too fast or too slow? It’s simple: you freakin’ don’t. However, in a world increasingly dominated by “agile” indoctrination, faster seems to be always equated with better and the tortoise vs. hare parable is heresy.
I-Speak
I don’t know where I read it, but I remember someone giving great advice about using “I-Speak” to present your case on a sensitive issue. Don’t go blasting away and saying stuff like “everyone thinks the system is a freakin’ disaster“. Instead, say “I have a hard time using the system as it’s designed“.
In really uptight and unresponsive groups, preface your concern with “I can only speak for myself, but…“. But don’t forget, in zero tolerance bureaucracies, keep your “I” trap totally shut tight and keep toiling along in quiet desperation.
Underlying Assumptions
The underlying assumptions harbored by executive decision-makers drive an org’s processes/policies. And those processes/policies influence an org’s social and financial performance. As a rule, assumptions based on Theory X thinking lead to mediocre performance and those based on Theory Y lead to stellar performance. Most org processes/policies (e.g. the annual “objective” performance appraisal ritual) are Theory X based constrictions cloaked in Theory Y rhetoric – regardless of what is espoused.
Preventers, Not Managers
The worst companies directly contribute to the physical and emotional deterioration of their DICforces by unceasingly imposing ridiculous schedules and ratcheting up the (unspoken) pressure to work massive amounts of unpaid overtime for long stretches of time. Average companies do the same under the tired old mantra of “it’s a hostile business environment“, but they take good care of their DICsters after much damage is done. The best of the breed are highly self-aware systems that actively practice “crisis prevention” – not “crisis management“. They diligently monitor the “system’s” vital signs and know when things are getting too toxic for their people. Unlike the worst and the average, the best actually take effective action to relieve the stress on their people before the wreckage accumulates. They’ll sacrifice some almighty dollars by relaxing schedules, or giving some extra days off, or frequently providing small tokens of appreciation to counter the toxicity of the operational environment. They are preventers, not managers.
Wouldn’t it be kool if the role of “manager” was jettisoned in favor of “preventer“? If anything, it would at least drive home what those in charge of others should really be doing – preventing, not managing.
The Yearning For Autonomy
Since they generally increase operating costs, trigger “it’s not my job” myopia, and encourage us-vs-them friction, I’m not a fan of unions. Nevertheless, I found this article on TechCrunch.com amusingly interesting: “Want To Unionize Developers? Focus On Workplace Democracy”. This passage caught my eye and triggered a chuckle:
Developers want autonomy. They don’t want to be jerked around by stupid managers who impose unrealistic deadlines, make impossible promises to clients and just generally disrespect their employees. Historically developers have had two options for dealing with bad management: find a better job or found a startup. But worker self-management would offer a third options — give the developers control over their own work.
Alas, those managers that are stupid don’t know they’re stupid and those employees who are disrespected don’t know they’re disrespected. Between: 1) these two BD00 made-up facts; 2) management’s fear of loss of control and stature; 3) the declining reputation of unionization over the years – don’t expect the idea of software developer unions to take hold soon; if ever.
Ignored, Denied, Or Pushed Aside
Fresh from Margaret Wheatley‘s “So Far from Home: Lost and Found in Our Brave New World“, I present you with these four vexing questions:
If you answered “yes” to any of these questions and your expectations were met, then you’re incredibly lucky because:
They’re based on an assumption of rational human behavior— that leaders are interested in what works— and that has not proven true. Time and again, innovators and their highly successful projects are ignored, denied or pushed aside, even in the best of times. In this dark era, this is even more true. – Margaret Wheatley
Not that I’m an innovator, but these questions hit me hard because it took decades of disappointment and bewilderment for me to realize that Ms. Wheatley is right. But you know what? Once I became truly aware that “it is the way it is“, I felt liberated. Now I do the work for the work itself. An intimate, joyful communication between the creator and the created.
Quantum Chaotic Complexity
How many institutions are still being managed in accordance with the knowledge learned from 17th century physics? These days, its networks and relationships, not billiard balls and force.
Blown, Busted, And Riddled
The CMMI-DEV model for software development contains 20+ Key Process Areas (KPA) that are required to be addressed by an org in order to achieve a respectable level of compliance. With such complexity, one could think that L3+ orgs would sponsor periodic process refresher courses for their DICforces in order to minimize social friction between process enforcers and enforcees and reduce time-sucking rework resulting from innocent process execution errors made by the enforcees.
BD00 postulates that many CMMI L3+ orgs don’t hold periodic, rolling process refreshers for their cellar dwellers. The worst of the herd periodically retrains its technical management and process groups (enforcers) , but not its product development teams (enforcees). These (either clueless or innocently ignorant) orgs deserve what they get. Not only do they get blown budgets, busted schedules, and bug-riddled products, but they ratchet up the “us vs. them” social friction between the uninformed hands-on product dweebs and the informed PWCE elites.
So Professional That It’s Unprofessional
Mike Williams is one of the big three Erlang creators (along with Joe Armstrong and Robert Virding) and the developer of the first Erlang Virtual Machine. Since then, he’s “moved up” and has been working as a software engineering manager for 20+ years. In his InfoQ talk titled “The Ideal Programmer – Why They Don’t Exist and How to Manage Without Them?“, Mike presents this hilarious slide:
It’s hilarious because, if you browse web sites like LinkedIn.com and Monster.com, you’ll find tons of similar, impossible-to-satisfy job descriptions. Everybody, especially the job description writer, knows that exhaustive “requirements” lists like these are a crock of BS. This practice is so professional that it’s unprofessional. So, why does it persist?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 