Archive
Sum Ting Wong
- SYS = Systems
- SW = Software
- HW = Hardware
When the majority of SYS engineers in an org are constantly asking the HW and SW engineers how the product works, my Chinese friend would say “sum ting (is) wong”. Since they’re the “domain experts”, the SYS engineers supposedly designed and recorded the product blueprints before the box was built. They also supposedly verified that what was built is what was specified. To be fair, if no useful blueprints exist, then 2nd generation SYS engineers who are assigned by org corpocrats to maintain the product can’t be blamed for not understanding how the product works. These poor dudes have to deal with the inherited mess left behind by the sloppy and undisciplined first generation of geniuses who’ve moved on to cushy “staff” and “management” positions.
Leadership is exploring new ground while leaving trail markers for those who follow. Failing to demand that first generation product engineers leave breadcrumbs on the trail is a massive failure of leadership.
If the SYS engineers don’t know how the product works at the “white box” level of detail, then they won’t be able to efficiently solve system performance problems, or conceive of and propose continuous improvements. The net effect is that the mysterious “black box” product owns them instead of vice versa. Like an unloved child, a neglected product is perpetually unruly. It becomes a serial misbehaver and a constant source of problems for its parents; leaving them confounded and confused when problems manifest in the field.
A corpocracry with leaders that are so disconnected from the day-to-day work in the bowels of the boiler room that they don’t demand system engineering ownership of products, get what they deserve; crappy products and deteriorating financial performance.
Proprietary Sneeze
In stodgy, arrogant, and paranoid corpocracies, everything is marked as proprietary: the company letterhead, the standard powerpoint layout, all documented processes (that (shhhh!) nobody follows), every e-mail, every conversation, the company newsletter, the recipes in the cafeteria, etc. Hell, when someone sneezes it’s deemed proprietary. Geez, what up wit dat?
“Lighten up Francis” – Sergeant Hulka (from the movie “Stripes”)
Heaven forbid that a competitor gets its slimy hands on any of your proprietary “stuff”. OMG, they’ll put you out of business by using all of your world-changing intellectual property against you. Anyone caught disclosing anything about the corpo innards will swiftly receive a peek-a-boo visit from a high ranking corpocrat, right?
To be fair, there probably is some stuff that really is proprietary, like some domain-specific algorithms and/or some custom hardware modules. But gimme a break Einstein. Regardless of what you espouse, the ubiquitous Bell curve says that you’re most likely not all that (pause for a yawn) great. Although you, like the vast majority of corpo citadels on the landscape, think and espouse that you’re obviously a cut above the rest, you’re not. Deal with it. Remove the camouflage that everyone is aware of, but is forbidden to discuss.
When you explicitly “allow” your people to discuss the undiscussables in a truly open and receptive environment without publicly or privately tarring and feathering them, then you’ve taken the first courageous step toward differentiating yourself from the herd. Mooo!
Note: I’m just a Dilbertonian DIC (Dweeb In the Cellar) who makes things up, so don’t believe a word I say.
Six To Nine Months
As a rule of thumb, one can assume that a corpo reorg will take place every six to nine months. “Our new organization will (no doubt) increase efficiency, profitability, and align us more closely with our customers“. Yada, yada, yada. Yeah, right. Whatever you say dude.
The figure below shows sample before-and-after corpo reorg charts. After the re-org, more profit-sapping fat has been added in an ill fated attempt to increase corpo performance. In the shiny new org, less productive work gets performed because some lucky(?) or ass-kissin’ DICs (Dweebs In the Cellar) are “promoted” into the ranks of the elite. Of course, as a reward for their loyalty, and regardless of their performance (because behavior is always more important than performance), some MIMs (Managers In the Middle) are further promoted up into the rafters or reshuffled sideways. Narrow, specialized, confusing, undefined, and weird new corpo titles are conjured up like “manager of the company newsletter”, “deputy director of timecard compliance”, “director of trade show booth setup “, and “manager of coffee grounds disposal”.
After six to nine months of further deteriorating financial performance, the corpo hierarchs shrug, scratch their heads, and repeat the cycle to “(no doubt) increase efficiency, profitability, and align us more closely with our customers“. Wash, rinse, and repeat. Wash, rinse, and repeat………….
Evasion And Abdication
One way to evade or abdicate responsibility is to never write anything down. Writing something down is a form of commitment because other people can see what you wrote, and archive it, and use it to hold you accountable.
“The palest of ink is better than the best memory.” – Chinese proverb
As a rule, managers don’t write down what they’ve signed up to do because they don’t “do” anything of substance. Of course, everyone in a standard cookie-cutter corpo hierarchy unquestioningly accepts that it’s “not a manager’s job” to do or commit to anything. Managers do, however, insist that others write things down because without the written word a manager can’t periodically poll for status and hold others accountable when schedules are missed.
On the other hand, really bad managers love to conjure up and write down what work others are required to do and when that work is due (even when they don’t have a klue what the work is). It’s the best of both worlds because they can hold others accountable without having to be held accountable themselves (whoopee!).
Even if managers are held accountable for poor team performance by higher up meta-managers (who also don’t write down their non-existent commitments), they don’t experience a guilty conscience because they fall back on the “the team failed and not me because it’s not my job” mentality.
When was the last time your immediate manager asked you “what problems are you having and how can I help?” or told you “let me know when you run into a problem so that I can try my best to help you“?
Disclaimer: I don’t have any badges or credentials and I just make things up, so don’t believe a word I say.
90 Percent Done
In order for those in charge (and those who are in charge of those who are in charge ad infinitum) to track and control a project, someone has to estimate when the project will be 100% complete. For any software development project of non-trivial complexity, it doesn’t matter who conjures up the estimate, or what drugs they were on when they verbalized it, the odds are huge that the project will be underestimated. That’s because in most corpo command and control hierarchies, there is always implicit pressure to underestimate the effort needed to “get it done”. After all, time is money and everyone wants to minimize the cost to “get it done”. Even though everybody smells the silent-but-deadly stank in the air and knows that’s how the game is played, everybody pretends otherwise.
The graph below shows a made up example (like John Lovitt, I’m a patholgical liar who makes everything up, so don’t believe a word I say) of a project timeline. On day zero, the obviously infallible project manager (if you browse linkedin.com, no manager has ever missed a due date) plots a nice and tidy straight (blue) line to the 100% done date. During the course of executing the project, regular status is taken and plotted as the “actual” progress (red) line so that everybody who is important in the company can know what’s going on.
For the example project modeled by the graph, the actual progress starts deviating from the planned progress on day one. Of course, since the vast majority of project (and product and program) managers are klueless and don’t have the expertise to fix the deficit, the gap widens over time. On really dorked up projects, the red line starts above the blue line and the project is ahead of schedule – whoopee!
At around the 90-95% scheduled-to-be-done time, something strange (well, not really strange) happens. Each successive status report gets stuck at 90% done. Those in charge (and those who are in charge of those who are in charge ad infinitum) say “WTF?” and then some sort of idiotic and ineffective action, like applying more pressure or requiring daily status meetings or throwing more DICs (Dweebs In the Cellar) on the project, is taken. In rare cases, the project (or product or program) manager is replaced. It’s rare because project (and product and program) managers and those who appoint them are infallible, remember?
So, is “continuous replanning”, where new scheduled-to-be-done dates are estimated as the project progresses, the answer? It can certainly help by reducing the chance of a major “WTF” discontinuity at the 90% done point. However, it’s not a cure all. As long as the vast majority of project (and product and program) managers maintain their attitude of infallibility and eschew maintaining some minimum level of technical competence in order to sniff out the real problems, help the team, and make a difference, it’ll remain the same-old same-old forever. Actually, it will get worse because as the inherent complexity of the projects that a company undertakes skyrockets, this lack of leadership excellence will trigger larger performance shortfalls. Bummer.
Status Takers And Schedule Jockeys
Whoo hoo! I’ve been promoted to “manager” by the Gods from above. I’m not a DIC (Dweeb In the Cellar) anymore. I’ve transitioned to the easy life of “taking status and riding the schedule”. Now I can shut down my brain because I don’t have to think or create anymore. I just have to walk around and: poll for status, look worried when people fall behind schedule, and “nicely” exert pressure on the team to perform. To top it all off, I got a big raise because of my “increase in responsibility”! Man, I love corpocracies and hieararchical gigs.
Fifty-Fifty
Because of the current economic environment, lots of recycled articles (take charge) regarding continuous education have appeared. Almost every one of them dispenses the same advice: “only you are responsible for continuously educating yourself and keeping your skills up to date”. Of course this is obviously true, but what about an employer’s duty to its stakeholders for ensuring that its workforce has the necessary training and skills to keep the company viably competitive in a rapidly changing landscape? Because of this duty, shouldn’t the responsibility be shared? What about fifty-fifty?
There are at least two ways that corpo managements (if they aren’t so self-absorbed that they’re actually are smart enough to detect the need) react to the need for continuing education of the people that produce its products and provide its services.
- Hire externally to acquire the new skills that it needs
- Invest internally to keep its workforce in synch with the times
Clueless orgs do neither, average orgs do number 1, above average orgs do 2, and great orgs do 1 and 2. Hiring externally can get the right skills in the right place faster and cheaper in the short run, but it can be much riskier than investing internally. Is your hiring process good enough to consistently weed out bozos, especially those that will be placed in positions that require leading people? If it’s a new skill that you require, how can your interviewers (most of whom, by definition, won’t have this new skill) confidently and assuredly determine if candidates are qualified? As everyone knows, face-to-face interviews, references and resumes can be BS smokescreens.
If external competitive pressures require a company to acquire deep, vertical and highly specialized skills, then hiring or renting from the outside may be the right way to go. It may be impractical and untimely to try and train its workforce to acquire knowledge and skills that require long term study. If you have a bunch of plumbers and you need an electrician to increase revenue or execute more efficiently, then it may be more cost effective and timely to hire a trained electrician than to train your plumbers to also become electricians (or it may not).
Which strategy does your corpocracy predominantly use to stay relevant? Number 1, number 2, both, or neither? If neither, why do you think that is the case? No cash, no will, neither?
Disconnected DICs
Without continuous, sincere, hard work from the leadership in a CCH (Command and Control Hierarchy) structure of human organization, it is all but guaranteed that the communication gap size between adjacent layers will exponentially increase when one traverses from the top level down to the bottom level.
The communication gap between two non-adjacent levels is even wider, culminating with a gap size of infinity between the DICs at Level=0 and the corpo hierarchs at Level=MAX. Bummer.
The Wall
The figure below shows the financial performance of a successful hypothetical company. During the startup phase, both revenue and profit increased at a linear pace, and then something interesting happened. As revenue rose, profit growth hit a wall and leveled off. Dooh!
So, what happened? In business lingo, the costs to execute the business rose faster than the costs to acquire the revenue. Since we are not company insiders, we can only speculate as to the underlying cause(s) of the performance slip, but here are two out of a bazillion possibilities:
- More bureaucrats were added at a faster rate than people with the skills and ability to execute.
- The company’s execution processes were unscaleable.
Let’s explore these two performance busters.
More bureaucrats were added at a faster rate than people with the skills and ability to execute.
With revenue pouring in, it’s easy to become sloppy and careless with all that dough. Egotistical managers, unconsciously trying to outdo one another by building personal empires, convince their disconnected and aloof next-level managers that they need more people for business execution, regardless of whether they actually do need them. These new additions are often specialists who are only capable of executing narrow slivers of the business. Thus, they spend most of their time in idle mode; consuming more from the company than they contribute.
On the other hand, the new additions may be ambitious, unskilled fellow managers who are tasked with doing what their bosses couldn’t – increase execution performance with the people that they currently have. By adding more sub-managers, each super-manager builds his/her empire and further buffers him/herself from where the rubber hits the road in the execution trenches.
The company’s execution processes were unscaleable.
Unless the company produces widgets or some other simple product that doesn’t require knowledge synthesis and frequent human situational decision-making skills, its business execution processes may be unscaleable. In a sincere but misguided attempt to control and increase execution performance, the company’s managers actually decrease scaleability and they inhibit performance gains by piling more constraining rules and procedures on top of the people who create, manufacture, test, and sustain the product portfolio. Rather than rolling up their sleeves and jumping in with their people to help them get the job done, these managers spend all of their time running around taking status and ensuring that all the rules and procedures are followed.
Can you think of any other reasons why this successful company may have stumbled?
All in all you’re just another brick in the wall. – Pink Floyd
Learn A Little, Do A Lot
There is no “learn” in “do” – manager yoda
Assume that you have a basic skill set, some expertise, and some experience in a domain where a task needs to be performed to solve a problem. Now assume that your boss assigns that problem to you and, out of curiosity you decide to track how you go about solving the problem.
The figure below shows the likely result of tracking your problem solving effort. You probably converged on the solution via a series of continuous Learning-Doing iterations. On your first iteration, you gathered a bunch of information and spent a considerable amount of time immersing yourself in the problem area to “learn” both context and content. Then you “did” a little, producing some type of work output – which was wrong. Next, you spent some more time “learning” by analyzing your output for errors/mistakes and correlating your work against the information pile that you amassed. Then you repeated the cycle, doing more while having to learn less on each subsequent iteration until voila, the problem was solved!
So, how can this natural problem solving process get hosed and low quality, shoddy work outputs be produced? Here are three possible reasons:
- Lack of availability of, or accessibility to, applicable information.
- Low quality, inconsistent, and ambiguous information about the problem.
- Explicit or implicit pressure to abandon the natural and iterative Learn-then-Do problem solving process.
IMHO, it should be a manager’s top priority to remove these obstacles to success. If a manager ignores, or can’t fulfill, this critical responsibility and he/she is just an obsessive, textbook-trained “status taker and schedule jockey”, then his/her team will transform into a group of low quality performers. More importantly, he/she will lose the respect of those team members who deeply care about quality.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 