Archive
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
Structure, Work, Entropy
Entropy can be interpreted as a measure of chaos, or disorder. The second law of thermodynamics asserts that entropy increases with the passage of time. Tick, tock, tick, tock. The universe is constantly but surely on the move toward randomness.
As the universe unfolds in a continuous and creative dance, it temporarily suspends its own law of increasing entropy. It spontaneously forms new structures while others are simultaneously disintegrating.
As human beings, we are of the universe and thus, we also possess the awesome power to create. It takes structure plus work to create and, maybe more importantly, sustain something of value. The best we can do is temporarily arrest the growth in entropy by applying structure and performing the work required to keep the structures that we create in tact. Eventually, the inexorable rise in entropy wins and our creations disintegrate. It is what it is.
The Venerable Context Diagram
Since the method was developed before object-oriented analysis, I was weaned on structured analysis for system development. One of the structured analysis tools that I found most useful was (and still is) the context diagram. Developing a context diagram is the first step at bounding a problem and clearly delineating what is my responsibility and what isn’t. A context diagram publicly and visibly communicates what needs to be developed and what merely needs to be “connected to” – what’s external and what’s internal.
After learning how to apply object-oriented analysis, I was surprised and dismayed to discover that the context diagram was not included in the UML (or even more surprisingly, the SysML) as one of its explicitly defined diagrams. It’s been replaced by the Use Case Diagram. However, after reading Tim Weilkiens’s Systems Engineering With SysML/UML: Modeling, Analysis, Design, I think that he solved the exclusion mystery.
….it wasn’t really fitting for a purely object-oriented notation like UML to support techniques from the procedural world. Fortunately the times when the procedural world and the object-oriented world were enemies and excluded each other are mostly overcome. Today, proven techniques from the procedural world are not rejected in object orientation, but further developed and integrated in the paradigm.
Isn’t it funny how the exclusive “either or” mindset dominates the inclusive “both and” mindset in the engineering world? When a new method or tool or language comes along, the older method gets totally rejected. The baby gets thrown out with the bathwater as a result of ego and dualistic “good-bad” thinking.
“Nothing is good or bad, thinking makes it so.” – William Shakespeare
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.
Mista Level
“Design is an intimate act of communication between the designer and the designed” – W. L. Livingston
I’m currently in the process of developing an algorithm that is required to accumulate and correlate a set of incoming, fragmented messages in real-time for the purpose of producing an integrated and unified output message for downstream users.
The figure below shows a context diagram centered around the algorithm under development. The input is an unending, 24×7, high speed, fragmented stream of messages that can exhibit a fair amount of variety in behavior, including lost and/or corrupted and/or misordered fragments. In addition, fragmented message streams from multiple “sources” can be interlaced with each other in a non-deterministic manner. The algorithm needs to: separate the input streams by source, maintain/update an internal real-time database that tracks all sources, and periodically transmit source-specific output reports when certain validation conditions are satisfied.
After studying literally 1000s of pages of technical information that describe the problem context that constrains the algorithm, I started sketching out and “playing” with candidate algorithm solutions at an arbitrary and subjective level of abstraction. Call this level of abstraction level 0. After looping around and around in the L0 thought space, I “subjectively decided” that I needed a second, more detailed but less abstract, level of definition, L1.
After maniacally spinning around within and between the two necessarily entangled hierarchical levels of definition, I arrived at a point of subjectively perceived stability in the design.
After receiving feedback from a fellow project stakeholder who needed an even more abstract level of description to communicate with other, non-development stakeholders, I decided that I mista level. However, I was able to quickly conjure up an L-1 description from the pre-existing lower level L0 and L1 descriptions.
Could I have started the algorithm development at L-1 and iteratively drilled downward? Could I have started at L1 and iteratively “syntegrated” upward? Would a one level-only (L-1, L0, or L1) specification be sufficient for all downstream stakeholders to use? The answers to all these questions, and others like them are highly subjective. I chose the jagged and discontinuous path that I traversed based on real-time situational assessment in the now, not based on some one-size-fits-all, step-by-step corpo approved procedure.
Who’s That Masked Man?
I’m very skeptical of management consultants, but the dudes at VitalSmarts are really good. They are responsible for the wonderful “crucial” pair of books:
I’ve read both of these along with Influencer. They’re all very “down to earth” and highly accessible tomes that detail what works and what doesn’t work in terms of leading organizations of people. Their simple and “executable” advice is backed by academic research and, most importantly, their direct experiences from interacting with lots and lots (thousands) of real people in working organizations around the globe.
The following snippet from their latest e-newsletter caught my eye:
“People are excellent at masking ability problems.”
Man, ain’t that the truth! Along with you, I ‘ve put the “mask ” on many times, both willingly and unwillingly. The question is: “what would cause people to do this?”.
I think the main reason why people try to feign expertise is because they are stuck working in archaic corpo CCHs (Command & Control Hierarchies). All CCH orgs unquestioningly assume that everyone within the pyramid walls is supremely competent, regardless of whether they are or not. In a CCH, anyone who dares to persistently point out “ability” problems is excommunicated, regardless of how much evidence is presented to prove the case so that a beneficial change can be made. Heaven forbid the case where a lower level masked associate points to the huge masks being worn by one or more of the obviously infallible managers entrenched in an upper echelon. Retribution is swift and unambiguous.
Three Things
Three things: people, money, and time. These three interdependent resource types are the weapons that managers can deploy to create and sustain wealth for an organization. Managers are tasked with the challenge of judiciously apportioning these raw resources to the creation and sustainment of value-added products and services that solve customer problems. In addition to the creation and sustainment of products and services, the difficulty of continuously aligning and steering large groups of people toward the goals of growth and increasing profitability causes problem “fires” to be ignited within the corpo citadel. Bloated processes and warring factions are just two examples of the infinite variety of “pop up” fires that impede growth and profitability.
Left unchecked, internal brush fires always grow and merge into paradoxically massive, but hidden, forest fires that consume valuable resources. Brush fires feed on neglect and ignorance. Instead of creating wealth and continuously satisfying the external customer base, the three resource pools get exhausted by constantly being allocated to extinguishing internal fires.
Unless managers can “see” the growing fires, one or more massive fireballs can burn the organization to the ground. So, how can managers prevent massive fireballs from consuming would-be profits and customer goodwill? By constantly listening to, and investigating, and smartly acting on, the concerns of their people and their customers. Just listening is not enough. Just investigating is not enough. Just listening and investigating is not enough. Just listening and investigating and ineffective action is not enough. Listening, investigating, and effective action are all required.
Wide But Shallow, Narrow But Deep
I just “finished” (yeah,that’s right –> 100% done (LOL!)) exploring, discovering, defining, and specifying, the functional changes required to add a new feature to one of our pre-existing, software-intensive products. I’m currently deep in the trenches exploring and discovering how to specify a new set of changes required to add a second related feature to the same product. Unlike glamorous “Greenfield” projects where one can start with a blank sheet of paper, I’m constrained and shackled by having to wrestle with a large and poorly documented legacy system. Sound familiar?
The extreme contrast between the demands of the two project types is illuminating. The first one required a “wide but shallow” (WBS) analysis and synthesis effort while the current one requires a “narrow but deep” (NBD) effort. Both types of projects require long periods of sustained immersion in the problem domain, so most (all?) managers won’t understand this post. They’re too busy running around in ADHD mode acting important, goin’ to endless agenda-less meetings, and puttin’ out fires (that they ignited in the first place via their own neglect, ignorance, and lack of listening skills). Gawd, I’m such a self-righteous and bad person obsessed with trashing the guild of management 🙂 .
The figure below highlights the difference between WBS and NBD efforts for a “hypothetical” product enhancement project.
In WBS projects, the main challenge is hunting down all the well hidden spots that need to be changed within the behemoth. Missing any one of these change-spots can (and usually does) eat up lots of time and money down the road when the thing doesn’t work and the product team has to find out why. In NBD projects, the main obstacle to overcome is the acquisition of the specialized application domain knowledge and expertise required to perform localized surgery on the beast. Since the “search” for the change/insertion spots of an NBD effort is bounded and localized, an NBD effort is much lower risk and less frustrating than a WBS effort. This is doubly true for an undocumented system where studying massive quantities of source code is the only way to discover the change points throughout a large system. It’s also more difficult to guesstimate “time to completion” for a WBS project than it is for an NBD project. On the other hand, much more learning takes place in a WBS project because of the breadth of exposure to large swaths of the code base.
Assuming that you’re given a choice (I know that this assumption is a sh*tty one), which type of project would you choose to work on for your next assignment; a WBS project, or an NBD project? No cheatin’ is allowed by choosing “neither” 😉 .
Sloppy and Undisciplined
If a company is sloppy and undisciplined in execution, then almost all of its value-creation resources (people, time, money) are constantly putting out legacy product fires instead of developing new products/services – creating wealth. Revenues and, especially, profits may suffer. “May” and not “will” you ask? Yes, I say. You see, if a company can get customers to continuously pay for the messes that the company has innocently but surely created, then financial performance may actually be perpetually “good”, or even “excellent”. Say what? Hoodwinking customers to pay for cleaning up your messes? What customers in their right mind would do this? Government customers who love to spend other people’s money, of course. Nice work if you can get it.
Favorite Companies
Over the years, I’ve been on a constant watch for unique companies. By unique, I mean those that stand apart from the rest of the herd in the way that the executive leadership balances the needs of all stakeholders – not just the shareholders, or especially, themselves. Of course, unless you’ve worked at a company, it’s pretty tough to know if the company really lives up to its core values and “walks the talk”. That’s because all companies project the image that they are great places to work, regardless of whether they really are.
So, how do I decide whether a company is a cut above the rest? Via subjective evaluation of external observations, of course. Here’s my unscientific list of “research” methods:
- Read third party accounts of experience given by former and current non-management employees.
- Read, listen, and watch multiple interviews with CEOs and executives.
- Scour publicly available mission statements, visions, core values and cultural descriptions for authenticity, lack of corpo jargon, and attention to detail.
- Stay away from glossy annual reports.
- Ignore whatever the hand picked company spokesperson(s) say.
Of course, my methods aren’t perfect, but do you know of any better ones?
Here’s my current list of faves. What are yours?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 