Archive
What Happened To Ross?
In the ideal case, an effectively led company increases both revenues and profits as it grows. The acquisition of business opportunities grows the revenues, and the execution of the acquired business grows the profits. It is as simple as that (I think?).
ROS (Return On Sales) is a common measure of profitability. It’s the amount of profit (or loss) that remains when the cost to execute some acquired business is subtracted from the revenue generated by the business. ROS is expressed as a percentage of revenue and the change in ROS over time is one indicator of a company’s efficiency.
The figure below shows the financial performance of a hypothetical company over a 10 year time frame. In this example, revenues grew 100% each year and the ROS was skillfully maintained at 50% throughout the 10 year period of performance. Steady maintenance of the ROS is “skillful” because as a company grows, more cost-incurring bureaucrats and narrow-skilled specialists tend to get added to manage the growing revenue stream (or to build self-serving empires of importance that take more from the org than they contribute?).
For comparison, the figure below shows the performance of a poorly led company over a 10 year operating period. In this case the company started out with a stellar 50% ROS, but it deteriorated by 10% each subsequent year. Bummer.
So, what happened to ROS? Who was asleep at the wheel? Uh, the executive leadership of course. Execution performance suffered for one or (more likely) many reasons. No, or ineffective, actions like:
- failing to continuously train the workforce to keep them current and to teach them how to be more productive,
- remaining stationary and inactive when development and production workers communicated ground-zero execution problems,
- standing on the sidelines as newly added “important ” bureaucrats and managers piled on more and more rules, procedures, and process constraints (of dubious added-value) in order to maintain an illusion of control,
- hiring more and more narrow and vertically skilled specialists that increased the bucket brigade delays between transforming raw inputs into value-added outputs,
may have been the cause for the poor performance. Then again, maybe not. What other and different reasons can you conjure up for explaining the poor execution performance of the company?
The Vault Of No Return
In big system development projects, continuous iteration and high speed error removal are critical to the creation of high quality products. Thus, it’s essential to install flexible and responsive Configuration Management and Quality Assurance (CMQA) support systems that provide easy access to intermediate work products that (most definitely) will require rework as a result of ongoing learning and new knowledge acquisition.
As opposed to virtually all methodologies that exhort early involvement of the CMQA folks in projects, I (but who the hell am I?) advise you to consider otherwise. If you have the power (and sadly, most people don’t), then keep the corpo CMQA orgs out of your knickers until the project enters the production phase. Why? Because I assert that most big company CMQA orgs innocently think they are the ends, and not a means. Thus, in order to project an illusion of importance, the org creates and enforces Draconian, Rube Goldberg-like, high latency, low value-added, schedule-busting procedures for storing work products in the vault of no return. Once project work products are locked in the vault, the amount of effort and time to retrieve them for error correction and disambiguation is so demoralizing and frustrating that most well-meaning information creators just give up. Sadly, instead of change management, most CMQA orgs unconsciously practice change prevention.
The figure below contrasts two different product developments in terms of when a CMQA org gets intertwined with the value creation project pipeline. The top half shows early coupling and the bottom half shows late coupling. Since upstream work products are used by downstream workgroups to produce the next stage’s outputs, the downstreamers will discover all kinds of errors of commission and (worse,) omission. However, since the project info has been locked in the vault of no return, if the culture isn’t one of infallible machismo, upstream producers and downstream consumers will circumvent the “system” and collaborate behind the scenes to fix mistakes and clarify ambiguities to increase quality. If and when that does happen, the low quality, vault-locked information gets out of synch with the informal and high quality information in the pipeline. Even though that situation is better than having both the vault and project pipeline filled with error infested information, post-delivery product maintenance teams will encounter outdated and incorrect blueprints when they retrieve the “formal” blueprints from the vault. Bummer.
Distributed Vs. Centralized Control
The figure below models two different configurations of a globally controlled, purposeful system of components. In the top half of the figure, the system controller keeps the producers aligned with the goal of producing high quality value stream outputs by periodically sampling status and issuing individualized, producer-specific, commands. This type of system configuration may work fine as long as:
- the producer status reports are truthful
- the controller understands what the status reports mean so that effective command guidance can be issued when problems manifest.
If the producer status reports aren’t truthful (politics, culture of fear, etc.), then the command guidance issued by the controller will not be effective. If the controller is clueless, then it doesn’t matter if the status reports are truthful. The system will become “hosed”, because the inevitable production problems that arise over time won’t get solved. As you might guess, when the status reports aren’t truthful and the controller is clueless, all is lost. Bummer.
The system configuration in the bottom half of the figure is designed to implement the “trust but verify” policy. In this design, the global controller directly receives samples of the value streams in addition to the producer status reports. The integration of value stream samples to the information cache available to the controller takes care of the “untruthful status report” risk. Again, if the controller is clueless, the system will get hosed. In fact, there is no system configuration that will work when the controller is incompetent.
How many system controllers do you know that actually sample and evaluate value stream outputs? For those that don’t, why do you think they don’t?
The system design below says “syonara dude” to the global omnipotent and omniscient controller. Each producer cell has its own local, closely coupled, and knowledgeable controller. Each local controller has a much smaller scope and workload than the previous two monolithic global controller designs. In addition, a single clueless local controller may be compensated for if the collective controller group has put into place a well defined, fair, and transparent set of criteria for replacement.
What types of systems does your organization have in place? Centrally controlled types, distributed control types, a mixture of both, hybrids? Which ones work well? How do you see yourself in your org? Are you a producer, a local controller, both a local controller and a producer, an overconfident global controller, a narcissistic controller of global controllers, a supreme controller of controllers who control other controllers who control yet other controllers? Do you sample and evaluate the value stream?
Accountability
Everybody loves to talk about “holding people accountable!”. You know, in the sense of “Bring Me The Head Of Alfredo Garcia“. The dilemma is that lots of people want to hold others accountable without being held accountable themselves. Management wants to hold the workforce accountable, but not vice-versa. The DICforce wants to hold management accountable, but not vice-versa.
When managers clearly define, specify, and communicate expected employee outputs along with the times that those outputs are due, then they have the information to hold an employee “accountable” if those requirements are not met. However, bad managers (of which there are many) aren’t competent enough to know how to clearly define, specify, and communicate what specifically is needed to get the job done. They do, however, know how to specify and monitor due dates – because it doesn’t require much brain matter to do so. Any wino off the street could be hired to dictate and watch unrealistic due dates.
On the other side of the fence, since bad managers don’t contribute anything to the org other than “status taking and schedule jockeying“, employees have no reliable and honest way of holding managers accountable (even if they were “allowed” to; which they aren’t). What’s an employee supposed to do? Call out a manager for not “taking status and watching schedule“? Yeah, right.
Sooooooo. Once you become a manager, a rare good one or a ubiquitous bad one, you’ve got it made. Your buddies who anointed you into the management guild won’t hold you accountable because it’ll make them look bad for choosing you (and of course, they can’t look bad in front of the troops because they have to maintain the illusion of infallibility). Your employees won’t hold you accountable either, because they want to remain hassle-free and you most likely don’t contribute anything of substance that is publicly and scrutably visible. It’s the best of both worlds and, in management lingo, a “win-win” situation.
Lesson Unlearned
Whoo hoo! We finally said screw it, we overcame our fears, and we mustered enough courage and determination to say “hasta la vista baby” to the stifling corpo citadels that we were shackled to. We huddled together, we created a flexible plan, we busted the cuffs, we scaled the prison wall, and holy crap; we actually freakin’ succeeded. We started our own company. And it’s growing. And our people feel useful and appreciated. And life is good. Ahhhhhhh!
Well duh, of course we need to track and manage revenues and costs, but in our company, unlike the herd we left behind (mooo!), those two obviously important metrics will always take a back seat to taking care of, and leading the people who create, develop, build, and sustain our product portfolio. Because we’ve personally experienced living in the quagmire, we’ve learned our lesson. We get “it” and we’ll never forget “it”. There’s no way, we mean no way, that we’re not gonna end up like our previous corpo hierarchs, who managed to turn it all backasswards – numbers first and people second (even though they innocently espoused the opposite).
Ummmm, yeah…… right. Check out the two parallel timelines below that purport to track the growth and maturity of a hypothetical startup company in the technology industry. I honestly don’t know squat, but I assert that the story reflected by the graphical depiction below is pervasive and ubiquitous, especially throughout the western world. If you could possibly be delirious enough to resonate with the content of this blarticle, then you may interpret the situation as a hopelessly sad state of affairs. Believe it or not, I interpret the situation as neither good nor bad. It just is what it is.
Dweeb In the Cellar
Check out the figure below and please heed the advice it dispenses. If you’re a Dweeb In the Cellar (DIC), don’t piss off the people in the highlighted boxes above you. As a DIC, you can (almost) safely piss off anyone else in the corpo caste system. However, each cookie cutter corpo command & control hierarchy is slightly, just slightly, different. For example, if your direct boss and one of his level 1 peers are great friends, you can’t piss the friend off either. As you might guess, it’s usually OK to piss your fellow DICs off, but again, each corpo org is slightly different.
Pray Or Play
Do you follow the rulebook and worship at the altar of the corpo pyramid, or do you break the rules in defiance of the chain of command to get stuff done in a timely fashion and add value to your organization? To some extent, everyone has to obey some basic ground rules so that chaos won’t reign, but do you question those rules from time to time to evaluate whether they’re still applicable? Do you experience pangs of fear when you ask tough questions that “aren’t supposed to be asked”? How do you ask a tough question without implying that someone is being ineffective? As just another dweeb stuck in a vertical silo at the bottom of the corpocracy, how can you point out cross-silo communication problems without pissing “important” people off? Do you faithfully, quietly, and unquestioningly sit behind the pew and pray, or do you at least try to play – in spite of the chance of incurring a potential career ending injury?
Directagers
Director of communications, director of operations, director of engineering, director of marketing, director of strategy. Yada, yada, yada. Everyone is, or wants to become, a “Director” of something. The ultimate directorship, of course, is to be elected to sit on one or more cushy Boards Of “Directors”.
Not discounting the title of “Chief”, the title of “Director” seems to have overtaken “Manager” as the coveted corpo title dujour. Compared to an honorable and esteemed “Director”, a “Manager” is now almost as unimportant as an “associate”, or equivalently, an “in-duh-vidual contributor” (gasp!). The title of “Manager” is……. so yesterday.
So what’s the next title to be inserted into the divisive corpo caste system, the “Directager“? Come on, take a guess.
Right, Right, Right.
Great leaders get the right info to the right people at the right time. They don’t hide behind the “it’s not my job” cliche. They don’t just “delegate this” and “delegate that” like a card dealer at a casino. They don’t just sit back in their throne, get manicures, and “review and approve”. They don’t just passively collect “status and schedule” information. They don’t set ambiguous and indecipherable direction, and then change it at will whenever it suits their personal agenda. They don’t mandate the latest management “technique” after they read about it in a 2 page Harvard Business Review article.
If getting the right info to the right people at the right time requires a leader to generate some of the information him/herself, then they do it.
Delegating only works when the delegator works too. – Robert Half
Hierarchical Growth
I’m currently in the process of reading Donella Meadows’s Thinking In Systems. Donella says that successful hierarchical systems grow from the bottom up, one layer at a time.
In the case of a human-made system of humans, as an assembled group of people becomes successful at what it does, it starts growing horizontally. The group finds a way to extract what it needs to sustain and grow itself (like money in exchange for products and services) from its surrounding environment.
In order to keep the group aligned and coordinated, the next higher level is formed from a small sub-group within the first level. Both levels feed each other in a mutually beneficial relationship and the organization keeps growing sideways. At a certain point, the second level becomes wide enough to require a third level to keep it synchronized with the group’s overall organizational goals. As growth continues, more and more layers are needed to keep the overall system from diverging from its true purpose.
At some unpredictable point in time, a strange and seemingly irrational inversion starts taking place as growth continues. The smaller, but higher layers in the hierarchy start consuming a more disproportionate share of the fruits of the organizational effort. The original, mutually beneficial, two way relationship transforms into an unbalanced one way relationship that is strangely accepted and taken for granted by everyone at all levels.
As a result of the imbalance, the bottom layers begin to atrophy from a lack of nourishment. As the one way upward flow of nourishment continues, the weight of the top layers increases and the strength of the lower layers decreases. In the worst case, the organization loses its balance and comes crashing to earth in a disintegrated mess.
In the early stages of growth, everyone in the organization fully understands that each successive layer is put in place to take care of the layer below it, and vice versa. When this understanding gets lost, all is lost. It’s just a matter of time until disaster strikes. Can the process be reversed? Sure it can, by restoring the balance and never losing sight of why the upper layers were created in the first place.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 