Archive
Wishful And Realistic
As software development orgs grow, they necessarily take on larger and larger projects to fill the revenue coffers required to sustain the growth. Naturally, before embarking on a new project, somebody’s gotta estimate how much time it will take and how many people will be needed to get it done in that guesstimated time.
The figure below shows an example of the dumbass linear projection technique of guesstimation. Given a set of past performance time-size data points, a wishful estimate for a new and bigger project is linearly extrapolated forward via a neat and tidy, mechanistic, textbook approach. Of course, BMs, DICs, and customers all know from bitter personal experience that this method is bogus. Everyone knows that software projects don’t scale linearly, but (naturally) no one speaks up out of fear of gettin’ their psychological ass kicked by the pope du jour. Everyone wants to be perceived as a “team” player, so each individual keeps their trap shut to avoid the ostracism, isolation, and pariah-dom that comes with attempting to break from clanthink unanimity. Plus, even though everyone knows that the wishful estimate is an hallucination, no one has a clue of what it will really take to get the job done. Hell, no one even knows how to define and articulate what done means. D’oh! (Notice the little purple point in the lower right portion of the graph. I won’t even explain its presence because you can easily figure out why it’s there.)
OK, you say, so what works better Mr. Smarty-Pants? Since no one knows with any degree of certainty what it will take to “just get it done” (<- tough management speak – lol!) nothing really works in the absolute sense, but there are some techniques that work better than the standard wishful/insane projection technique. But of course, deviation from the norm is unacceptable, so you may as well stop reading here and go back about your b’ness.
One such better, but forbidden, way to estimate how much time is needed to complete a large hairball software development project is shown below. A more realistic estimate can be obtained by assuming an exponential growth in complexity and associated time-to-complete with increasing project size. The trick is in conjuring up values for the constant K and exponent M. Hell, it requires trickery to even come up with an accurate estimate of the size of the project; be it function points, lines of code, number of requirements or any other academically derived metric.
An even more effective way of estimating a more accurate TTC is to leverage the dynamic learning (gasp!) that takes place the minute the project execution clock starts tickin’. Learning? Leverage learning? No mechanistic equations based on unquantifiable variables? WTF is he talkin’ bout? He’s kiddin’ right?
Ego To Talent Ratio
In Scott Berkun‘s “Managing Breakthrough Projects” video, Scott concocts a metric called the Ego-To-Talent ratio (ETTR). Here’s my highly unscientific and speculative curve that plots ETTR versus position on the company org chart.
See that bozo on the chart? That’s me. Where are you?
Crisis?, What Crisis?
The other day, I heard a song on Pandora from one of my fave albums of the 70s (yes, they were called albums back then); Supertramp‘s “Crisis?, What Crisis“. The album title reminded me of orgs that emotionally panic “under the covers” when a crisis occurs, but outwardly behave as if there is no crisis. By “behaving like no crisis is occurring“, I mean that the SCOLs in charge apply whatever band aids they can in the short term to get through the crisis but don’t do anything of substance to stave off, or better handle, future crises.
When the crisis at hand passes, the heroes are congratulated and: the org structure stays the same, the people in the top roles stay the same, the operational business processes remain the same, and most ominously, the patriarchal CCH mindsets stay the same. It’s back to the same-old, same-old, business as usual.
The figure below shows what maybe should happen when crises occur and learning takes place? Someone or some group willingly steps up to positively change the structures and behaviors so that the org can smoothly navigate through, and even thrive within, future crises. In the example below, it took 2 crises to stave off self destruction, right the course, and excel in the future. Alas, the problem with the previous sentence is the “someone or some group” phrase at the beginning.
Hurd Joins The Herd
I was considering writing a blog post about the downfall of Hewlett Packard’s CEO Mark Hurd, but I decided to back off. I figured that all the credentialed and highly respected tech columnists and bloggers have covered this horror story from all angles.
So, instead of my usual rag, rag, rag…… whine, whine, whine….. toll-u-so, toll-u-so, toll-u-sow verbage, I’ve written an empty husk of a blog post. The accompanying picture sux too….
Nevertheless, I’ll be back on my high horse and raging against the machine soon.
Innovation Types
In the beginning of Scott Berkun’s delightful and entertaining “Managing Breakthrough Projects” video, Scott talks about two supposed types of innovation: product and process. He (rightly) poo-pooze away process innovation as not being innovative at all. Remember the business process re-engineering craze of the 90’s, anyone? Sick-sigma? Oh, I forgot that sick-sigma works. So, I’m sorry if I offended all you esteemed, variously colored belt holders out there.
According to self-professed process innovators, the process innovations they conjure up reduce the time and/or cost of making a product or performing a service without, and here’s the rub, sacrificing quality. Actually, most of the process improvement gurus that I’ve been exposed to don’t ever mention the word “quality”. They promise to reduce time to market (via some newfangled glorious tool or methodology) or cost (via, duh, outsourcing). Some of these snake oil salesmen dudes actually profess that they can increase quality while decreasing time and cost.
The difference between a terrorist and a methodologist is that you can negotiate with a terrorist – Unknown
Most process improvement initiatives that I’ve been, uh, lucky(?) to be a part of didn’t improve anything. That’s because the “improvements” weren’t developed by those closest to the work. You know, those interchangeable, fungible people who actually understand what processes and methods need to be done to ensure high quality.All that those highly esteemed, title-holding, mini-Hitlers did was saddle the value makers and service providers down with extra steps and paperwork and impressive looking checklists that took away productive time formerly used to make products and provide services.
Process improvement is a high-minded, overblown way of saying “kill the goose that laid the golden egg before it lays another one“.
Be Humble
Zappos.com’s core value number 10 is: “Be Humble“. According to CEO Tony Hsieh via his book Delivering Happiness (DH), the “Be Humble” core value has probably had the most impact on hiring decisions at Zappos.com.
There are a lot of experienced, smart, and talented people we interview that we know can make an immediate impact on our top or bottom line. But a lot of them are also egotistical, so we end up not hiring them. At most companies, the hiring manager would probably argue that we should hire such a candidate because he or she will add a lot of value to the company, which is probably why most large corporations don’t have great cultures.
So, how can you weed out the BOOGLs, CGHs, CBMs, SCOLs, and determine whether a candidate fits well with your culture? Zappos.com requires each candidate-for-hire to go through two sets of interviews: one with the hiring group to evaluate skills fit, and the other with the Human Resources (HR) group to determine cultural fit. It’s the latter that sets Zappos.com apart from the herd (moooo!). They ask questions specifically derived from their set of 10 core values.
So much for being humble myself. If I was, this blog wouldn’t be soaked with acronyms like BOOGLs, CGHs, CBMs, SCOLs, and other childish terms from the readme.txt page 🙂
Note: Tony et al will be starting a book tour in August and they will be traveling around in a souped up DH bus. You can follow the happiness on Twitter at dhbus and dhbook and ceo@zappos.
Us And Them
Poor org leaders, or SCOLs, either maintain a stratified “Us And Them” (UAT) line in their orgs or worse – they purposefully create one. By hiring clones of themselves, multiple UAT lines of demarcation appear; choking off open, honest, inter-layer communication and breeding mistrust and disrespect.
Great leaders, or PHORs, skillfully obliterate UAT lines where they exist, or they heroically prevent UAT lines from arising in the first place. Of course, that’s what makes them great leaders.
Google, Zappos, And Me
Check it out:
I was preparing to write a blog post about Zappos.com’s core value “Be Humble“, but I forgot what number it was. So, I decided to Google it, and the above picture is what appeared in my browser. WTF? Holy Shite!
If this doesn’t get me a free pass to Zappos Insights, I don’t know what will!!!!!
Note: I swear that the pic wasn’t photo-shopped. I ain’t no Bernie Madoff.
Compensation Compression
The figure below shows the salary trends for a typical corpricracy comprised of DICs, BOOGLs, SCOLs, and CGHs. Notice that the sky’s the limit for manager types and compression occurs for the DICforce. Is that the way it should be? In theory, probably yes. In practice, most likely no.
The most frequent reason given by the mainstream management guild for rationalizing the curve is that managers have more responsibility and greater impact on an org than any “induhvidual contributor” DIC. That is true, but are they fulfilling their responsibility? Is their impact positive or negative? Oh sure, every viable org has at least a handful of PHOR managers that fulfill their responsibilities and positively impact the org, but all mediocracies are filled with BOOGLs, SCOLs, and CGHs who don’t fulfill their responsibility and negatively impact the corpricracy.
When the inequity in compensation becomes blatantly obvious and intolerable, a handful of underappreciated DICs usually break off and form their own startup where everyone starts out as either a CABBIE or PHOR. Ironically, as the startup grows and allegedly matures:
- The majority of PHORs transform into BOOGLs, SCOLs, and CGHs while retaining the mindset that they’re still PHORs.
- The BOOGLs, SCOLs, and CGHs start perceiving the CABBIEs as DICs; a cost to be minimized.
Unconscious, Conscious, Bozo, Helper
The following sparsely “bent” UML class diagram (see the end of this post for a quick and dorky tutorial for interpreting the diagram) exposes Bulldozer00’s internal hierarchy of manager types. Yours may be different, especially if you’re a manager.
The Base Class
The hierarchy’s Manager base class supplies all the mundane operations that sub-classed managers inherit and perform. For example, all managers in this particular inheritance tree make project plans, track project progress, and monitor progress against the plans. The frequency at which these behaviors are performed, along with the exact details of how they’re executed, is both manager-specific and project-specific. For example, during performance of the “takeStatus” operation, one manager may require project members to write out detailed weekly status reports whilst another may just require informal verbal status.
The Sub-Classes
The second level in Bulldozer00’s morbid and disturbing manager class hierarchy is more interesting. There are two polar opposite sub-types; Bozo and Helper. In addition to inheriting the boring, mechanical, and necessary responsibilities of the Manager base class, these subclasses provide radically different sets of behaviors. For instance, the Bozo subclass provides an “ignoreDICs” behavior whilst the Helper subclass provides “listenToPeople” and “solicitIdeas” behaviors. Comparing the behavior sets between the two subclasses and then against your own manager(s), how would you classify your manager(s)?
As the diagram shows, there are two Bozo Manager subtypes: Conscious and Unconscious. There’s no equivalent subdivision for the Helper Manager type because all Helper Manager “instantiations” are fully conscious. Hell, since all the behaviors that Helper Managers exhibit are so extraordinarily rare, productive, and against-the-grain, there is no way they can be unconscious and not know what they’re doing.
In Bulldozer00’s experience, most Bozo Managers are of the Unconscious ilk. They continuously execute the counterproductive behaviors forwarded on to them via their Bozo inheritance, but they don’t realize how detrimental their actions and words are to the orgs they’re responsible for growing and developing. Since virtually all their fellow clique members behave the same way, they’re oblivious to alternatives and they can’t connect poor org performance to their own dysfunctional behaviors.
Forgive them, for they know not what they do. – Jesus
Lastly, we come to the Conscious Bozo Manager class. Beware of these dudes, of which there are few (thank god), because they are hell on wheels. These guys/gals know fully well that their behaviors/actions are both locally and globally destructive. But why, you ask, would they behave this way? Well, because they’re out to inflate their heads and wallets and there are no boundaries they wouldn’t cross to achieve their goals.
Advice
If you choose to embrace, internalize, and use Bulldozer00’s class hierarchy to evaluate and “privately” judge your managers, you might want to take these suggestions into consideration:
- Run like hell from the Conscious Bozo types.
- Do your best to bring consciousness to the legions of well meaning, but sleepwalking, Unconscious Bozo types
- Attach yourself like a lamprey to the Helper type
But why the hell would you want to “buy into” Bulldozer00’s manager taxonomy? Great freakin’ question!
Appendix: Mini Class Diagram Graphic Tutorial
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
