Archive
Change In Behavior
“Change your thinking, and your behavior will change.” How many times have you heard or seen that sentence? Of course, it’s true, but as ever, the devil’s in the details. In my case, I’ve often fooled myself into thinking that my thinking has changed when it really hasn’t. So, the question is, who are “I” and “myself” in the previous sentence?
How To, When To
It seems like someone at USA Today has been ingesting contraband. In “Stereotype of computer geeks fades and nerds are cool”, Haya El Nasser opines:
The stereotype of the geeky techie that persists in pop culture is fading in real life, thanks to the legacy of industry giants such as Apple founder Steve Jobs and the increasing dependence of more Americans on the skills of those who know how to make their gadgets work.
Some schools are offering one-day workshops that include tips on “office finesse” and wardrobe and body language and when to talk or when to pick up a dropped napkin when meeting with a prospective employer.
When to pick up a dropped napkin when meeting with a prospective employer? WTF! How about tips on:
- When it’s appropriate to tie your bib at the dinner table.
- When to clip your nose hairs.
- How long to wait before acting on a “there’s free leftover food in the conference room” e-mail.
- How often to apply deodorant
- How to emulate a British accent
- How to eat cake at a going away party
- When to clap at an all hands meeting
- How many breaths to breathe before hitting the “send-all” button
- How not to pile your plate sky high at free lunches
- How to snicker without getting caught
- How to detect tattletalers
- How to carry your coffee cup like Wally
- How to respond to the “what percent done are you?” question
- When you can skip washing your hands in the rest room
- How long to wait before consuming that seemingly forgotten lunch in the fridge
- When to be fashionably late to meetings
- How to wordsmith inappropriate questions to the company help desk into benign pleas for help
- How to <<insert your intractable issue here>>
Us And Them
BD00 speculates that all non-psycho leaders would love to dissolve the “us vs them” attitude that most likely pervades their org. Alas, it’s not easy to do when your org is structured as, and operates like, a standard command and control hierarchy. Here’s a list of reasons why the “us vs them” conundrum endures within the walls of the CCH:
- We unilaterally set the rules, policies and procedures they are required to unquestioningly follow
- We get bonuses and they get COLAs (Cost Of Living Adjustments)
- We plan their work and evaluate them; and there is no “quid pro quo Clarisse“
- We have a loose set of criteria for evaluating for ourselves and a strict set for evaluating them
- We have nicer offices than them
- We promote/demote them, not vice versa
- We conform them to the org and we conform the org to us.
- We physically co-locate our team in a corner and fragment their teams throughout the org
Got any other “us and them” reinforcers to add to the list?
Request For Fashion Help
In a few hours, BD00 will be boarding a plane for sunny Melbourne FL to participate in “Golf Camp 2012“. As he did in 2010, BD00 would like to ask for your help in picking out his opening day outfit for a bogey free Sunday. Err, since BD00 plans to go shirtless to highlight his Hans-and-Franz guns, you can at least pick out the shorts part of the ensemble.
The figure below shows BD00’s paltry wardrobe selection back in 2010.
Of course, due to prudent stock picking, sold out speaking appearances, consulting fees, and master leveraging of massive tax loopholes, BD00 has been able to expand his links couture commensurate with the growth in his girth and enlargement of his ego. Thus, BD00 has added the following “design patterns” to his Kardashianesque wardrobe:
So, what’s it gonna be dear reader? Charlie? Pisces-dude? Lorraine? Bird? Mark? Other closet readers?
Fat, Lazy, Slob Who Did Good
Kevin Smith’s “Tough Sh*t: Life Advice from a Fat, Lazy Slob Who Did Good” is the first lite and breezy book that I’ve read in quite a while.
In between exercise sets at the gym, I scribbled down a quick review of the book. In keeping with the lazy slob theme, I didn’t transcribe the scribbles into e-form. So, here’s the review in raw and unedited form:
While prepping this post for publication, I got a kick out of the list of tags that wordpress.com recommended :
The “Shit” and “Clerks” tags were good calls, but freakin’ Condoleezza Rice????? I gotta have a word with the dude behind the curtain who patiently types in tag recommendations each time a draft is saved.
All Forked Up!
BD00 posits that many software development orgs start out with good business intentions to build and share a domain-specific “platform” (a.k.a. infrastructure) layer of software amongst a portfolio of closely related, but slightly different instantiations of revenue generating applications. However, as your intuition may be hinting at, the vast majority of these poor souls unintentionally, but surely, fork it all up. D’oh!
The example timeline below exposes just one way in which these colossal “fork ups” manifest. At T0, the platform team starts building the infrastructure code (common functionality such as inter-component communication protocols, event logging, data recording, system fault detection/handling, etc) in cohabitation with the team of the first revenue generating app. It’s important to have two loosely-coupled teams in action so that the platform stays generic and doesn’t get fused/baked together with the initial app product.
At T1, a new development effort starts on App2. The freshly formed App2 team saves a bunch of development cost and time upfront by reusing, as-is, the “general” platform code that’s being co-evolved with App1.
Everything moves along in parallel, hunky dory fashion until something strange happens. At T2, the App2 product team notices that each successive platform update breaks their code. They also notice that their feature requests and bug reports are taking a back seat to the App1 team’s needs. Because of this lack of “service“, at T3 the frustrated App2 team says “FORK IT!” – and they literally do it. They “clone and own” the so-called common platform code base and start evolving their “forked up” version themselves. Since the App2 team now has to evolve both their App and their newly born platform layer, their schedule starts slipping more than usual and their prescriptive “plan” gets more disconnected from reality than it normally does. To add insult to injury, the App2 team finds that there is no usable platform API documentation, no tutorial/example code, and they must pour through 1000s of lines of code to figure out how to use, debug, and add features to the dang thing. Development of the platform starts taking more time than the development of their App and… yada, yada, yada. You can write the rest of the story, no?
So, assume that you’ve been burned once (and hopefully only once) by the ubiquitous and pervasive “forked up” pattern of reuse. How do you prevent history from repeating itself (yet again)? Do you issue coercive threats to conform to the mission? Do you swap out individuals or whole teams? Do you send your whole org to a 3 day Scrum certification class? Will continuous exhortations from the heavens work to change “mindsets“? Do you start measuring/collecting/evaluating some new metrics? Do you change the structure and behaviors of the enclosing social system? Is this solely a social problem; solely a technical problem? Do you not think about it and hope for the best – the next time around?
Ready, Set, Go!
Risk-Reward Curve
I’d like to thank my new found e-friend Bob Marshall for triggering the creation of this scientifically unassailable graph:
Thinking Styles
I used to think: “DAMN IT! IT SHOULDN’T BE THIS WAY!” for just about every observation that I judged to be a “problem“. Now I think, “It shouldn’t be this way – but it is – lol“ for most observations that I judge to be problems. Of course, there are still far too many things that cause me to red-line, but it’s an incremental, iterative, and continuous learning experience.
If I’m lucky enough, I might even gravitate up to this fully, non-judgmental, thought-style: “It is this way, because it got this way“. However, I don’t think I’ll ever make it into the effortless thinking realm of Buddha/Lao Tzu/Eckhart Tolle/Byron Katy: “It is this way because it’s exactly the way it should be“.
How about you, dear reader? What’s your predominant thinking style? Has it been changing with age? Are you happy with it?
Protocol Deterioration
Russ Ackoff once said something like: “A system is not the sum of its parts. It’s the product of its part-interactions“. With that Ackoffism in mind, lo and behold the slooow and relentless process of inter-part protocol deterioration.
What state are your org protocols in? “Whoo Hoo!“, “Uh Oh!“, “D’oh!“, or “I Dunno!“?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 