Archive
Emotional Messaging
I don’t know about you, but when I feel strongly about topic that I know pretty well, it’s difficult for me to talk about the topic without mixing emotional meaning together with the verbal content of what I’m trying to communicate. Is that a bad thing? In the standard business mindset of a bygone era, it IS a bad thing. It’s “not professional” to show emotion. Those who can keep their emotions in check are annointed as leaders of the corpo castle. Robots rule and there is no room for humanity. Since all leadees watch their leaders closely, and most of the leadees naturally tend to emulate their leaders in the hope of moving up the corpo pyramid to success, mechanistic leaders innocently and unconsciously create mediocre “oatmeal” organizations.
In this day and age of knowledge commoditization, openness, and candor, emotion may be exactly what is needed to catapult an organization to the top. In order to lead, you must not only be competent, but passionate and inspiring. Those words imply the requirement for emotional communication to me.
Without emotional involvement, project outputs tend to be “meh” – cold, bland and mediocre. Classic MBA managers prefer the measurable over the meaningful. Not me. How about you?
High Falutin’ Titles
Along with a whole bunch of co-workers, I’m a member of the professional networking site linkedin.com. It’s a great site and I highly recommend it.
It’s interesting to browse through the profiles on LinkedIn. Everybody’s a freakin’ manager, or director, or chief-this, or chief-that. However, when you read their accomplishments, you can’t tell what the freak they’ve done. They seem to mostly describe the functions of the org areas that they’ve worked in. WTF? Of course, I don’t have any facts (I only use facts when they bolster my argument and I auto-reject all others 🙂 ), but I’d bet the farm that most of these people don’t direct or manage anyone and they haven’t done squat in years. They’re each, OMG!, a dreaded individual contributor. I picture them, perhaps wrongly, walking around flaunting their titles, manipulating people (instead of helping them to develop and grow) and barking out non-sensical orders that they’ve pulled out of their arses. They behave this way to look/feel important and they actually fool a few people for a while.
It’s sad, because I think that at the core of their souls, all people want to do the right thing for all. However, the shining light at their core has been trapped in no man’s land by layer upon layer of ego. The culprit behind ego inflation in the corpo world is a dysfunctional org structure. Specifically, it’s the obsolete 150 year old pyramidal, hierarchical structure of entitlement that all dinosaur corpo citadels pay homage to.
“Enough with the rant, got any alternative ideas smarty pants”? How can you mobilize a large group of people to change the world and prevent chaos from reigning without a corpo pyramidal caste system? One way is to organize as, and more importantly, operate in accordance with, a circular ring structure where all rings are directly connected with robust and high bandwidth communication channels. Instead of managers in the inner rings, there are leaders. Leaders focus more on developing people instead of enriching themselves.
So you say that the multi-ring design is nothing more than a squashed hierarchy with the innermost node representing the CEO? You’re literally right, but not figuratively. The main reason for operating your org structure as a flat concentric set of rings is to eradicate the deeply ingrained 1000s of years old “I’m better than you because I’m higher up in the food chain” mindset that unconsciously pervades all hierarchies. Sure, the people residing on the inner rings still have the responsibility to make org-wide decisions, but they do so with a more down-to-earth and people-centric mindset.
A non-conforming, ring-based company organization can’t possibly work, right? Blasphemy and off with my head! I know of at least one company that’s successfully implemented the “ringo star”. Semco Inc. of Brazil. If it piques your interest, Google them and/or check out the articles bookmarked in this twine: The Magic of Semco.
Thanks for listening.
My UCB
My Unshakeable Cognitive Burden
A few years ago, I first heard the phrase “Unshakeable Cognitive Burden”, or UCB. The UCB is a collection of deeply rooted beliefs, opinions, and values that color a person’s view of life. It serves as the foundation for his/her behavior. We all have a UCB, and we start unconsciously building it from the ground up as soon as we are born. If we remain unconscious and unaware of our UCB as we age, it starts to harden and stagnate.
The UCB is shaped like a pyramid where the lower layers become incredibly difficult to displace and replace over time as we innocently, but deliberately, filter out those circumstances and events and experiences that go against it. Since the top UCB layers are under less psychological pressure than the lower layers, they may be easy to displace and replace. However, depending on how unconscious and entrenched we are in our personal belief system, even the top layers can become immutable.
Trust me, it’s not good to have a UCB. I struggle with mine all the time. Rigid attachment to a UCB leads to a life of frustration, disappointment, and constant suffering. You get stuck in an arrogant, “I’m right and you’re wrong” binary mindset that can lead to violence or worse. Instead of living in the moment and enjoying life, you spend much of your time defending your UCB and attacking everyone else’s. It’s you against the big bad world. The Buddhists call this “the illusion of duality”.
The only way out of the UCB trap is to awaken to the fact that you’re living in a self-woven cocoon of lies based on “thoughts”. If you ever come to the realization that thoughts are just temporary formations of natural energy that arise out of nowhere in your consciousness, then your stance will soften and life will become lighter, breezier, and more peaceful. You will become more open and accommodating of others thoughts, ideas, and feelings.
So how do we awaken and become consciously aware? Is there a step by step procedure? I wish I knew. Do you?
Government Business
The figure below is a UML (Unified Modeling Language) class diagram that models a fictional government contracting system. So you don’t know UML? Don’t leave, because UML is easy to understand if one doesn’t over-specify in an attempt to show the world how “smart” he/she is.
The diagram shows the players (“classes” in UML lingo) in the game and some of the relationships (“associations” in UML lingo) between them. The diagram can be understood as follows:
The taxpayer funds congress, which funds groups of government bureaucrats, who hire a contractor to develop and deliver a product to be used by government workers to do their job of serving the public. Money, which everyone worships of course, ties all these main power players together. The contractor develops a product, which is then (delivered to the government and is) used by the government workers. All is well and the world becomes a better place. Whoopeee!
Yawn, meh. Boring and uninteresting, no? But wait, there’s more. Some hidden relationships between the “classes” in the system are not displayed by this proper and politically correct diagram. The diagram below shows just one of these hidden relationships – mistrust – between everyone 🙂 . How did this mistrust emerge and infiltrate the system? From the players getting burned in the past, that’s how. Especially the ultimate source of all money in the system – the taxpayer.
The last figure in this post shows the dynamic behaviors exhibited by each of the active players in this goverment business dance. In the UML, the middle compartment in a “class” (which is nothing more than a type of object – a classification) is intended to hold the attributes that characterize the class. I purposefully left them out because they’re not important to the message I’m trying to communicate.
I’ll leave it to your imagination to create specific scenarios of system operation (called “use cases” in the UML). Scenarios are specific subsets of behaviors that are sequentially strung together in time (scenarios can be modeled with UML “sequence diagrams”). At the end of a given scenario execution, the system has achieved a specific goal, like “make everyone in the system miserable”, or “damage the environment”, or “reward those who deserve it the least and punish those who are innocent of wrongdoing”.
Are there any significant players missing in this system? Are there any relationships missing? Are there any behaviors missing? Got a different model of how this government system works or how it should work? Remember this:
The purpose of a system is what it does, not what its advocates say it does.
Thanks for listening!
A Rigged System
Based on observation and personal experience, here’s my assessment of how the system nominally executes:
- A customer issues a Request For Proposal (RFP) or a Request For Quote (RFQ) for a product that meets a perceived need.
- The competitors respond with a proposal that contains a solution, a price, and a schedule.
- An organization wins (kudos and high-fives all around)!
- A program team is formed in the winning organization.
- The program team inherits the proposal schedule.
- The proposal is communicated to the product development group (PDG).
- The PDG forms a product development process (PDP) team.
- The PDP team analyzes the proposal and constructs a PDP schedule.
- The PDP team executes the PDP.
- The PDP team performance doesn’t *match* its own schedule OR the original proposal schedule – sometimes by a large amount.
- The customer, the organization, the program team, and the PDP team suffer the consequences.
- Go to step one for the next effort.
The figure below illustrates the nominal system operation, where M = Milestone.
Sometimes, but not always, the developer organization “forgets” the original proposal schedule and, via the magic of cognitive dissonance, praises the PDP team at the end of the effort for being on schedule and under budget. Sometimes, even the customer conveniently “forgets” original proposal schedule, but the customer’s financial sponsor usually doesn’t.
Do you agree with the assessment of the system’s nominal operation? If you agree with it, then consider these follow on questions:
For each of the participants in the system, where do you think the suffering starts?
Do all participants suffer equally? If not, which participant do you think suffers the most?
Is anyone at fault, or are the unintended consequences a byproduct of the system’s behavior?
What management techniques can be employed to drive “the measure of underperformance” to zero, or ideally, to a negative value?
Are there some management techniques that, if applied, will cause greater underperformance?
If you don’t agree with the assessment, then please tell me why, and what your experience has been.
Do you think the cognitive dissonance scenario exists?
If so, have you experienced the cognitive dissonance scenario?
In the cognitive dissonance scenario, even though the outcome is falsely deemed a rousing success, do you think there is any suffering by one or more participant groups during execution?
There Are Lots Of “I”s In A Team
“Sacred Cows Make The Best Hamburger”
Do you ever get tired of hearing the old and worn out management cry: “There’s no I in team!”. In this article, I’d like to challenge that unquestioned assumption.
The left-hand figure in the graphic below depicts a man-made group with a bunch of “I”s thrown together. Since the motto is “it’s every man for himself,” the group shouldn’t really be called a team. It’s more like a heap of individual and unconnected parts. In a heap, the whole is nothing more than the sum of the parts.
The figure in the middle of the graphic represents a group of people instilled with the “there’s no I in team” mentality. In this case, the group is more than the sum of its parts and it’s a much better problem solving structure than a heap of “I”s. However, because of the across-the-board homogeneity and lack of distinction between group members, the solutions produced by a group of “we”s are bland and mediocre, like unflavored oatmeal.
The figure on the right shows the ideal team. It’s composed of people who are motivated to succeed both individually and collectively. Relative to the other two types of groups, the team of “I + We”s is a super performer and it creates innovative solutions to problems. Thus, a high performing team is comprised of lots of “I”s.
Sadly, the vast majority of corpo organizations create hideous hybrid abominations like the one in the figure below. Yuk!
By; repeatedly espousing that “there’s no I in team!” to the doers sub-group; treating all work with the same apathetic reception regardless of relative quality; and punishing individual creativity; managers create and nurture a divided mediocracy. Of course, since they are the chosen ones, managers never follow the rules that they espouse for others. Thus, they are constantly and cleverly competing with their brethren for status and entitlement, operating as “I”s. It’s a good thing that the “we”s actually produce the outputs that allow the organization to survive, even though their products are mediocre and boring as hell.
Who’s Important?
Do you want to know who’s really valued by your organization’s so-called leadership? Just take a look at who’s located physically close to them. Look who’s got the big offices and what they’ve actually done to grow the organization. Look at who gets to go on company junkets. Look at who gets the training dollars. Are they the organization’s value producers, or are they the overhead consumers? Are they members of contracts, finance, marketing, human resources, business development, communications, compliance, or are they the people who create the value that keeps the organization alive: the engineers, the designers, the manufacturers, the integrators, the testers, the customer trainers, the customer support staff? Odds are that the people who directly create the wealth are cloistered in cubicle farms at the “back” or “bottom” of the building and treated as second class citizens. Long live those fossil managers who are stuck in the past and are ignorantly happy to operate by Ford’s , Taylor’s, and Sloane’s rules – regardless of what they say. Clueless dolts.
The Drunkard’s Walk
Assume that your company has a problem that needs to be solved. Management then creates a project and allocates resources: money, time and you, to solve the problem. The figure below shows the context that is established at project start. There’s you, the hairball problem, and a solution somewhere at the end of the project pipeline.
Since the best solution (out of an infinite set of possibilities) is almost always unknown a-priori, the amount of allocated money and time may not be correct. In my experience as a participant in the development and (mostly) maintenance of large, complex real-time embedded software systems, the “budgeted” amount of time and money is usually vastly underestimated. To top things off, management usually thinks that the problem-to-solution path is a linear, forward-only, sequential march to success.
The figure below shows the real drunkard’s walk that is traversed when a non-trivial problem gets solved. The start-to-end signature is person-specific. A prim and proper straight line to the solution through the official corpo process book never occurs. If you’re familiar with the problem domain and have solid experience with other similar problems, then your solution path may be less erratic than the path of others.
In the example above, notice how there are 3 occurrences of vector segments that go backward in time to revisit and correct mistakes. Each decision that you make to go backwards is a result of new knowledge discovery and learning. Sadly, because going backwards is a serious taboo in linear-sequential-think orgs, some people consciously decide to never go back, knowing full well that they’ve left some turds in the road for their followers to step in.
In a high pressure, micro-watched project, publicizing any regression steps to management in real-time is not a smart move. Even though it’s the truth, an unconscious force within you (ego) can cause you to lie and feign forward progress at every status reporting interval. Thus, in your manager’s mind, you’re “on schedule and under budget”. Splendid!
If you’re working on a multi-person project, then everyone else on the team is performing their version of the drunkard’s walk too. At each weekly breathalyzer test (oops! I meant status reporting meeting), everyone tries their damnest to appear sober in order to avoid a DUI .
Happy drinking!
The UML And The SysML
Introduction
The Unified Modeling Language (UML) and System Modeling Language (SysML) are two industry standard tools (not methodologies) that are used to visually express and communicate system structure and behavior.
The UML was designed by SW-weenies for SW-weenies. Miraculously, three well-known SW methodologists (affectionately called the three amigos) came together in koom-bah-yah fashion and synthesized the UML from their own separate pet modeling notations. Just as surprising is the fact that the three amigos subsequently donated their UML work to the Object Management Group (OMG) for standardization and evolution. Unlike other OMG technologies that were designed by large committees of politicians, the UML was originally created by three well-meaning and dedicated people.
After “seeing the light” and recognizing the power of the UML for specifying/designing large, complex, software-electro-mechanical systems, the system engineering community embraced the UML. But they found some features lacking or missing altogether. Thus, the SysML was born. Being smart enough not to throw the baby out with the bathwater, the system engineering powers-that-be modified and extended the UML in order to create the SysML. The hope was that broad, across-the-board adoption of the SysML-UML toolset pair would enable companies to more efficiently develop large complex multi-technology products.
The MLs are graphics intensive and the “diagram” is the fundamental building block of them both. The most widely used graphics primitives are simple enough to use for quick whiteboard sketching, but they’re also defined rigorously enough (hundreds of pages of detailed OMG specifications) to be “compiled” and checked for syntax and semantic errors – if required and wanted.
The Diagrams
The stacked UML class diagram below shows the structural relationships among the diagrams in the UML and SysML, respectively. The subsequent table lists all the diagrams in the two MLs and it also maps which diagram belongs to which ML.
In the table, the blue, orange and green marked diagrams are closely related but not equal. For instance, the SysML block definition diagram is equivalent too, but replaces the UML class diagram.
Diagrams are created by placing graphics primitives onto a paper or electronic canvas and connecting entities together with associations. Text is also used in the construction of ML diagrams but it plays second fiddle to graphics. Both MLs have subsets of diagrams designed to clearly communicate the required structure(s) of a system and the required behavior(s) of the system.
The main individual star performers in the UML and the SysML are the “class” and (the more generic) “block”, respectively. Closely coupled class or block clusters can be aggregated and abstracted “upwards” into components, packages, and sub-systems, or they can be de-abstracted downwards into sub-classes, parts, and atomic types. A rich palette of line-based connectors can be employed to model various types of static and dynamic associations and relationships between classes and blocks.
A conundrum?
In the pre-ML days of large system specification and design, ad-hoc text and structured analysis/design tools were predominantly used to communicate requirements, architectures, and designs between engineering disciplines. The use of these ad-hoc tools often created large gaps in understanding between the engineering disciplines, especially between systems and software engineers. These misunderstandings led to inefficient and error prone development. The figure below shows how the SysML and UML toolset pair is intended to close this “gap of misunderstanding”.
Minimization of the gap-of-misunderstanding leads to shorter *and* higher quality product development projects. Since the languages are large and feature rich, learning to apply the MLs effectively is not a trivial endeavor. You can’t absorb all the details and learn it overnight.
Cheapskate organizations who trivialize the learning process and don’t invest in their frontline engineering employees will get what they deserve if they mandate ML usage but don’t pay for extensive institution-wide training. Instead of closing the gap-of-misunderstanding, the gap may get larger if the MLs aren’t applied effectively. One could end up with lots of indecipherable documentation that slows development and makes maintenance more of a nightmare than if the MLs were not used at all (the cure is worse than the disease!). Just because plenty of documentation gets created, and it looks pretty, doesn’t guarantee that the initial product development and subsequent maintenance processes will occur seamlessly. Also, as always in any complex product development, good foundational technical documentation cannot replace the value and importance of face-to-face interaction. Having a minimal, but necessary and sufficient document set augments and supplements the efficient exchange of face-to-face tacit communication.
Closing Note: The “gap-of-misunderstanding” is a derivative of W. L. Livingston’s “gulf-of-human-intellect” (GOHI) which can be explored in Livingston’s book “Have Fun At Work”.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 