Archive
Accessible And Accessed
One of the metrics that a lot of corpo hierarchs assess themselves on is how accessible they are to their people. However, being accessible (textbook open door policy, walking the halls, e-mail, pseudo-mandated all hands meetings) doesn’t mean being accessed. For obvious reasons, they don’t measure themselves on this important metric, especially how frequently they are accessed (voluntarily and unsolicited) by their non-direct reports. In the vast majority of corpocracies, the number of accesses per unit of time goes down as the difference between caste levels of the accessor and accessee goes up. Just because that’s the way it’s always been doesn’t mean that’s the way it should or could be.
Spoiled And Lazy; Hungry And Energetic
A few years ago, I read an opinion piece regarding the demise of the US auto industry. The author stated that because they were spoon fed boatloads of money by the US government to design and build military hardware during WWII, the car companies morphed into spoiled and lazy sloths; they stopped innovating on their own nickel. Unless a sugar daddy (like the US government) was going to externally subsidize the effort, they weren’t gonna open the company coffers to develop new products or vastly improve their existing ones. Because of this overly conservative mindset (and the poo pooing away of Deming’s quality movement), the Japanese eventually blew right by the big three – even though their nation was decimated by the war and they had to start from scratch.
The same danger applies today, every day, to every company that builds things, especially big things, for government orgs. Understandably, since creating and continuously improving big complex systems requires big investments and big scary risks to be overcome, companies are loathe to pour money into what may eventually turn out to be an infinite rat hole. However, if all the competitors in the market space have the same welfare mindset, then no one will sprint out ahead of the pack and all participants may still prosper – until money gets tight. When the external dollar stream slows to a trickle, those (if any) competitors who’ve boldly invested in the future and successfully transformed their investments into product improvements and new product portfolio additions, rise to the top. It’s the hungry and energetic, not the spoiled and lazy, that continuously prosper through good times and bad.
Is your company spoiled and lazy, or hungry and energetic? If it’s the former, what actions does your company take when tough economic times emerge and the money stream slows?
We Don’t Want Yours
We want our group to be less conflict averse so that the best ideas can be forged within the crucible of debate and (sometimes) heated dialog. We also want passion from our people. As a matter of fact, we demand it of everyone in our group.
BUT!
We don’t approve of your over-the-top confrontational style and we don’t approve of the ways that you externalize your passion. Sadly, we don’t have any role models in our management ranks to lead the “conflict aversion reduction and passion elevation” initiative. Thus, we have no clue of how we want our people to initiate confrontation or express passion, but we’ll know it when we see it, of course.
WTF?
Recruitment
Surprisingly, in spite of my relentlessly continuous rants against a sea of CCHs, BMs, and STSJs as far as the eye can see, I’ve been contacted by a handful of recruiters probing into my availability for jumping ship. Either they don’t know this blog exists and they haven’t read any of my blasphemous blog posts, or they have read some of them and they still think I can help their clients make money. The former is most likely, but if it’s the latter, then I’m stunned and I hope their clients have the same 21st century mindset as they do.
Since I’m very happy where I am, I will only consider those proposals that satisfy the following requirements. Of course, they’re presented as a bland, linear, 1970’s list of “shalls”.
- The potential employer shall (R-1) offer me 2X my current 6 figure salary
- The potential employer shall (R-2) offer me an opportunity to work on a vast array of interesting new product developments or existing product enhancements. I reserve the right to decide what “interesting” means
- The potential employer shall (R-3) supply me with all the tools I need to do my job and allow me to work from home 90% of the time.
- The potential employer shall (R-4) pay all expenses for me to travel to and from the employer’s home base if the distance between my house and the home base is greater than 20 miles.
- The potential employer shall (R-5) entrust me with an unlimited training budget to allow me to continuously probe, sense, cut through the camouflage, and evaluate the applicability of new software technologies to the employer’s product portfolio.
- For the sole reason of getting people to listen more closely to what I have to say on matters within my scope of knowledge and expertise, the employer shall (R-6) endow me with some kind of BFT. More than one title would be preferable because it may be the tie-breaker amongst multiple, simultaneous employment offers.
What do you think? Outrageously arrogant and full of hubris? Reasonable and practical? Let me know if you think I should shit-can this post and hope that no internet archive crawlers get a hold of it. D’oh!
A Democratic Workplace? No Freakin’ Way!
“We’ll send our sons anywhere in the world to die for democracy,” says Ricardo Semler (CEO of Semco), “but don’t seem to apply the concept to the workplace. This is a tragic error, because people on their own developing their own solutions will develop something different“.
In Semler’s own firm, there are no five-year business plans (which he views as wishful thinking), but rather “a rolling rationale about numbers.” A project takes off only if a critical mass of employees decides to get involved. Staff determine when they need a leader, and then choose their own bosses in a process akin to courtship, says Semler, resulting in a corporate turnover rate of 2% over 25 years.
Interested in hearing more from Mr. Semler? Then check out this video of a lecture he gave to elite MIT business students way back in 2005:
Blasphemy! We know what’s best for all the cake eaters in our kingdom because we’re infallible, of course. That couldn’t possibly work here because our business is too different. It’s “not applicable“.
Incremental Chunked Construction
Assume that the green monster at the top of the figure below represents a stratospheric vision of a pipelined, data-centric, software-intensive system that needs to be developed and maintained over a long lifecycle. By data-centric, I mean that all the connectors, both internal and external, represent 24 X 7 real-time flows of streaming data – not “client requests” for data or transactional “services”. If the Herculean development is successful, the product will both solve a customer’s problem and make money for the developer org. Solving a problem and making money at the same time – what a concept, eh?
One disciplined way to build the system is what can be called “incremental chunked construction”. The system entities are called “chunks” to reinforce the thought that their granularity is much larger than a fine grained “unit” – which everybody in the agile, enterprise IT, transaction-centric, software systems world seems to be fixated on these days.
Follow the progression in the non-standard, ad-hoc diagram downward to better understand the process of incremental chunked development. It’s not much different than the classic “unit testing and continuous integration” concept. The real difference is in the size, granularity, complexity and automation-ability of the individual chunk and multi-chunk integration test harnesses that need to be co-developed. Often, these harnesses are as large and complex as the product’s chunks and subsystems themselves. Sadly, mostly due to pressure from STSJ management (most of whom have no software background, mysteriously forget repeated past schedule/cost performance shortfalls, and don’t have to get their hands dirty spending months building the contraption themselves), the effort to develop these test support entities is often underestimated as much as, if not more than, the product code. Bummer.
Four Managers And An Engineer
A lot of people have heard of the blockbuster movie “Four Weddings And A Funeral”, but no one has heard of the cinematic release in incubation titled “Four Managers And An Engineer“. The story line goes like this:
- One manager calls a “planning” meeting and invites three peer managers (actually two peers and one pseudo-manager) and one enginerd.
- The meeting host manager presents an initial powerpoint plan to the group.
- At the bottom of each and every plan page, the one enginerd’s name appears in a colored box coupled with a non-trivial task to do and a critical “need by” date.
- The enginerd points out the irony of the four-to-one ratio of managers to enginerds present at the meeting when other more important managers up the chain are crying out for higher profit numbers.
- To further build tension in the melodrama, the enginerd asks why no one else on the team was assigned any of these critically important tasks.
- One more Hershey kiss is added to the pile of poop when the enginerd graphically shows that sequentially placing the task boxes end-to-end (since they’re assigned to one bottleneck taskee) would blow the “planned” schedule out of the water.
- As the coup de grace, the enginerd asks what non-technical management tasks the managers assigned to themselves, and why they’re not in the plan with their names next to them.
- In a coordinated rage, the managers attack the engineer and bludgeon him/her to death with their blackberrys and leather bound Covey planners.
- The managers then; hide the body, replace the name of the deceased engineer on every page of the powerpoint plan with that of another enginerd, call another meeting, and invite themselves along with the next victim to their group-conspired serial killing spree.
Like another blockbuster movie, “Ground Hog Day”, the cycle repeats itself ad-infinitum. Unlike Ground Hog Day, there’s no breaking out of the loop and no transitioning to a happy Hollywood ending. The movie drones on until the audience gets bored to death and leaves the theater or the projector breaks down, whichever comes first. Wanna role in my movie? Wanna be the director? Wanna finance it?
Data-Centric, Transaction-Centric
The market (ka-ching!, ka-ching!) for transaction-centric enterprise IT (Information Technology) systems dwarfs that for real-time, data-centric sensor control systems. Because of this market disparity, the lion’s share of investment dollars is naturally and rightfully allocated to creating new software technologies that facilitate the efficient development of behemoth enterprise IT systems.
I work in an industry that develops and sells distributed, real-time, data-centric sensor systems and it frustrates me to no end when people don’t “see” (or are ignorant of) the difference between the domains. With innocence, and unfortunately, ignorance embedded in their psyche, these people try to jam-fit risky, transaction-centric technologies into data-centric sensor system designs. By risky, I mean an elevated chance of failing to meet scalability, real-time throughput and latency requirements that are much more stringent for data-centric systems than they are for most transaction-centric systems. Attributes like scalability, latency, capacity, and throughput are usually only measurable after a large investment has been made in the system development. To add salt to the wound, re-architecting a system after the mistake is discovered and ( more importantly) acknowledged, delays release and consumes resources by amounts that can seriously damage a company’s long term viability.
As an example, consider the CORBA and DDS OMG standard middleware technologies. CORBA was initially designed (by committee) from scratch to accommodate the development of big, distributed, client-server, transaction-centric systems. Thus, minimizing latency and maximizing throughout were not the major design drivers in its definition and development. DDS was designed to accommodate the development of big, distributed, publisher-subscriber, data-centric systems. It was not designed by a committee of competing vendors each eager to throw their pet features into a fragmented, overly complex quagmire. DDS was derived from the merger of two fielded and proven implementations, one by Thales (distributed naval shipboard sensor control systems) and the other by RTI (distributed robotic sensor and control systems). In contrast, as a well meaning attempt to be all things to all people, publish-subscribe capability was tacked on to the CORBA beast after the fact. Meanwhile, DDS has remained lean and mean. Because of the architecture busting risk for the types of applications DDS targets, no client-server capability has been back-fitted into its design.
Consider the example distributed, data-centric, sensor system application layer design below. If this application sits on top of a DDS middleware layer, there is no “intrusion” of a (single point of failure) CORBA broker into the application layer. Each application layer system component simply boots up, subscribes to the topic (message) streams it needs, starts crunching them with it’s app-specific algorithms, and publishes its own topic instances (messages) to the other system components that have subscribed to the topic.
Now consider a CORBA broker-based instantiation of this application example (refer to the figure below). Because of the CORBA requirement for each system component to register with an all knowing centralized ORB (Object Request Broker) authority, CORBA “leaks” into the application layer design. After registration, and after each service has found (via post-registration ORB lookup) the other services it needs to subscribe to, the ORB can disappear from the application layer – until a crash occurs and the system gets hosed. DDS avoids leakage into the value-added application layer by avoiding the centralized broker concept and providing for fully distributed, under-the-covers, “auto-discovery” of publishers and subscribers. No DDS application process has to interact with a registrar at startup to find other components – it only has to tell DDS which topics it will publish and which topics it needs to subscribe to. Each CORBA component has to know about the topics it needs and the services it needs to subscribe to.
The more a system is required to accommodate future growth, the more inapplicable a centralized ORB-based architecture is. Relative to a fully distributed coordination and auto-discovery mechanism that’s transparent to each application component, attempting to jam fit a single, centralized coordinator into a large scale distributed system so that the components can find and interact with each other reduces robustness, fault tolerance, and increases long term maintenance costs.
CCP
Relax right wing meanies, it’s not CCCP. It’s CCP, and it stands for Context, Content, and Process. Context is a clear but not necessarily immutable definition of what’s in and what’s out of the problem space. Content is the intentionally designed static structure and dynamic behavior of the socio-technical solution(s) to be applied in an attempt to solve the problem. Process is the set of development activities, tasks, and toolboxes that will be used to pre-test (simulate or emulate), construct, integrate, post-test, and carefully introduce the solution into the problem space. Like the other well-known trio, schedule-cost-quality, the three CCP elements are intimately coupled and inseparable. Myopically focusing on the optimization of one element and refusing to pay homage to the others degrades the performance of the whole.
I first discovered the holy trinity of CCP many years ago by probing, sensing, and interpreting the systems work of John Warfield via my friend, William Livingston. I’ve been applying the CCP strategy for years to technical problems that I’ve been tasked to solve.
You can start using the CCP problem solving process by diving into any of the three pillars of guidance. It’s not a neat, sequential, step-by-step process like those documented in your corpo standards database (that nobody follows but lots of experts are constantly wasting money/time to “improve”). It’s a messy, iterative, jagged, mistake discovering and correcting intellectual endeavor.
I usually start using CCP by spending a fair amount of time struggling to define the context; bounding, iterating and sketching fuzzy lines around what I think is in and what is out of scope. Next, I dive into the content sub-process; using the context info to conjure up solution candidates and simulate them in my head at the speed of thought. The first details of the process that should be employed to bring the solution out of my head and into the material world usually trickle out naturally from the info generated during the content definition sub-process. Herky-jerky, iterative jumping between CCH sub-processes, mental simulation, looping, recursion, and sketching are key activities that I perform during the execution of CCP.
What’s your take on CCP? Do you think it’s generic enough to cover a large swath of socio-technical problem categories/classes? What general problem solving process(es) do you use?
Management Gurus
Every student of management methods has heard of the blah, blah mainstream gurus like Prahalad, Charan, Christensen, Covey, Collins et al. How many of you have heard of Argyris, Mintzberg, Ackoff, Warfield, Ackoff, Beer, Livingston? You never hear of these dudes because they’re out on the lunatic fringe. They’re heretical, in-your-face realists who tell it like it is; which rubs CEOs and self-important top management teams the wrong way, of course. Thus, their work is ignored.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 