Archive
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?
Howard, Me, And Polarization
I don’t have the athletic gifts to “be like Mike“, but I do have the right stuff to “be like Howard”, Howard Stern that is. Howie has made millions over the years by flawlessly executing the well known successful strategy of polarization employed by talking heads (O’Reilly, Limbaugh, Coulter, Franken, Ventura) everywhere. He’s an asshole to a lot of people, but he’s also a hero to a large group who pay dough to hear his potty mouth. I’m similar to Howie in that I’m a polarizing asshole to many, but I’m a hero to no one and there’s no one willing to pay for the verbal diarrhea that spews forth from my piehole. I would gladly take the millions if I had the chance, but I’m fine with where I am right now, in this moment. Unlike hundreds of millions of people, I have what I need and I need what I have.
Oh, I almost forgot. Merry Xmas to all and don’t forget to connect with your loved ones today.
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.
A Costly Mistake?
Assume the following:
- Your flagship software-intensive product has had a long and successful 10 year run in the marketplace. The revenue it has generated has fueled your company’s continued growth over that time span.
- In order to expand your market penetration and keep up with new customer demands, you have no choice but to re-architect the hundreds of thousands of lines of source code in your application layer to increase the product’s scalability.
- Since you have to make a large leap anyway, you decide to replace your homegrown, non-portable, non-value adding but essential, middleware layer.
- You’ve diligently tracked your maintenance costs on the legacy system and you know that it currently costs close to $2M per year to maintain (bug fixes, new feature additions) the product.
- Since your old and tired home grown middleware has been through the wringer over the 10 year run, most of your yearly maintenance cost is consumed in the application layer.
The figure below illustrates one “view” of the situation described above.
Now, assume that the picture below models where you want to be in a reasonable amount of time (not too “aggressive”) lest you kludge together a less maintainable beast than the old veteran you have now.
Cost and time-wise, the graph below shows your target date, T1, and your maintenance cost savings bogey, $75K per month. For the example below, if the development of the new product incarnation takes 2 years and $2.25 M, your savings will start accruing at 2.5 years after the “switchover” date T1.
Now comes the fun part of this essay. Assume that:
- Some other product development group in your company is 2 years into the development of a new middleware “candidate” that may or may not satisfy all of your top four prioritized goals (as listed in the second figure up the page).
- This new middleware layer is larger than your current middleware layer and complicated with many new (yet at the same time old) technologies with relatively steep learning curves.
- Even after two years of consumed resources, the middleware is (surprise!) poorly documented.
- Except for a handful of fragmented and scattered powerpoint files, programming and design artifacts are non-existent – showing a lack of empathy for those who would want to consider leveraging the 2 year company investment.
- The development process that the middleware team is using is fairly unstructured and unsupervised – as evidenced by the lack of project and technical documentation.
- Since they’re heavily invested in their baby, the members of the development team tend to get defensive when others attempt to probe into the depths of the middleware to determine if the solution is the right fit for your impending product upgrade.
How would you mitigate the risk that your maintenance costs would go up instead of down if you switched over to the new middleware solution? Would you take the middleware development team’s word for it? What if someone proposed prototyping and exploring an alternative solution that he/she thinks would better satisfy your product upgrade goals? In summary, how would you decrease the chance of making a costly mistake?
Serial Misbehavers Anonymous
Hello everyone. My name is Tony DaSilva, and I’m a serial misbehaver. I repeatedly and relentlessly attack sacred cows in broad daylight and unsuccessfully attempt to discuss the undiscussables both in public (to their faces) and in private (behind their backs). As you all know yourselves, this behavior is extremely counterproductive and it inflicts a considerable amount of psychological pain upon all those people around me, including those who are multiple hops away from the local carnage.
In addition to slam dunking turds into everybody’s punch bowl, this nasty affliction results in a predictable boomerang effect that overflows my own punch bowl with retaliatory grumpies. Often, the next day’s hangover leads to emotional waves of guilt washing over me and intense feelings of isolation. Someone please be my sponsor and help me to STFU during the tough times when the beast within awakens and wants to possess my body and soul yet once again. D’oh!
“Tony’s behavior was explainable, but not excusable” – KW
Open Kimono
I continue to be enamored and awed by the way the leadership at zappos.com operates the company. I’m convinced that they’re the real deal. They’ve obtained a level of business nirvana that balances altruism with profitability which is perhaps unmatched by any other company on earth – except for maybe Semco.
Sadly, even though Zappos continuously and willingly opens its kimono to all those who care to learn about how they nurture and sustain their success, the Zappos operational model probably won’t go very far. The endless sea of power-obsessed dinosaurs that rule the corpo roost are too clever (cleverness is how they got into the protected nest in the first place).
The most common refrain for rejecting any attempt to emulate Zappos “best practices” will be: “none of that stuff will work here because our business is totally different“. These will be the words of wisdom uttered from the same moo-herd potty mouths that repetitively proclaim “customers are number one and our employees are our most valuable asset“. Blah, blah, blah. Yawn, yawn, yawn. BS, BS, BS.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 