Archive
I Found Another Gem
Whoo hoo! I’ve stumbled upon another rare gem in a massive pile of ugly rocks. As the graphic below shows, I’ve added HCL Technologies to my list of favorite companies. Led by their visionary CEO, Vineet Nayar, HCL is one of the few models for successful companies of the future. Since the vast majority of corpo Executive Teams are stuck in the mechanistic Sloan/Taylor mindset of the 1900s with no intention of changing the way they manage, err, impose control, it’s always refreshing and exciting to discover a new game changer.
So, how do I decide whether a company is a cut above the rest? Via subjective evaluation of external observations, of course. Financial performance, which is of course important, is of secondary concern. 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 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 – which are all clones of each other.
* Ignore whatever the hand picked company spokesperson(s) say – propaganda city.
Of course, my methods aren’t perfect, but do you know of any better ones?
Related Articles
- Why HCL Technologies puts employees ahead of customers (tech.fortune.cnn.com)
- HCL Technologies Annual Revenues up 24.1 % YoY; Quarterly Revenues up by 21.5% YoY and 7.7% Sequentially; Europe Annual Revenues up by 20.6% YoY in FY10 (prnewswire.com)
- Management Innovation: Extreme Management Makeover (petervan.wordpress.com)
- Indian outsourcer HCL Technologies quarterly profit up 6.9 percent to $74M on strong demand (taragana.com)
Two Paths
As a small group of people assembled for a purpose greater than each individual grows, some form of structure is required to prevent chaos from reigning. The top path shows the emergence of a group of integral coordinators while the bottom path shows a traditional, stratified CCH being born.
Which group would you rather be a part of? If you say you’d rather be a part of the “circular” group and you’re lucky enough to be a part of one, you’re still likely to get hosed down the road. You see, if your group continues to grow, it will naturally gravitate toward the pyramidal CCH caste system. That is, unless your natural or democratically chosen group leaders don’t morph into CGHs or BOOGLs and they actively prevent the subtle transformation from taking place.
If you’re currently embedded in a CCH and one of its leaders bravely attempts to change the structure to a circular, participative meritocracy, fugg-ed-aboud-it. The change agent will get crushed by his/her clanthinking BOOGL and SCOL peers, who ironically espouse that they want circular behavior while still preserving the stratified CCH.
Where Is Point A?
In the “Managing The Unmanageable” techonomy video discussion, HCL Technologies CEO Vineet Nayar says something like: “If your people don’t know where point A is, then they won’t know how to get to point B“. Vineet said this in response to a question regarding the concern that the more transparent your company is, the more your competitors can copy you. Vineet, along with the other two 21st century CEOs on the panel stated that the benefits of transparency far out weigh the risks of “giving away the family jewels“.
Look at the figure below. On the left side, through transparency and continuous full disclosure, your people know where you are (point A) and your people know where you and they want to be in the future (point B). Thus, you and your people can figure out what problems need to be solved and what new actions need to be taken. On the right side of the figure, everyone knows where point B is, but nobody (except for maybe a “select few” high up in the CCH) knows where they’re starting from. Where the frig is point A?
Related Articles
- Techonomy – Managing the Unmanageable: The New Empowered Workforce (nextbigfuture.com)
- Why HCL Technologies puts employees ahead of customers (tech.fortune.cnn.com)
- Techonomy: a new philosophy of progress (petervan.wordpress.com)
Alignment
You can supply your own words for this post…..
Deterministic, Animated, Social
Unless you object, of course, a system can be defined as an aggregation of interacting parts built by a designer for a purpose. Uber systems thinker Russell Ackoff classified systems into three archetypes: deterministic, animated, and social. The main criterion Ackoff uses for mapping a system into its type is purpose; the purpose of the containing whole and the purpose(s) of the whole’s parts.
The figure below attempts to put the Ackoff “system of system types” 🙂 into graphic form.
Deterministic Systems
In a deterministic system like an automobile, neither the whole nor its parts have self-purposes because there is no “self”. Both the whole and its parts are inanimate objects with fixed machine behavior designed and assembled by a purposeful external entity, like an engineering team. Deterministic systems are designed by men to serve specific, targeted purposes of men. The variety of behavior exhibited by deterministic systems, while possibly being complex in an absolute sense, is dwarfed by the variety of behaviors capable of being manifest by animated or social systems.
Animated Systems
In an animated system, the individual parts don’t have isolated purposes of their own, but the containing whole does. The parts and the whole are inseparably entangled in that the parts require services from the whole and the whole requires services from the parts in order to survive. The non-linear product (not sum) of the interactions of the parts manifest as the external observable behavior of the whole. Any specific behavior of the whole cannot be traced to the behavior of a single specific part. The human being is the ultimate example of an animated system. The heart, lungs, liver, an arm, or a leg have no purposes of their own outside of the human body. The whole body, with the aid of the product of the interactions of its parts produces a virtually infinite range of behaviors. Without some parts, the whole cannot survive (loss of a functioning heart). Without other parts, the behavior of the whole becomes constrained (loss of a functioning leg).
Social Systems
In a social system, the whole and each part has a purpose. The larger the system, the greater the number and variety of the purposes. If they aren’t aligned to some degree, the product of the purposes can cause a huge range of externally observed behaviors to be manifest. When the self-purposes of the parts are in total alignment with whole, the system’s behavior exhibits less variety and greater efficiency at trying to fulfill the whole’s purpose(s). Both internal and external forces continually impose pressure upon the whole and its parts to misalign. Only those designers who can keep the parts’ purpose aligned with the whole’s purpose have any chance of getting the whole to fulfill its purpose.
System And Model Mismatch
Ackoff states that modeling a system of one type with the wrong type for the purpose of improving or replacing it is the cause of epic failures. For example, attempting to model a social system as a deterministic system with an underlying mathematical model causes erroneous actions and decisions to be made by ignoring the purposes of the parts. Human purposes cannot be modeled with equations. Likewise, modeling a social system as an animated system also ignores the purposes of the many parts. These mismatches assume the purposes of the parts align with each other and the purpose of the whole. Bad assumption, no?
What’s Your ITAR?
A recent personal discovery that revealed itself to me is that “inquiring more and asserting less” is more effective than vice versa. Nonetheless, even after discovering this insight, I’m having a hard time increasing my Inquiry To Assertion Ratio (ITAR).
As you probably know, it’s difficult to change ingrained, long term behavior. When a social situation pops up in which the choice to inquire or assert appears, there often is no choice for me. In order to appear “in the know“, I automatically pull the trigger and make an assertion without asking any questions beforehand. However, I think I’ve made some progress. I can now often detect what I did after the fact. To improve even further, I’m hoping to reach the point where I can detect my transgression instantaneously, in the moment, so that I actually can choose to inquire or assert before I act. Ahhh, that would be nirvana, no?
In patriarchical CCH orgs, the ingrained mindset is such that the higher one moves up in the hierarchy, the lower the ITAR. That’s because BOOGLs and SCOLs unconsciously feel the need to appear infallible in front of the DICforce. Adding fuel to the fire, the DICsters fuel this behavior by expecting patriarchs to be infallible and have all the answers. It’s a self-reinforcing loop of ineffective behavior.
What’s your ITAR? As you age, do you find it rising – or sinking?
Yes I do! No You Don’t!
“Jane, you ignorant slut” – Dan Ackroid
In this EETimes post, I Don’t Need No Stinkin’ Requirements, Jon Pearson argues for the commencement of coding and testing before the software requirements are well known and recorded. As a counterpoint, Jack Ganssle wrote this rebuttal: I Desperately Need Stinkin Requirements. Because software industry illuminaries (especially snake oil peddling methodologists) often assume all software applications fit the same mold, it’s important to note that Pearson and Gannsle are making their cases in the context of real-time embedded systems – not web based applications. If you think the same development processes apply in both contexts, then I urge you to question that assumption.
I usually agree with Ganssle on matters of software development, but Pearson also provides a thoughtful argument to start coding as soon as a vague but bounded vision of the global structure and base behavior is formed in your head. On my current project, which is the design and development of a large, distributed real-time sensor that will be embedded within a national infrastructure, a trio of us have started coding, integrating, and testing the infrastructure layer before the application layer requirements have been nailed down to a “comfortable degree of certainty”.
The simple figures below show how we are proceeding at the current moment. The top figure is an astronomically high level, logical view of the pipe-filter archetype that fits the application layer of our system. All processes are multi-threaded and deployable across one or more processor nodes. The bottom figure shows a simplistic 2 layer view of the software architecture and the parallel development effort involving the systems and software engineering teams. Notice that the teams are informally and frequently synchronizing with each other to stay on the same page.
The main reason we are designing and coding up the infrastructure while the application layer requirements are in flux is that we want to measure important cross-cutting concerns like end-to-end latency, processor loading, and fault tolerance performance before the application layer functionality gets burned into a specific architecture.
So, do you think our approach is wasteful? Will it cause massive, downstream rework that could have been avoided if we held off and waited for the requirements to become stable?
Add Managers And Hope
The figure below shows the result of two attempts to increase the productivity of a hypothetical DICteam. In this totally concocted and fictional example, the nervous dudes in the penthouse (not shown in the figure) keep adding specialized managers to the team to fill voids that they perceive are keeping performance from improving. However, since the SCOLs never baseline the TEAM_VALUE_ADDED metric before each brilliant move, or track its increase or decrease with time, they have no idea whether they have achieved their goal. Because SCOLsters think they’re infallible, they just auto-assume that their brilliant moves work out as expected.
Of course, it often turns out that SCOLster decisions and actions do more harm than good. As the graph in the figure for this bogus example shows, not only did the team operating cost increase by the addition of two new manager salaries to the total, the team productivity decreased because of the additional communication and coordination delays inserted into the system. Add an additional “hidden” operating cost due to the high likelihood of jockeying and infighting between the three BMs (to gain favor from the penthouse dudes), and the system performance deteriorates further. Bummer.
So how can SCOLs increase team performance without throwing more useless overhead BM bodies at the problem? For starters, they can clearly communicate the gaps they “see” to the single team coordinator and help him/her rise to the challenge by providing mentorship and advice. They also can replace the BM with a competent, non-BM (fat chance). They can also (heaven forbid) invest in better tools, infrastructure, and training for the one coordinator and team of DICmates – instead of investing that money in more BM specialists. Got any more performance increasing alternatives to the standard “add managers and hope” tactic?
To Call, Or To Be Called. THAT Is The Question.
Except for GUIs, I prefer not to use frameworks for application software development. I simply don’t like to be the controllee. I like to be the controller; to be on top so to speak. I don’t like to be called; I’d rather call.
The UML figure below shows a simple class diagram and sequence diagram pair that illustrate how a typical framework and an application interact. On initialization, your code has to install a bunch of CallBack (CB) functions or objects into the framework. After initialization, your code then waits to be called by the framework with information on Events (E) that you’re interested in processing. You’re code is subservient to the Framework Gods.
After object oriented inheritance and programming by difference, frameworks were supposed to be the next silver bullet in software reuse. Well crafted, niche-based frameworks have their place of course, but they’re not the rage they once were in the 90s. A problem with frameworks, especially homegrown ones, is that in order to be all things to all people, they are often bloated beyond recognition and require steep learning curves. They also often place too much constraint on application developers while at the same time not providing necessary low level functionality that the application developer ends up having to write him/herself. Finding out what you can and can’t do under the “inverted control” structure of a framework is often an exercise in frustration. On the other hand, a framework imposes order and consistency across the set of applications written to conform to it’s operating rules; a boon to keeping maintenance costs down.
The alternative to a framework is a set of interrelated, but not too closely coupled, application domain libraries that the programmer (that’s you and me) can choose from. The UML class and sequence diagram pair below shows how application code interacts with a set of needed and wanted support libraries. Notice who’s on top.
How about you? Do you like to be on top? What has been your experience working with non-GUI application frameworks? How about system-wide frameworks like CORBA or J2EE?
Get Back To Work, Slackers
Penny Herscher, CEO of FirstRain, states in her blog:
We’ve made a terrific change this year to our vacation policy – which is basically not to have one…. We have a very intense culture today. People work hard, they work long hours inside and outside “normal business hours”, from home, from airplanes, and we don’t clock or watch the hours they work. So if we don’t clock the hours they are here, why should we clock the hours they are not? Why should we be tracking paperwork and forms when an employee takes the day off but we don’t do the same for when they work over a weekend.
She’s joking right? Trusting your employees and giving them total responsibility for managing their time? No way bro. That’s just not how it’s done! Poor FirstRain. Productivity is going to plummet and a trip to bankruptcy court is forthcoming, no?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 